>
> 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:
> ftp://gardiner.ucolick.org/pub/pp/
> 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: 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)
> ----------------------------------------------------------------------
>
Rich
-- ************************************************ Richard Bonomo UW Space Astronomy Laboratory ph: (608) 263-4683 telefacsimile: (608) 263-0361 email: bonomo@sal.wisc.edu ************************************************-- 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 - 16:18:09 EDT