- From: Ray Kelm <rhk_at_newimage.com>
- Date: Fri, 09 Aug 2002 12:13:57 -0400
bryan cole wrote: > Thanks for your help, David! > > I'm trying to re-implement a NI-DAQ (the National Instruments driver set > for their I/O cards) based data-acquisition application on Linux. The > application uses "Conditional Retrieval" I.e. data streams continously > into a circular buffer while one of the channels is continously > monitored (in software) for some trigger-condition. When the trigger > condition occurs a custom call-back function is called by the NI-DAQ > driver. In this callback, I copy the data, centered on the trigger > point, from the circular buffer into a "user-buffer". > > Using Comedi, I've set up a streaming acquisition to a mmap'd buffer but > I must implement the system for continuously monitoring the trigger > channel myself. I have written a function to incrementally scan the > buffer data, but this must be called manually and at regular intervals > to ensure the buffer doesn't overflow. I would like to automate this but > I'm not sure of the best approach (options: 2nd user-process, 2nd thread > in acquisition application, kernel module, others?). I've implemented something similar, and am on my third generation of the code. The first used a kernel module with rtlinux, using a callback that was called whenever data was available. That worked great, but was somewhat overkill. The sample rate was 400k/s. The second generation just used a thread reading data from /dev/comedi0, using select() and read(). This version removed the requirement for rtlinux. The sample rate was still 400k/s. The third generation is just re-packaging the code as C instead of C++, and bumping the sample rate to 1M/s. with a fast PC, mmap should not be necessary. -Ray
Received on 2002-08-09Z15:13:57