Subject: Re: interrupting parallel port lossage
To: Bakul Shah <bakul@netcom.com>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
List: port-i386
Date: 03/23/1995 01:27:12
>The protocol is something like:
>
>1. wait for BUSY to be deasserted.
>2. write data byte
>3. after at least 500 ns, pulse *STROBE low for at least 500 ns
>4. Some time later the printer will pulse *ACK low for at least 5 us.
> It will (or at least ought to) lower BUSY when *ACK goes high.
>
>May be you need to put *two* delays in lpintr()?
>
> /* is printer online and ready for output */
> if (NOT_READY() && NOT_READY_ERR())
> return 0;
>
> if (sc->sc_count) {
> /* send char */
> outb(iobase + lpt_data, *sc->sc_cp++);
>---------> inb(0x84);
> outb(iobase + lpt_control, control | LPC_STROBE);
>---------> inb(0x84);
> sc->sc_count--;
> outb(iobase + lpt_control, control);
What I finally ended up with for lptintr() was this:
if (sc->sc_count) {
/* send char */
outb(iobase + lpt_data, *sc->sc_cp++);
delay(2);
outb(iobase + lpt_control, control | LPC_STROBE);
delay(2);
sc->sc_count--;
outb(iobase + lpt_control, control);
delay(2);
Some notes during this debugging:
I made up a test page that was mostly text so I could easily track the errors.
The errors were all one character "bleeding" into either the next or the
previous one. I remember hearing that delay() isn't accurate for small values
of delay() - would that err on too much or too little delay?
The inb()s helped, but didn't seem to be enough delay. I still seem to get
errors, but so far they are greatly reduced. Some of these delay's can
probably go away.
Load seemed to affect the printing tests - the greater the load, the better the
chance for screwups not to happen. This fits in with the idea that the timing
on the port writes is a little too strict.
--Ken