avrdude-dev
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]