Mark Whitis's Website

CIO-DAS1600 Driver for Linux

I have developed a device driver for the CIO-DAS1600 series of Data Acquisition cards for the linux operating system. This should work with little or no modifications on other compatible cards from Computer boards, CyberResearch, Metrabyte and possibly others.

This driver was commissioned by John Walker, a muscle physiology researcher in the Murphy Lab at the University of Virginia School of Medicine, Department of molecular physiology in order to facilitate his research on smooth muscles (the kind of muscles found in blood vessels and internal organs as opposed to skeletal muscles (the kind you use to lift things) or cardiac muscles (heart)).

Driver Features

At the time this driver was written, there were no drivers availible which would satisfy the needs of the experiment. There were other drivers for similar (in some cases, fairly compatible) hardware. If you need merely to use your data acquisition card as a single channel oscilloscope at the maximum sample rate, one of these other drivers may be for you. If you need simultaneous, synchronized input and output with millisecond timing accuracy then this driver may be for you.

1 Khz simultaneous, synchronized input and output

The driver can output 2 channels of Analog stimulus, 4 bits of digital data, and 1 pulse width modulated output while reading 16 channels of analog input and 4 bits of digital input. The driver infrastructure also supports an additional 24 bits of digital input and output but support for the 8255 PIA chip has not been implemented.

Continuous data transfer

Some drivers support high speed transfer but as soon as the buffer is full, you have to stop. This driver uses FIFO's, implemented as ring buffers, for the communications between kernel and user space.

No DMA required

Standard PC DMA (as opposed to busmaster DMA) is pretty dreadful. It is slow, although fast enough for this application. While it lowers CPU usage somewhat, it does not reduce interrupt latency requirements for continuous data transfer unless you use two DMA channels in a hardware assisted ping-pong configuration instead of one for each data stream; when you fill up a buffer, you need to switch to a new buffer before the next byte of data is availible. PC DMA channels are a limited resource. And since this board only gives you two choices for DMA channel (channels 1 and 3), the potential for conflicts nears certainty.

Synchronization features

Interleaved Data Streams
Many driver implementations have separate devices, and therefore separate data streams, for each analog input and output channel; these implementations often cannot handle acquisition on more than one simultaneous channel and even if they could, such use could easily yield corrupted data. Separate data streams could easily get out of sync and it would be more difficult to detect loss of sync and re-establish sync.
Magic number in input/output data streams detects loss of synchronization due to bufer overflow or underflow or programming error and permits resynchronization.
Output data is included in input data stream.
Connecting outputs to unused analog input channels is encouraged
One output bit provides a status output which can be used to measure interrupt latency and interrupt service routine duration. Connecting this output to an oscilloscope/counter has proved to be very useful during development and testing and is recommended for initial setup as well.
Kernel messages can be enabled whenever a buffer overflow or underflow occurs.
User sync
The user has one 32 bit word of arbitrary data which is included copied from the output data stream to the input data stream. This can be used to detect any data loss, as a trigger, and to communicate additional status, often simultaneously. A simple use of this is to put a value of -1 on the first sample, -2 on the last, and 0,1,2,3... on all values in between. Values of -3, and -4 could be used for constant baseline values output for a period of time before the actual test data. This simple scheme works for over 2 billion samples (23 days at 1khz sample rate). In addition to detecting any lost data, it is easy to locate the beginning and end of a stimulus/response data stream. For more complicated requirements, subcodes could be used (some of the bits are read from succeeding samples) to encode additional data while still being able to detect any lost samples.
IOCTLs have been implemented to stop the data acquisition hardware, clear the buffers in the driver, and restart the data acquistion hardware.

Works with standard Linux Kernels

No kernel patches are needed.

Loadable Kernel Module

The driver was implemented as a Loadable Kernel Module. This offers many advantages:

No need to recompile kernel
Code does not need to be GPL tainted.
No need to reboot to install or remove driver
New versions of the driver can be loaded on the fly

Performance

The driver has been tested at a 1Khz on 486 and pentium systems. It can go faster although hardware limits would prevent coordinated operation above a few khz. Due to a serious design flaw in the board, CPU load is significant at rates above 1Khz. At 1Khz, expect about 20% CPU utlization by the driver itself (due to a hardware design flaw workaround). Reducing the number of A/D channels sampled would permit higher speeds. Maximum interrupt latency is normally less than 70us with standard hardware, which also sets an upper limit. With four channels, sampled at 10us intervals (total 40us), 10us extra delay( i.e. 50us total) for reliabliity, and a maximum interrupt latency of 70 us, this driver could be used to sample at around 6khz using about 30% of the CPU cycles. This driver could increase interrupt latency for other drivers.

Burst Mode

All A/D conversions are performed in burst mode. If you want to sample 16 channels one thousand times per second with a 10us, there are two basic approaches. With a simpler board (but with onboard timing), you simply program the board to sample at 16Khz. But this results in a significant skew between channels; two conceptually "simultaneous" readings on two different channels can be almost a full millisecond (937.5us) apart in time. With burst mode, you program the board to take 16 samples at 10us intervals and then wait 840us before the next burst. This makes the maximum skew between two channels 150us, over a sixfold improvement in this example.

Copyright

This code is not GPL tainted. This means, among other things, that it may ported to other operating systems such as *BSD.

Downloading

Download das1600 driver source .

Installation

...

Usage

...

Notes

I was unable to get this board to work with the manufacturers supplied diagnostic software (which apparently used DMA) on two separate systems. In fact, I wasted more time trying unsuccesfully to get the manufacturers proprietary diagnostics to work than I spent writing the linux device driver.

The non-dma approach improves reliability/compatibity but it carries a significant CPU overhead penalty; this is due to an undocument design defect in the hardware. There is a interrupt flip flop on the board which must be reset at the _conclusion_ of each A/D burst but the CPU interrupt occurs at the _beginning_ of the A/D burst. If you do not reset the flip flop in your interrupt service routine, you will never get another interrupt but if you reset it too soon, you will abort the current A/D burst. In addition, if you read the data before the burst completes you will get invalid data and lose sync with the FIFO, although you can work around that by not reading any data from the FIFO the first time the interrupt service routine is called. To make matters worse, there does not appear to be any reasonable way to determine from the status flags when a burst is complete; a time delay is necessary.