From: Richard Stover (
Date: Fri Mar 10 2000 - 13:11:17 EST

  • Next message: Tim Waugh: "Re: [PARPORT] Linux paride boot disk"

    Tim Waugh wrote:
    > On Thu, 9 Mar 2000, Greg Nelson wrote:
    > > 1) What specifically are the problems regarding the FIFO? I have a
    > > set of specs and datasheets that I can consult to see if these can
    > > be resolved.
    > When we're in the reading path, and using the FIFO, the user has told us
    > how many bytes we can return. So if the peripheral is sending us a
    > constant stream of data (and we don't know if this is the case), we'll
    > have to tell it to shut up after a certain point.
    > But in the datasheets I've been looking at, there doesn't seem to be a way
    > to tell the chipset to stop accepting data into the FIFO while we read out
    > the contents. So we have this situation:
    > FIFO
    > read 3 bytes |***-------| peripheral has more to send (O)
    > got 1 byte |**OO------| sent 2 bytes
    > got another |*OO-------|
    > and another |OO--------|
    > reset FIFO (empty)
    > We lost data. Even if we read out all of the data in the FIFO before we
    > reset, there's nothing to stop the peripheral filling it up again as we
    > read it out.
    > Do you see the problem now?

    Since I've been working on a device driver to handle a high speed
    camera that will produce data at very high rates I've been looking
    at issues like this. If you have a peripheral that does follow
    the ECP standards you shouldn't have to loose any data.
    The way to stop data is to negotiate from reverse to forward phase
    (from input to output). When the host sets nReverseRequest (also
    called nInit high, the pheripheral must tri-state its data bus.
    If the peripheral was in the middle of a data transmission it
    must assume the data byte will be discarded by the host and
    it stops all furthter transfers. You can then read whatever
    is left in the fifo. nReverseRequest is bit 2 of the device
    control register.

    If your device doesn't adher to the ECP protocols, well...good luck.

    I hope this helps.


    Richard Stover                       email:
    Detector Development Laboratory
    UCO/Lick Observatory                 Voice: 831-459-2139
    Natural Sciences Bldg. 2, Room 160
    University of California             FAX:   831-459-2298
    Santa Cruz, CA 95064  USA            FAX:   831-426-5244 (Alternate)

    -- To unsubscribe, send mail to: -- -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Fri Mar 10 2000 - 13:12:54 EST