Fwd: Re: mmap'd streaming acquisition

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?).

If the buffer overflows, then the streaming is stopped. Is there some
way to change this behavior to something more like a true circular
buffer (where new data overwrites old without stopping the acquisition),
so I don't need to keep calling comedi_mark_buffer_read()? 

I'm using comedi_get_buffer_contents() + comedi_get_buffer_offset() to
get the location of the most recently acquisred buffer-data. I then scan
from the last scanned point up to this new point for a
trigger-condition. Thus a comedi function to get the position of the
front data would be more elegant.

Are there any plans for including such "software triggering"
functionality into comedi / comedilibs?

Bryan

On Tue, 2002-08-06 at 20:35, David Schleef wrote:
> On Tue, Aug 06, 2002 at 05:07:11PM +0100, bryan cole wrote:
> > Is the comedi_get_front_count()
> > function still part of the comedi API?
> 
> No, but it will be eventually.  The code is in comedilib, but the
> name is dumb.
> 
> You always have the option of calling the bufinfo ioctl() directly,
> which will provide all the information you need.  I would appreciate
> feedback on the information you actually use, in order to provide
> a small set of useful functions, rather than 42 randomly named
> functions that are all tiny wrappers around a bufinfo ioctl.
> 
> 
> 
> dave...

Received on 2002-08-07Z08:46:39