Rich,
> > 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
microsecond
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
-- 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 - 16:58:49 EDT