Subject: Re: interrupting parallel port lossage
To: Bruce Evans <bde@zeta.org.au>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
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?
--Ken