![[*]](file:/usr/lib/latex2html/icons/footnote.png){kind=icon}
A. Driescher
After reading this document you will find answers to the questions of how
The goal is to support high speed data acquisition in a none real-time Linux environment as easy as possible. To accomplish this goal different design decisions had to be made:
The device driver design is based on the ``normal'' understanding of the Linux file system interface. This means that read aud write are used to read data from the analog to digital converter or write new values to the digital analog converter, respectively. How exactly the data conversion is handled can be set by the ioctl system call of the driver. This mean for instance that a command like
cat /dev/me2600_aio | gzip my_datacould be used to read date from the device driver and write these data in compressed format to a file that could be processed later on.
typedef struct{
// header for all blocks
unsigned int block_size; /* size of this struct */
unsigned int driver_version; /* internal version number of this driver */
unsigned int block_sequence_number; /* sequence number of this block */
block_type type; /* type of data block */
// variant data block dependig on "type"
union {
unsigned int data_sequence_number; /* sequence number within this block type */
adc_data_v1 adc_v1;
dio_data_v1 dio_v1;
event_data_v1 event_v1;
} data;
} block_struct;
A central problem is the assignment of time stamps to the measurement. The me2600 hardware does not automatically assign time stamps to measurements. The nearest thing to a time stamp is the interrupt time generated by the hardware for the ``convertion ready event''. Naturally, the jitter is therefore based on the interrupt latency in your computer. The me2600 can generate two different conversion ready interrupts. The first is after a single conversion is ready; the second is given at the FIFO half full event. While for small sample frequencies one interrupt per conversion is no problem, the hardware can support a sample frequency up to 300KHz. Without real time kernel extentions this interrupt rate is unlikely to work reliable. In this case it is certainly more appropriate to generate an interrupt after the FIFO is half full to reduce the interrupt frequency to something the kernel can handle.
Depending on how fast the computer is, how high the system load is and what interrupt has been choosen by the user, data can be lost due to some overflow condidition either in the onboard ADC-FIFO or the driver's ring buffer. What exactly the best error handling strategy is, is application depending. The driver supports error detection by:
The internal data processing algorithm at interrupt time is as follows:
analog output channels. Each channel can be independently configured
to one of the following output ranges:
,
or
.
A ioctl command is provided by the device driver to configure the channels according to
your needs.
To change the output of one or more of the channels you have to write a struct to the device interface that looks like that:
// definition of possible data block types for write interface
typedef enum{do_block_v1, da_block_v1} write_block_type;
typedef struct{
// header for all blocks
unsigned int block_size; /* size of this struct */
write_block_type type; /* type of data block */
union {
do_data_v1 do_v1;
da_data_v1 da_v1;
} data;
} write_block_struct;
where da_v1 contains the data for the channels. This struct is defined by:
typedef struct{
short value[ME2600_NUM_DA]; // value to write to the DA
me2600_bool valid[ME2600_NUM_DA]; // !=0 -> update the corresponding port
me2600_bool update_now; // True=update DAC in buffered mode, ignored in transparent mode
} da_data_v1;
So, programming the DAC boils down to:
for differential mode.
Every time an application tries to read data from the driver the conversion is
automatically started. So, the read timing simply depends on
when the caller reads data from the driver. In this mode all 8
channels are used resulting in a conversion time of
because every channel needs 10 clocks generated
by the me2600 oscillator at 
to finish its conversion.
The sample frequency and timing accuracy depends only on the caller as
long as the required conversion time plus a small processing overhead
in the device driver can be neglected. Due to the none-real-time
characteristic of Linux, sample frequencies larger than
are difficult to manage with this driver
configuration as long as a reasonable small timing jitter is required.
The driver supports this mode by allowing the user to setup the number of requested samples and the sample frequency.
Due to a hardware bug in the me2600 the driver has to wait until at
least 
samples have arrived (FIFO half-full interrupt) even if
you have requested a smaller number of samples. This can cause an
undesired latency time that is especially relevant for smaller sample
frequencies.
Example:
Let's say you want a sample frequency of
. Assuming
channels are sampled, the latency is
plus conversion time. This means that the conversion result will at
the earliest be available after 
even if you only need
sample. The work around is to increase the sample frequency until
an acceptable latency time is reached and than throw away unnecessary
data.
The latency
concideration from section ![[*]](file:/usr/lib/latex2html/icons/crossref.png){kind=icon}
hold for this mode
as well but are usually of less importance because this mode is
usually used with high sample rates.
This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.43)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 technical_overview.tex
The translation was initiated by Arne Driescher on 2003-06-06