Messages in this thread | | | Date | Mon, 9 Feb 2009 12:01:44 -0600 | From | Shawn Bohrer <> | Subject | [staging] High level Comedi feedback |
| |
Hey All,
After reviewing the design of COMEDI there are a few concerns we've found that could inhibit COMEDI as a general data acquisition framework. I can elaborate on any of these concerns if needed, and I'd appreciate any feedback from those who are more familiar with the COMEDI drivers.
1. COMEDI lacks a state model (configure, reserve, commit, start, stop) that allows for speedy programming, reserving, and starting and stopping when multiple clients are vying for usage of the shared hardware and setup/tear-down costs have to be minimized. The comedi_cmd interface forces the setup costs to be incurred for every acquisition this is a performance liability. The other downside of this interface is that it does not allow for on-the-fly settings changes such as changing an acquisition rate or ranges of a channel within a running acquisition/generation.
2. In general I'm concerned that the comedi_cmd_struct can't be expanded to support all of the possible timing configurations of existing hardware.
3. COMEDI expresses timing in terms of nano-seconds, limiting the scan rate to 1GHz, scopes can go higher than this. The ~4,200V and 4.2A limits brought by the range scaling coefficients are often suitable, but could be a problem later with signal conditioned boards. Would value + unit or value + multiplier be better?
4. COMEDI lacks the fine grained resource reservation (digital lines, specific routes).
5. COMEDI does not yet support memory mapped digital lines or memory mapped single point reads/writes directly with the hardware.
6. COMEDI doesn't yet support configuring hardware buffer sizes for deep on-board FIFOs.
7. The comedi_bond.c driver doesn't attempt any synchronization and doesn't support buffered operations. These features could be added, in the kernel, but wouldn't this be better done in user-mode?
-- Shawn
| |