[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avrdude-dev] Parallel port doesn't keep programmed states
From: |
Rune Christensen |
Subject: |
RE: [avrdude-dev] Parallel port doesn't keep programmed states |
Date: |
Wed, 26 Nov 2003 11:55:36 +0100 |
Hi
The link is http://www.beyondlogic.org/usb/usblptpd11.htm
But it's only a Windows driver!
Rune
-----Original Message-----
From: address@hidden
[mailto:address@hidden
Behalf Of Jan-Hinnerk Reichert
Sent: Wednesday, November 26, 2003 3:06 AM
To: address@hidden
Subject: Re: [avrdude-dev] Parallel port doesn't keep programmed states
On Wednesday 26 November 2003 00:43, Rune Christensen wrote:
> I have found a driver using the lpt port for I2C from
> www.beyondlogic.org I have ordered a DDK from Micro$oft.
I haven't found the driver on this site. Could you please post a more
specific link?
> To do list:
> We need to get exclusive access to the lpt port (P'n'P problem)
> (solved in the driver from beyondlogic)
> How much should the driver take care of (communication and/or
> access)??
We just had a discussion about making SPI-drivers for UNIX systems.
This would reduce the overhead for system calls. Right now, we are
doing 32 ioctl()-calls to transfer a single byte to/from the
parallel-port. With a driver there would be only one call per byte
;-)
A SPI-driver should have the following capabilities:
- configurable pins for MOSI, MISO and SCK
- sending/receiving a single byte
- making a single clock pulse on SCK (needed for "enter programming
mode")
- setting of maximum SPI-frequency (without all the system overhead,
we may be getting to fast)
IMHO, this is not a trivial task. The hardest thing will be the
generation of exact timings.
However, we can do it one step at a time:
1) Have a working driver that allows safe access to parallel port
(just writing and reading pins).
2) Implement SPI-transfers. Check if we get too fast.
3) Implement a configurable delay. Just something like: 0 for no
delay, 1 for some delay, 2 for some more delay...
4) Calculate delays from processor speed and given max. frequency.
Everything except 1) also needs changes in the avrdude-source, but
that shouldn't be too difficult.
Of course, volunteers are always welcome ;-)))
/Jan-Hinnerk
_______________________________________________
avrdude-dev mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/avrdude-dev
- [avrdude-dev] Parallel port doesn't keep programmed states, idefixx, 2003/11/21
- RE: [avrdude-dev] Parallel port doesn't keep programmed states, Rune Christensen, 2003/11/21
- RE: [avrdude-dev] Parallel port doesn't keep programmed states, E. Weddington, 2003/11/21
- Re: [avrdude-dev] Parallel port doesn't keep programmed states, idefixx, 2003/11/23
- Re: [avrdude-dev] Parallel port doesn't keep programmed states, Jan-Hinnerk Reichert, 2003/11/24
- Re: [avrdude-dev] Parallel port doesn't keep programmed states, E. Weddington, 2003/11/24
- RE: [avrdude-dev] Parallel port doesn't keep programmed states, Marc Wetzel, 2003/11/24
- RE: [avrdude-dev] Parallel port doesn't keep programmed states, E. Weddington, 2003/11/24
- RE: [avrdude-dev] Parallel port doesn't keep programmed states, Rune Christensen, 2003/11/25
- Re: [avrdude-dev] Parallel port doesn't keep programmed states, Jan-Hinnerk Reichert, 2003/11/25
- RE: [avrdude-dev] Parallel port doesn't keep programmed states,
Rune Christensen <=
- Re: [avrdude-dev] Parallel port doesn't keep programmed states, Jan-Hinnerk Reichert, 2003/11/26
- RE: [avrdude-dev]Windows driver [Parallel port doesn't keep programmed states], Rune Christensen, 2003/11/26
- Re: [avrdude-dev] Parallel port doesn't keep programmed states, Joerg Wunsch, 2003/11/26