Re: [PARPORT] ECP, DMA, driver writing

From: Richard Stover (richard@ucolick.org)
Date: Fri Jun 23 2000 - 14:42:07 EDT

  • Next message: Derek Bouius: "[Fwd: [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).

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

    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.

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

    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.

    Hope this helps...

    Richard
     

    -- 
    Richard Stover                       email: richard@ucolick.org
    Detector Development Laboratory      http://gardiner.ucolick.org/~ccdev
    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: linux-parport-request@torque.net -- -- with the single word "unsubscribe" in the body of the message. --



    This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 14:44:20 EDT