Re: [PARPORT] Question about 2.4.0-test1 FIFO reads

From: rjh@world.std.com
Date: Tue Jul 04 2000 - 23:54:19 EDT

  • Next message: rjh@world.std.com: "Re: [PARPORT] Question about 2.4.0-test1 FIFO reads"

    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