Re: [PARPORT] ECP, DMA, driver writing

From: Richard Bonomo (
Date: Fri Jun 23 2000 - 16:16:57 EDT

  • Next message: Richard Bonomo: "Re: [PARPORT] ECP, DMA, driver writing"

    > Rich,
    > I think my application is not exactly like yours. I'm reading
    > large (but finite, up to about 64Mbyte) sized images in ECP mode.
    > I wrote a separate device driver to do this. It is a loadable module.
    > I've tried to put lots of comments in the source code (so I could
    > remember what I was doing a year from now).
    My situation is similar; it will involve about 78 Mbytes of data,
    in toto.

    > I have put the source code on my ftp server:
    > The driver is in pp.tar and a sample user program is ppgreadxv.c

    Thank you! I have downloaded it do that I may peruse it.

    > 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?)

    > There is also a mechanism to allow a second user process to do
    > near real-time processing of the data as it is being read in.
    > If the user process doing the actual read uses shared memory to
    > hold the image data the second user process can access that shared
    > memory and can do an ioctl to the device driver which will return
    > a byte count after each 65K byte chuck of image data are read.
    > The sample user program, ppgreadxv.c, doesn't illustrate the real-time
    > processing, but I could develop a simple example if it seems worth
    > while.

    Could be of interest. (Let me know if you do decide to do this...)

    > I use this to do things like image unscrambling (if there are actually
    > multiple channels of data in the input stream)
    > and streaming transmission of the descrambled data onto the net,
    > where other processes can grab the data and do any number of
    > useful things.
    > My driver doesn't bother to do DMA on output since I typically
    > write only a few bytes of control data to the camera that is sending
    > the image data.
    > None of this plays well with the standard parport code. But parallel I/O
    > cards
    > are cheap so having a dedicated parallel port for this sort of
    > application
    > is easy.

    Not a concern for us, as the built-in port will be dedicated to
    this use.

    > 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...

    > Hope this helps...

    Thank you. I will no doubt have questions for you...

    > Richard
    > --
    > 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)
    > ----------------------------------------------------------------------


    Richard Bonomo
    UW Space Astronomy Laboratory
    ph: (608) 263-4683 telefacsimile: (608) 263-0361

    -- 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:18:09 EDT