- From: Ian Abbott <abbotti_at_mev.co.uk>
- Date: Mon, 07 Feb 2005 15:09:33 +0000
Hi Frank, On 02/06/05 15:25, Frank Mori Hess wrote: > On Thursday 03 February 2005 07:30 am, Ian Abbott wrote: >>I've added a new driver (plus a helper driver) for the Amplicon PCI272 >>and PC272E 72-channel DIO cards to Bugzilla (bug #128): >> >>https://cvs.comedi.org/cgi-bin/bugzilla/show_bug.cgi?id=128 >> >>Feel free to point out all the errors, etc. :-) > > Hi Ian, > > I don't want command support simulated by the driver. The hardware doesn't > really support input or output commands, just externally triggered > interrupts. It reminds me of the evil das-08 which claimed to support > externally triggered a/d conversions, but really all it did was generate > an interrupt and the actual a/d conversion was started by the cpu (with > crappy unreliable timing as a result). The driver should just expose the > ability to externally generate interrupts, then the user-space program (or > RT task) can do whatever it wants when an interrupt is triggered. So interrupt driven commands are a bit of a no-no? I thought crappy unreliable interrupt timing would be better than even crapper process scheduling timing! There are a few existing drivers that make use of interrupt driven commands for data acquisition: 8255 - has some incomplete support for commands dt2814 - has interrupt driven ai pcl711 - has interrupt driven ai pcl812 and pcl816 - uses interrupt driven ai if DMA disabled pci818 - sometimes uses interrupt driven ai (depending on convert_src, etc.) > Right now, I think the only existing driver that does something similar > with externally triggered interrupts is comedi_parport.c, which just > writes a 0 to the buffer every time it gets an external trigger. A > user-space program can then do a select() on the device file to get woken > up whenever a trigger occurs. So this sort of command should only be supported on hardware that has on-board buffers? There are a couple of other drivers that do that too: ni_6527 and amplc_pc236 (I wrote amplc_pc236 a couple of years ago, based on comedi_parport). > This scheme is less than ideal, but good > enough if you don't want to spend time figuring out how to extend comedi > to better support externally triggered callbacks. It seemed better to me to return some useful data in the command buffer, rather than 0. Maybe I could just document that the driver uses interrupt-driven commands and the hardware has no buffering? -- -=( Ian Abbott _at_ MEV Ltd. E-mail: <abbotti_at_mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Received on 2005-02-07Z15:09:33