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