- From: Steve Sharples <sds_at_eee.nottingham.ac.uk>
- Date: Tue, 6 Apr 2004 12:00:13 +0100 (BST)
Hello there, I'm after opinions about a sensible approach to adding extra functionality to a driver that's already been written by someone else (amplc_pci230). We have an Amplicon PCI230 data acquisition card, and our analogue data acquisition requirements include the ability to take data from a list of analogue channels in what I've previously been calling "triggered burst mode." This is when an external event (a digital line going from low to high, say) triggers the acquisition of a set list of channels, as fast as the board can acquire them. Once all channels in the list are done, the board waits for the next external trigger event. The comedi command structure seems to allow this using: start_src TRIG_NOW scan_begin_src TRIG_EXT convert_src TRIG_TIMER scan_end_src TRIG_COUNT stop_src TRIG_COUNT However, only TRIG_FOLLOW is "allowed" for scan_begin_src in amplc_pci230.c I plan to add scan_begin_src=TRIG_EXT functionality in one of 2 ways: (1) use one of the 8255 port C lines as the GATE input to the 8254 counter/timer that's providing the convert clock pulses. This will require an external pulse of the correct length (at least as long as the time required to sample all the channels on the channel list) and some mechanism for ensuring that the next scan doesn't begin before the next external gate pulse is applied. I'm not really sure how to do this without sitting in a loop, polling the port C line, and waiting for the correct series of transitions... this kinda breaks the rules for the command structure, which is meant to return once set up. (2) use one of the 8255 port C lines to gate one of the 8254 counter/timers to produce a pulse of the correct length (using "Mode 1, Hardware re-triggerable one-shot"), which is then applied to the GATE input of the counter/timer that's providing the convert clock pulses. The second method seems more rugged... what to people think? Is this the right way to go about doing this? Has anyone got any advice? Is this how it's done in other drivers, or am I missing a trick? I'm concerned that the pulse will have to be of exactly the correct length to get the correct number of convert pulses (for the number of channels in the channel list), otherwise the next scan will start. Perhaps it would be easier to, instead of using scan_begin_src=TRIG_EXT, use start_src=TRIG_EXT; this would effectively limit you to one scan per command (you could have more than one scan per command, they would just follow on from each other, without waiting for a trigger), and relying on software to set up the next command before the next hardware trigger comes along. I can't help feeling that there has to be an easier way! I'm sure I just need someone to say "have a look at the xxxx driver, it's all explained perfectly"! Any help much appreciated! Cheers, Steve Sharples.
Received on 2004-04-06Z10:00:13