Re: [PARPORT] How can cpu use by the parport be limited? (question from new cpia driver maintainer)

Date: Fri Dec 27 2002 - 19:33:51 EST

  • Next message: Alan Cox: "Re: [PARPORT] How can cpu use by the parport be limited? (question from new cpia driver maintainer)"

    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

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