Re: [PARPORT] ECP, DMA, driver writing

From: Richard Stover (
Date: Fri Jun 23 2000 - 16:58:11 EDT

  • Next message: Peter Pregler: "Re: [PARPORT] ECP, DMA, driver writing"


    > > The driver uses interrupt-driven double-buffered DMA to read data
    > > into system buffers. While DMA data is streaming into one buffer
    > > the driver is copying the content of the other buffer to the user
    > > address space buffer. This sounds simple enough, but I had to
    > > make diagrams and a flowchart to get it all straight in my mind
    > > before I started coding. Its now working solidly.
    > >
    > Does this cause bus-contention problems (i.e., does the copy operation
    > stall if it doesn't finish before the next DMA starts?)

    With 100 nanosecond memory, bus transfers take a fraction of a
    so there is no bus contention.
    On my 400MHz system it doesn't even produce a noticable load. The whole
    idea behind the double buffering is that the copy operation is going
    on during the DMA of the next block of data. If the copy doesn't
    finish soon enough then the next DMA can't start immediately.
    This is where a fast machine helps. I'm currently transferring
    data at about 4 microseconds per byte. My camera can send data as
    fast as 1 microsecond per byte. But a parallel port on the ISA bus
    just doesn't run this fast. The best I've seen is about 2 microseconds
    per byte (500kbyte per second). It would be nice to know if there
    are some motherboards that can go faster. (We're now planning a custom
    PCI board.)

    > > Rich, you said you had "a continuing stream of data (uncontrolled)."
    > > Do you have some buffering on this data stream? DMA can't continue
    > > at a perfectly uninterrupted rate because of the need to reload
    > > the DMA registers every 65K bytes. In my driver this is done
    > > in an interrupt routine. I have a 32k byte fifo to
    > > buffer my data. This seems sufficient, even at high data rates,
    > > but this might depend on the speed of your machine and on what
    > > other processes are running.
    > >
    > There is minimal buffering off-board, and the ECP fifo, that is it.
    > The data stream is not under the control of the computer; it just comes
    > as water out of a fire hose...

    The ECP fifo is typically 16 bytes - not much good for
    fast, sustained data rates.
    So you need a fast machine to make sure the DMA transfers don't stall.
    Even then, interrupt latency might kill you, depending on how fast
    your data arrives from your instrument. We're using a single 32kbyte
    fifo on a board between the camera and the port to provide buffering.
    At 4 microseconds per byte that gives me about 120 milliseconds worth
    of data buffering. This seems adequate and might even be overkill.


    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 Jun 23 2000 - 16:58:49 EDT