Specifications

Comedi
2 / 148
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.
1.3 A general DAQ device driver package
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. Nor-
mal 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’ in the /dev
directory. 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: open(), close(), read(), write(), ioctl(), and mmap().
• /proc interface. Linux (and some other UNIX operating systems) offer a file-like interface to attached devices (and other
OS-related information) via the /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 each device.
• 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.
1.4 DAQ signals
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.