Copyright © 1998-2003 David Schleef
Copyright © 2001-2003, 2005, 2008 Frank Mori Hess
Copyright © 2002-2003 Herman Bruyninckx
Copyright © 2012 Bernd Porr
Copyright © 2012 Ian Abbott
Copyright © 2012 Éric Piel
This document is part of Comedilib. In the context of this document, the term "source code" as defined by the license is interpreted as the XML source.
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, version 2.1 of the License.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
Comedi is a free software project to interface digital acquisition (DAQ) cards. It is the combination of three complementary software items: (i) a generic, device-independent API, (ii) a collection of Linux kernel modules that implement this API for a wide range of cards, and (iii) a Linux user space library with a developer-oriented programming interface to configure and use the cards.
Table of Contents
Comedi is a free software project that develops drivers, tools, and libraries for various forms of data acquisition: reading and writing of analog signals; reading and writing of digital inputs/outputs; pulse and frequency counting; pulse generation; reading encoders; etc. The source code is distributed in two main packages, comedi and comedilib:
Comedi is a collection of drivers for a variety
of common data acquisition plug-in boards (which are called
“devices” in Comedi terminology). The drivers are
implemented as the combination of (i) one single core Linux kernel module
comedi”) providing common
functionality, and (ii) individual low-level driver modules for
Comedilib is a separately distributed package containing a user-space library that provides a developer-friendly interface to the Comedi devices. Included in the Comedilib package are documentation, configuration and calibration utilities, and demonstration programs.
Kcomedilib is a Linux kernel module
(distributed with the
comedi package) that provides
the same interface as comedilib in kernel space,
and suitable for use by real-time kernel modules. It is
effectively a “kernel library” for using Comedi from
This section gives a high-level introduction to which functionality you can expect from the software. More technical details and programming examples are given in the following sections of this document.
A device driver is a piece of software that interfaces a particular piece of hardware: a printer, a sound card, a motor drive, etc. It translates the primitive, device-dependent commands with which the hardware manufacturer allows you to configure, read and write the electronics of the hardware interface into more abstract and generic function calls and data structures for the application programmer.
David Schleef started the Comedi project to put a generic interface on top of lots of different cards for measurement and control purposes. This type of cards are often called data acquisition (or DAQ) cards.
Analog input and output cards were the first goal of the project, but now Comedi also provides a device independent interface to digital input and output cards, and counter and timer cards (including encoders, pulse generators, frequency and pulse timers, etc.).
Schleef designed a structure which is a balance between modularity and complexity: it's fairly easy to integrate a new card because most of the infrastructure part of other, similar drivers can be reused, and learning the generic and hence somewhat “heavier” Comedi API doesn't scare away new contributors from integrating their drivers into the Comedi framework.
Device drivers are often written by application programmers, that have only their particular application in mind; especially in real-time applications. For example, one writes a driver for the parallel port, because one wants to use it to generate pulses that drive a stepper motor. This approach often leads to device drivers that depend too much on that particular application, and are not general enough to be re-used for other applications. One golden rule for the device driver writer is to separate mechanism and policy:
Mechanism. The mechanism part of the device interface is a faithful representation of the bare functionality of the device, independent of what part of the functionality an application will use.
Policy. Once a device driver offers a software interface to the mechanism of the device, an application writer can use this mechanism interface to use the device in one particular fashion. That is, some of the data stuctures offered by the mechanism are interpreted in specific physical units, or some of them are taken together because this composition is relevant for the application. For example, a analog output card can be used to generate voltages that are the inputs for the electronic drivers of the motors of a robot; these voltages can be interpreted as setpoints for the desired velocity of these motors, and six of them are taken together to steer one particular robot with six-degrees of freedom. Some of the other outputs of the same physical device can be used by another application program, for example to generate a sine wave that drives a vibration shaker.
So, Comedi focuses only on the mechanism part of DAQ interfacing. The project does not provide the policy parts, such as Graphical User Interfaces to program and display acquisitions, signal processing libraries, or control algorithms.
From the point of view of application developers, there are many reasons to welcome the standardization of the API and the architectural structure of DAQ software:
API: devices that offer similar functionalities, should have the same software interface, and their differences should be coped with by parameterizing the interfaces, not by changing the interface for each new device in the family. However, the DAQ manufacturers have never been able (or willing) to come up with such a standardization effort themselves.
Architectural structure: many electronic interfaces have more than one layer of functionality between the hardware and the operating system, and the device driver code should reflect this fact. For example, many different interface cards use the same PCI driver chips, or use the parallel port as an intermediate means to connect to the hardware device. Hence, “lower-level” device drivers for these PCI chips and parallel ports allow for an increased modularity and re-useability of the software. Finding the generic similarities and structure among different cards helps in developing device drivers faster and with better documentation.
In the case of Linux as the host operating system, device driver writers must keep the following issues in mind:
Kernel space vs. User space. The Linux operating system has two levels that require different programming approaches. Only privileged processes can run in the kernel, where they have access to all hardware and to all kernel data structures. Normal application programs can run their processes only in user space, where these processes are shielded from each other, and from direct access to hardware and to critical data of the operating system; these user space programs execute much of the operating system's functionality through system calls.
Device drivers typically must access specific addresses on the bus, and hence must (at least partially) run in kernel space. Normal users program against the API of the Comedilib user-space library. Comedilib then handles the necessary communication with the Comedi modules running in kernel-space.
Device files or device file system.
Users who write an application for a particular device,
must link their application to that device's device driver. Part of
this device driver, however, runs in kernel space, and the user
application in user space. So, the operating system provides an
interface between both. In Linux or Unix, these interfaces are in the
form of “files”
Each device supported in the kernel may be
representated as such a user space device file, and its functionality can
may be accessed by classical Unix file I/O:
Linux (and some other UNIX operating systems) offer a file-like
interface to attached devices (and other OS-related information) via
/proc directories. These
“files” do not really exist, but it gives a familiar
interface to users, with which they can inspect the current status of
Direct Memory Access (DMA) vs. Programmed Input/Output (PIO). Almost all devices can be interfaced in PIO mode: the processor is responsible for directly accessing the bus addresses allocated to the device whenever it needs to read or write data. Some devices also allow DMA: the device and the memory “talk” to each other directly, without needing the processor. DMA is a feature of the bus, not of the operating system (which, of course, has to support its processes to use the feature).
Real-time vs. non real-time. If the device is to be used in a RTLinux/GPL or RTAI application, there are a few extra requirements, because not all system calls are available in the kernel of the real-time operating systems RTLinux/GPL or RTAI. The APIs of RTAI and RTLinux/Free differ in different ways, so the Comedi developers have spent a lot of efforts to make generic wrappers to the required RTOS primitives: timers, memory allocation, registration of interrupt handlers, etc.
The cards supported in Comedi have one or more of the following signals: analog input, analog output, digital input, digital output, counters input, counter output, pulse input, pulse output:
Digital signals are conceptually quite simple, and don't need much configuration: the number of channels, their addresses on the bus, and their input or output direction.
Analog signals are a bit more complicated. Typically, an analog
acquisition channel can be programmed to generate or read a voltage between a
lower and an upper threshold (e.g.,
+10V). The card's electronics may also allow
automatically sampling of a set of channels in a prescribed order.
Pulse-based signals (counters, timers, encoders, etc.) are conceptually only a bit more complex than digital inputs and outputs, in that they only add some timing specifications to the signal. Comedi has still only a limited number of drivers for this kind of signals, although most of the necessary API and support functionality is available.
In addition to these “real” DAQ functions, Comedi also offers basic timer access.
Comedi organizes all hardware according to the following hierarchy:
Channel: the lowest-level hardware component, that represents the properties of one single data channel; for example, an analog input, or a digital output.
Subdevice: a set of functionally identical channels. For example, a set of 16 identical analog inputs.
Device: a set of subdevices that
are physically implemented on the
same interface card; in other words, the interface card itself.
For example, the
National Instruments 6024E
device has a subdevice with 16 analog input channels, another
subdevice with two analog output channels, and a
third subdevice with eight digital inputs/outputs.
Some interface cards have extra components that don't fit in the above-mentioned classification, such as an EEPROM to store configuration and board parameters, or calibration inputs. These special components are also classified as “sub-devices” in Comedi.
This Section introduces the terminology that this document uses when talking about Comedi “commands”, which are streaming asyncronous acquisitions. Figure 1 depicts a typical acquisition sequence when running a command:
The sequence has a start and an end. At both sides, the software and the hardware need some finite initialization or settling time.
The sequence consists of a number of identically repeated scans. This is where the actual data acquisitions are taking place: data is read from the card, or written to it. Each scan also has a begin, an end, and a finite setup time. Possibly, there is also a settling time (“scan delay”) at the end of a scan.
So, the hardware puts a lower boundary (the scan interval) on the minimum time needed to complete a full scan.
Each scan contains one or more conversions on particular channels, i.e., the AD/DA converter is activated on each of the programmed channels, and produces a sample, again in a finite conversion time, starting from the moment in time called the sample time in Figure 1 (sometimes also called the “timestamp”), and caused by a triggering event, called convert.
In addition, some hardware has limits on the minimum conversion interval it can achieve, i.e., the minimum time it needs between subsequent conversions. For example, some A/D hardware must multiplex the conversions from different input channels onto one single A/D converter. Thus the conversions are done serially in time (as shown in Figure 1). Other cards have the hardware to do two or more acquisitions in parallel, and can perform all the conversions in a scan simultaneously. The begin of each conversion is “triggered” by some internally or externally generated pulse, e.g., a timer.
In general, not only the start of a conversion is triggered, but also the start of a scan and of a sequence. Comedi provides the API to configure what triggering source one wants to use in each case. The API also allows you to specify the channel list, i.e., the sequence of channels that needs to be acquired during each scan.
The basic data acquisition functionalities that Comedi offers work on channels, or sets of channels:
Single acquisition: Comedi has
function calls to synchronously perform
one single data acquisition on a specified
comedi_dio_write. In addition,
be used to perform an acquisition.
“Synchronous” means that the calling process blocks until the data acquisition has finished.
Mutiple synchronous acquisition:
performs (possibly multiple) data acquisitions on a specified channel,
in a synchronous way. So, the
function call blocks until the whole acquisition has finished.
The precise timing between the acquisitions is not hardware controlled.
comedi_do_insnlist() executes a
list of instructions in
one single (blocking, synchronous) call, such that the overhead
involved in configuring each individual acquisition is reduced.
Command: a command is
scans, for which conditions have been specified
that determine when the acquisition will start and stop, and
when each conversion in each scan should occur. A
comedi_command function call sets up the
aynchronous data acquisition:
as soon as the command information has been filled in, the
comedi_command function call returns.
The hardware of the card takes care of the sequencing and timing of
the data acquisition as it proceeds.
The command functionality cannot be offered by DAQ cards that
lack the hardware to autonomously sequence a series of
For these cards, the command functionality may be provided in
software. And because of the quite strict real-time requirements for a
command acquisition, a real-time operating system should be used to
translate the command specification into a correctly timed sequence of
instructions. Comedi provides the
module to support such a
virtual command execution under
RTAI or RTLinux/Free.
Comedi not only offers the API to access the functionality of the cards, but also to query the capabilities of the installed devices. That is, a user process can find out what channels are available, and what their physical parameters are (range, direction of input/output, etc.).
Buffering is another important aspect of device drivers: the acquired data has to be stored in such buffers, because, in general, the application program cannot guarantee to always be ready to provide or accept data as soon as the interface board wants to do a read or write operation. Comedi provides internal buffers for data being streamed to/from devices via Comedi commands. The buffer sizes are user-adjustable.