Subject: Re: interrupting parallel port lossage
To: Bruce Evans <>
From: Ken Hornstein <>
List: port-i386
Date: 03/23/1995 10:41:49
>>			    A  B  C  D
>>			     ________                    _ _ _ _ _
>>	DATA    ------------<________>------S S---------<_ _ _ _ _
>>		_______________    _________   ____________
>>	*STROBE                \__/         S S            \_
>>				  __________   _________
>>	BUSY    _________________/          S S         \________
>>		____________________________   ____         ____
>>	*ACK                                S S    \_______/
>>						   E    F   G
>>A->B == DATA out to *STROBE low time = 0.5 us min.
>>B->C == *STROBE low to *STROBE high time = 0.5 us min.
>>C->D == *STROBE high to DATA tri-state == 0.5 us min.
>Do you think the software needs to delay for C->D?  I don't think so.
>If it returns from an interrupt handler, a relatively huge delay is hard
>to avoid.  If it polls BUSY and/or *ACK, it should see valid states
>because these signals are already stable enough.

Last night the errors I saw were very consistant.  Characters either ended
up "bleeding" to the next or previous character.  A bleedover to a previous
character would seem to imply that the next character was put on the data
lines before the printer got done taking them off.  Judging from that, I
would guess that some sort of delay from C->D is necessary.  I think that
bleeding over to the next character is from not enough setup time.

Judging from this timing diagram, BUSY should go high before you put *STROBE
high, right?  Maybe a check for this is really what's needed instead of
a delay from C->D.

>>So one more thing the driver can do is check that BUSY is
>>really low *before* outputting and right after setting
>>*STROBE low, check BUSY goes high (via a timed loop;
>>breakout after 5 us or BUSY hight).
>This only works if you disable interrupts and the cpu is
>sufficiently fast.  Otherwise an interrupt or cpu slowness
>may add an unknown amount of time to the 5 us and *BUSY
>may go up and down while you're not looking.  Disabling
>interrupts isn't nice and depending on particular cpu and
>hardware speeds is the cause of half the problems that we
>are discussing.

Maybe in a spin loop?  (Only check 5 times, for example).  What's the "right"
way to do this?