On 3 Jul, Tim Waugh wrote:
> On Sun, Jul 02, 2000 at 05:13:28PM -0400, rjh@world.std.com wrote:
>
>> 1) This assumes that the stop, turn around is fast enough to avoid a few
>> extra bytes getting into the FIFO. (The code checks for this and
>> reports an error when it happens.)
>
> Yes. I wonder if it works to stop it before reading from the FIFO,
> and then resume if we need more. That would close that race wouldn't
> it?
>
It should. At the very least, the window is greatly smaller. This
depends on some details of FIFO management that the specification sheets
do not discuss. Like the interaction of FIFO full with direction
reversal.
IEEE 1284 permits the recipient of a transfer to postpone acknowledge by
up to 1 second. Does the FIFO hardware interact with the ECP hardware
to postpone the ack when FIFO-full? The spec sheet for the hardware in
my computers does not say. I would hope that the chip does. It would
sure make life much easier. It would almost eliminate the worry about
FIFO overruns. A Linux system is in really deep trouble if it cannot get
around to servicing a parallel interrupt for anything close to a full
second. FIFO overruns are probably the least of its worries.
I've dealt with enough PC hardware not to trust that it does the
sensible things. Axelson's reference includes warnings about FIFO
overrun, but it also was written when a 386 was commonplace and it uses
Visual Basic examples. In that environment a 1 second delay might
reasonably be expected to occur. Plus, I would worry about whether the
peripherals are really IEEE1284 compliant. It may say 1 second, but
they might not tolerate 1 second delays. Perhaps it is possible that
people with real knowledge of the various chipsets could confirm how the
transfers, FIFO-full, and direction reversal interact.
>> 2) It assumes that the peripheral is not perturbed by the host doing the
>> port turn-around before all the bytes are read.
>
> It assumes the peripheral is IEEE 1284 compliant, yes. There are lots
> of places where it could probably be more forgiving.
>
The device that I'm dealing with is not fully IEEE 1284 compliant. I
cannot yet count the ways since I am still learning them. For instance,
this is the firmware that it uses for an ECP-mode reverse transfer:
#define XMIT_1_BYTE_ECP(c) \
{ PORTA = c; \
Clear_PeriphClk; \
while (!bHostAck) ; \
Set_PeriphClk; \
while (bHostAck) ; \
}
and
while (length--) { // [40]
XMIT_1_BYTE_ECP(*buffer++);
}
(See that [40] for 1284 state 40.) It completely ignores the reverse
request. But it will happilly wait if the host ack is delayed (up until
the timeout triggers). As they warned me, don't try to mess with
anything during device block transfers. It does not deal with change
well.
I'm still learning what triggers recovery, deadman timers, etc. I still
find myself pulling power on the thing and then waiting a while for it
to recover and stabilize.
This is real life. This device works fine with regular PC's running
Windows 98/NT, so the original developers are pleased. They know that
they left out a lot of 1284, but "it works". To be fair, they had a
bunch to behavior to squeeze into a little bitty 2KB ROM.
>
> While writing the code I imagined a peripheral with lots of data to
> send, so I didn't want to use the FIFO (which can get filled up
> quickly) if that would cause data loss. So if the client only wants a
> few bytes, the idea is that we do it in software mode to prevent
> losing any data.
>
> Bear in mind that while writing it I didn't even have any proper
> hardware to test with, just the spec.
And I've got real hardware that doesn't follow the spec. This should be
fun. :-) It does want to slam some moderately fast transfers of about
100KB through that ECP code. From the cycle time of the microprocessor
involved, and the assembler that corresponds to the above C code, it can
do a byte in 1.2 microseconds. But do note, while it is not prepared
for any exception cases, it is prepared for the host to slow down the
transfer with slow acks.
A lot really depends on the unknowns of FIFO behavior by the various
chips.
R Horn rjh@world.std.com
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Jul 05 2000 - 00:05:34 EDT