Specifications

Comedi
1 / 148
1 Overview
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 (called ‘comedi’)
providing common functionality, and (ii) individual low-level driver modules for each device.
• 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
real-time tasks.
Comedi works with standard Linux kernels, but also with its real-time extensions RTAI and RTLinux/GPL.
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.
1.1 What is a ‘device driver’?
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.
1.2 Policy vs. mechanism
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.