Darren Bilby (email@example.com)
Wed, 29 Dec 1999 02:51:55 +1300
Yeah, I definitely agree with the way you've done it. If people need to do
low level stuff they should be using outb and inb, perhaps a list of the
basic inb and outb commands to set up ECP, EPP and SPP mode could be
documented to help those people.
Took a while to get my head around what the parport code was doing, totally
makes sense now tho. I ended up aliasing outb and inb with #define in the
parport code so I could see exactly what was going out the port.
From: Tim Waugh [mailto:firstname.lastname@example.org]
Sent: Wednesday, 29 December 1999 1:30 am
To: Darren Bilby
Cc: Linux Parallel_Port
Subject: RE: [PARPORT] Realtime control of parallel port
On Tue, 28 Dec 1999, Darren Bilby wrote:
> We wanted to keep firing things at the port indefinitely in ECP mode,
> but in doing a write() it was, changing modes in and out of ECP (to
> PS2 mode?). The parport code was excellent for firing out big blocks
> of data, but we were sending it out 30 bytes at a time with a realtime
> app. It was doing a fair bit of handshaking for every 30 bytes which
> it didn't need to do.
Right. The reasons that it tells the parallel port chip to go to PS2 mode
are (a) so that you know that when write() returns the peripheral has
actually received the data and (b) so that SPP operations will work
I don't really want to get rid of (a), but (b) could be done more lazily
by having each parport operation check what mode the port was in and
adjust it appropriately. It would be quite easy to get it wrong though --
some of those operations can be called from interrupt context sometimes.
> The extra handshaking confused our our hardware board which was only
> minimally ECP compliant. In the end we were really asking a parport to
> do things it was never designed to do, but with a bit of magik we made
> it go.
There shouldn't have been any actual handshaking on the wire though. I'm
sure there are opportunities for making it go faster, but I'd like to keep
the write()-doesn't-cache guarantee.
-- To unsubscribe, send mail to: email@example.com --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Tue 28 Dec 1999 - 08:53:42 EST