Quoting Christian Kuhtz <ck@gnu.org>:

> Gregory McGarry wrote:
> > I've got some PCI and VME acquisition boards I'm currently looking
> > at supporting.  So I'm looking at doing a machine-independent
> interface.

What's more, any such specialist domain is usually currently in the grip of lame
overpriced vendor-tiein interfaces (lots of acquisition boards I see for sale
here and there have their own special Windows program for data capture that
outputs CSV or works via OLE to Excel, for example), so a strong open source
offering for data capture on NetBSD could be *very* popular in that niche.

[API design questions]

I design APIs for a living and would be glad to help.

I see the fundamental interface required by software for these sampling devices
(be they sampling levels or counters that keep going up or counters that reset
on each read - the data model can be borrowed from SNMP!) is to have a buffer
from which can be read a series of timestamped samples. Eg, your application can
block on the port and be awoken on every arriving sample, or if it gets
distracted and they queue up, can still retrieve them all with kernel-generated
timestamps, giving the application the best possible position to catch up on its
data processing from. Timestamping of all samples at the point of reading will
be the best for accuracy.

The API I would want as a developer would be to be able to open
/dev/capture[0-9]+ and use ioctls to:

1) Query available sampling rates, returned as a list of ranges. Some devices
will have a few fixed sampling rates, so ranges of length one will be accepted.
Some devices will have a fixed sampling rate.

2) Query most recent sample, minimum sample since reset, and maximum sample
since reset. regardless of the queuing of regular samples. Handy for providing
an onscreen indication of status that updates every second or whatever.

3) Get the sampling device type - is it a level of something, an event counter
that resets every $currentsamplerate, an event counter that resets when told to,
or a digital interface where each bit of the sample is an independent channel?
Are the samples 16 bit, 32 bit, or 64 bit - a limited choice that affects the
size of the word read from the sample stream? How many bits of those are
actually significant - many devices are 12 bit ADCs or have 8 digital channels
etc.

If you open the device for writing (which only one process can do, although any
number may open it for reading at the same time as it is open for writing) you
can also:

1) Reset the counter, if it's an explicitly resettable counter. This also resets
min/max sample registers.

2) Request that the device start capturing, given a sample rate from the
acceptable ranges. This means that actual read()s from the device will return
sample records which get queued at the appropriate frequency.

3) Request that the device stop capturing.

A "sample record" would consist of a timestamp in whatever format we already
have for high accuracy timers (there is one I'm sure) followed by however many
bits of sample.

Whether the device provides data via DMA, polling from the kernel, or IRQs
wouldn't matter at this level.

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software