My experience is with a similar application so perhaps these comments
will help. It was a couple years ago using Linux 2.2 connecting a CCD
device to a PC. My test numbers are for a 500 MHz PC.
1.) Do not use interrupts unless you also have DMA.
Interrupts are designed for situations where the device will be busy for
a long time (compared to the CPU task switch time). This means hundreds
of microseconds or longer on current PCs. The CCD device responds to
the parallel signals within a microsecond, so it is much faster to wait
in a poll loop than to suffer all the computation of state save,
reschedule tasks, service interrupt, reschedule tasks. This also helps
other interrupt device responses (like mice for X windows) because the
poll loop is in the interruptable upper half of the driver, running at
client process priority.
This might be the problem that you are currently seeing. You might also
utilize a mix of interrupt and non-interrupt. It is the bulk data
transport where the CCD device responds within a microsecond. The other
command related stuff for setup and picture taking might be slow enough
that interrupts help.
2.) You do not need DMA as much as you need FIFO support.
In a non-interrupt mode you can turn on the ECP with hardware FIFO. When
an interrupt actually occurs, the FIFO logic will continue to operate.
This gains one FIFO worth of transfer time. The generic parallel FIFO
is 16 bytes, but some parts have larger FIFOs. Again, the bulk transfer
should sit in a polling loop at an interruptable upper level. Whenever
there is an interrupt, the return to this loop will slurp in the full
FIFO within a few microseconds. It is limited by the PIO bus. Then you
usually cycle on the loop waiting for FIFO-not-empty and collect one
byte per every few loops. (My device delivered data at about
700KB/sec maximum into dummy test logic.)
I did not bother to shift to interrupt for the slightly longer capture
controls with my device. I never did get DMA working because of
hardware issues. Few of the target PCs had DMA capable parallel
devices, but most had hardware ECP to FIFO. Those that did not were
able to use the software ECP mode. None had to drop back to nibble
mode.
While capturing, the CPU ran at 100% cpu utilization. This did not
interfere with X windows, editing, compiling, or other normal
activities. The Linux scheduler quickly dropped the capture program
down to low priority and just scheduled its polling cycle during what
would otherwise have been idle time. Most PCs are normally 90+ percent
idle even during typical use. Our target devices were typically 99+
percent idle when not taking pictures.
The data transfer rate when not doing anything else was:
75 KB/sec - software ECP mode
300 KB/sec - software polling, ECP-FIFO hardware
For endurance testing I ran the CCD on continuous maximum rate capture
mode for 100,000+ captures before any internal or external release.
This did not noticably interfere with other routine use of the PC.
Running CPU intensive applications did interfere with the capture rate,
but did not break things.
-- 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 Dec 27 2002 - 19:36:29 EST