Comedi

The Control and Measurement Device Interface handbook

David Schleef

        ds@schleef.org
      

Frank Hess

        fmhess@users.sourceforge.net
      

Herman Bruyninckx

        Herman.Bruyninckx@mech.kuleuven.ac.be
      

Abstract

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
1. Overview
1.1. What is a "device driver"?
1.2. Policy vs. mechanism
1.3. A general DAQ device driver package
1.4. DAQ signals
1.5. Device hierarchy
1.6. Acquisition terminology
1.7. DAQ functions
1.8. Supporting functionality
2. Configuration
2.1. Configuration
2.2. Getting information about a card
3. Writing Comedi programs
3.1. Your first Comedi program
3.2. Converting samples to voltages
3.3. Using the file interface
3.4. Your second Comedi program: simple acquisition
3.5. Your third Comedi program: instructions
3.6. Your fourth Comedi program: commands
4. Acquisition and configuration functions
4.1. Functions for single acquisition
4.1.1. Single digital acquisition
4.1.2. Single analog acquisition
4.2. Instructions for multiple acquisitions
4.2.1. The instruction data structure
4.2.2. Instruction execution
4.3. Instructions for configuration
4.4. Instruction for internal triggering
4.5. Commands for streaming acquisition
4.5.1. Executing a command
4.5.2. The command data structure
4.5.3. The command trigger events
4.5.4. The command flags
4.5.5. Anti-aliasing
4.6. Slowly-varying inputs
4.7. Experimental functionality
4.7.1. Digital input combining machines
4.7.2. Analog filtering configuration
4.7.3. Analog Output Waveform Generation
4.7.4. Extended Triggering
4.7.5. Analog Triggering
4.7.6. Bitfield Pattern Matching Extended Trigger
4.7.7. Counter configuration
4.7.8. One source plus auxiliary counter configuration
5. Writing a Comedi driver
5.1. Communication user space-kernel space
5.2. Generic functionality
5.2.1. Data structures
5.2.2. Generic driver support functions
5.3. Board-specific functionality
5.4. Callbacks, events and interrupts
5.5. Device driver caveats
5.6. Integrating the driver in the Comedi library
6. Low-level drivers
6.1. Low-level drivers
6.1.1. 8255.o -- generic 8255 support
6.1.2. adl_pci9111.o -- Driver for the Adlink PCI-9111HR card.
6.1.3. adl_pci9118.o -- Adlink PCI-9118DG, PCI-9118HG, PCI-9118HR
6.1.4. adv_pci1710.o -- Advantech PCI-1710, PCI-1710HG, PCI-1711, PCI-1713, Advantech PCI-1720, PCI-1731
6.1.5. amplc_pc236.o -- Driver for Amplicon PC36AT and PCI236 DIO boards
6.1.6. amplc_pc263.o -- Driver for Amplicon PC263 and PCI263 Relay boards
6.1.7. amplc_pci230.o -- Driver for Amplicom PCI230 and PCI260 Multifunction I/O boards
6.1.8. cb_pcidas.o -- Driver for the ComputerBoards/MeasurementComputing cards of the PCI-DAS series with the AMCC S5933 PCI controller.
6.1.9. cb_pcidas64.o -- Driver for the ComputerBoards/MeasurementComputing PCI-DAS64xx, 60XX, and 4020 series with the PLX 9080 PCI controller.
6.1.10. cb_pcidda.o -- ComputerBoards/MeasurementComputing PCI-DDA series
6.1.11. cb_pcimdda.o -- A driver for this relatively new and uniquely designed board
6.1.12. comedi_parport.o -- Standard PC parallel port
6.1.13. comedi_rt_timer.o -- Command emulator using real-time tasks
6.1.14. comedi_test.o -- generates fake waveforms
6.1.15. contec_pci_dio.o -- Driver for Contec PIO1616L digital io board
6.1.16. daqboard2000.o -- IOTech DAQBoard/2000
6.1.17. das08.o -- DAS-08 compatible boards
6.1.18. das16.o -- DAS16 compatible boards
6.1.19. das16m1.o -- CIO-DAS16/M1
6.1.20. das1800.o -- Keithley Metrabyte DAS1800 (& compatibles)
6.1.21. das6402.o -- Keithley Metrabyte DAS6402 (& compatibles)
6.1.22. das800.o -- Keithley Metrabyte DAS800 (& compatibles)
6.1.23. dt2801.o -- Data Translation DT2801 series and DT01-EZ
6.1.24. dt2811.o -- Data Translation DT2811
6.1.25. dt2814.o -- Data Translation DT2814
6.1.26. dt2815.o -- Data Translation DT2815
6.1.27. dt2817.o -- Data Translation DT2817
6.1.28. dt282x.o -- Data Translation DT2821 series (including DT-EZ)
6.1.29. dt3000.o -- Data Translation DT3000 series
6.1.30. fl512.o -- unknown
6.1.31. icp_multi.o -- Inova ICP_MULTI
6.1.32. ii_pci20kc.o -- Intelligent Instruments PCI-20001C carrier board
6.1.33. ke_counter.o -- Driver for Kolter Electronic Counter Card
6.1.34. me_daq.o -- Driver for the Meilhaus PCI data acquisition cards.
6.1.35. mpc8260cpm.o -- MPC8260 CPM module generic digital I/O lines
6.1.36. multiq3.o -- Quanser Consulting MultiQ-3
6.1.37. ni_670x.o -- National Instruments 670x
6.1.38. ni_at_a2150.o -- National Instruments AT-A2150
6.1.39. ni_at_ao.o -- National Instruments AT-AO-6/10
6.1.40. ni_atmio.o -- National Instruments AT-MIO-E series
6.1.41. ni_atmio16d.o -- National Instruments AT-MIO-16D
6.1.42. ni_daq_dio24.o -- National Instruments PCMCIA DAQ-Card DIO-24
6.1.43. ni_labpc.o -- National Instruments Lab-PC (& compatibles)
6.1.44. ni_mio_cs.o -- National Instruments DAQCard E series
6.1.45. ni_pcidio.o -- National Instruments PCI-DIO32HS, PCI-DIO96, PCI-6533, PCI-6503
6.1.46. ni_pcimio.o -- National Instruments PCI-MIO-E series (all boards)
6.1.47. pcl711.o -- Advantech PCL-711 and 711b, ADLink ACL-8112
6.1.48. pcl724.o -- Advantech PCL-724, PCL-722, PCL-731 ADLink ACL-7122, ACL-7124, PET-48DIO
6.1.49. pcl725.o -- Advantech PCL-725 (& compatibles)
6.1.50. pcl726.o -- Advantech PCL-726 & compatibles
6.1.51. pcl812.o -- Advantech PCL-812/PG, PCL-813/B, ADLink ACL-8112DG/HG/PG, ACL-8113, ACL-8216, ICP DAS A-821PGH/PGL/PGL-NDA, A-822PGH/PGL, A-823PGH/PGL, A-826PG, ICP DAS ISO-813
6.1.52. pcl816.o -- Advantech PCL-816 cards, PCL-814
6.1.53. pcl818.o -- Advantech PCL-818 cards, PCL-718
6.1.54. pcm3730.o -- PCM3730
6.1.55. pcmad.o -- Winsystems PCM-A/D12, PCM-A/D16
6.1.56. poc.o -- Generic driver for very simple devices Device names: dac02
6.1.57. quatech_daqp_cs.o -- Quatech DAQP PCMCIA data capture cards
6.1.58. rtd520.o -- Real Time Devices PCI4520/DM7520
6.1.59. rti800.o -- Analog Devices RTI-800/815
6.1.60. rti802.o -- Analog Devices RTI-802
6.1.61. serial2002.o -- Driver for serial connected hardware
6.1.62. skel.o -- Skeleton driver, an example for driver writers
6.1.63. ssv_dnp.o -- SSV Embedded Systems DIL/Net-PC
7. Comedi Reference
7.1. Headerfiles: comedi.h and comedilib.h
7.2. Constants and Macros
7.2.1. CR_PACK
7.2.2. RANGE_LENGTH (deprecated)
7.3. Data Types and Structures
7.3.1. subdevice_struct
7.3.2. comedi_devinfo
7.3.3. comedi_t
7.3.4. sampl_t
7.3.5. lsampl_t
7.3.6. comedi_trig (deprecated)
7.3.7. comedi_sv_t
7.3.8. comedi_cmd
7.3.9. comedi_insn
7.3.10. comedi_range
7.3.11. comedi_krange
7.3.12. comedi_insnlist
7.4. Comedi Function Reference
comedi_close -- close a Comedi device
comedi_open -- open a Comedi device
comedi_loglevel -- change Comedilib logging properties
comedi_perror -- print a Comedilib error message
comedi_strerror -- return string describing Comedilib error code
comedi_errno -- number of last Comedilib error
comedi_fileno -- integer descriptor of Comedilib device
comedi_get_n_subdevices -- number of subdevices
comedi_get_version_code -- Comedi version code
comedi_get_driver_name -- Comedi driver name
comedi_get_board_name -- Comedi device name
comedi_get_subdevice_type -- type of subdevice
comedi_find_subdevice_by_type -- search for subdevice type
comedi_get_read_subdevice -- find streaming input subdevice
comedi_get_write_subdevice -- find streaming output subdevice
comedi_get_subdevice_flags -- properties of subdevice
comedi_get_n_channels -- number of subdevice channels
comedi_range_is_chan_specific -- range information depends on channel
comedi_maxdata_is_chan_specific -- maximum sample depends on channel
comedi_get_maxdata -- maximum sample of channel
comedi_get_n_ranges -- number of ranges of channel
comedi_get_range -- range information of channel
comedi_find_range -- search for range
comedi_get_buffer_size -- streaming buffer size of subdevice
comedi_get_max_buffer_size -- maximum streaming buffer size
comedi_set_buffer_size -- streaming buffer size of subdevice
comedi_trigger -- perform streaming input/output (deprecated)
comedi_do_insnlist -- perform multiple instructions
comedi_do_insn -- perform instruction
comedi_lock -- subdevice reservation
comedi_unlock -- subdevice reservation
comedi_to_phys -- convert sample to physical units
comedi_from_phys -- convert physical units to sample
comedi_data_read -- read single sample from channel
comedi_data_read_delayed -- read single sample from channel after delaying for specified settling time
comedi_data_read_hint -- tell driver which channel/range/aref you are going to read from next
comedi_data_write -- write single sample to channel
comedi_dio_config -- change input/output properties of channel
comedi_dio_read -- read single bit from digital channel
comedi_dio_write -- write single bit to digital channel
comedi_dio_bitfield -- read/write multiple digital channels
comedi_sv_init -- slowly-varying inputs
comedi_sv_update -- slowly-varying inputs
comedi_sv_measure -- slowly-varying inputs
comedi_get_cmd_src_mask -- streaming input/output capabilities
comedi_get_cmd_generic_timed -- streaming input/output capabilities
comedi_cancel -- stop streaming input/output in progress
comedi_command -- start streaming input/output
comedi_command_test -- test streaming input/output configuration
comedi_poll -- force updating of streaming buffer
comedi_set_max_buffer_size -- streaming buffer size of subdevice
comedi_get_buffer_contents -- streaming buffer status
comedi_mark_buffer_read -- streaming buffer status
comedi_get_buffer_offset -- streaming buffer status
comedi_get_timer -- timer information (deprecated)
comedi_timed_1chan -- streaming input (deprecated)
comedi_set_global_oor_behavior -- out-of-range behavior
comedi_apply_calibration -- set calibration from file
comedi_apply_parsed_calibration -- set calibration from memory
comedi_cleanup_calibration_file -- free calibration resources
comedi_get_default_calibration_path -- get default calibration file path
comedi_parse_calibration_file -- set calibration
Glossary

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 project's source code is distributed in two packages, comedi and comedilib, and provides several Linux kernel modules and a user space library:

Comedi works with standard Linux kernels, but also with its real-time extensions RTAI and RTLinux/Free.

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.

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 Linux-specific issues in mind:

  • Kernel space vs. User space. The Linux operating system has two levels that require basically 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 Comedi, while Comedi device driver writers use the API offered by Kcomedilib. Typical examples of the latter are the registration of interrupt handler routines, and the handling of events.

  • 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 (2.2.x kernels or earlier) or /devfs directory (2.4.x kernels and later). Each device supported in the kernel has a representative as such a user space device file, and its functionality can be accessed by classical Unix file I/O: open, close, read, write, and ioctl.

  • /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/Free 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/Free 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, counter 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 and +10V); the card's electronics can be programmed to automatically sample a set of channels, in a prescribed order, to buffer sequences of data on the board; or to use DMA or an interrupt routine to dump the data in a prescribed part of memory.

  • 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.

1.5. Device hierarchy

Comedi organizes all hardware according to the following generic 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. Each channel has several parameters, such as: the voltage range; the reference voltage; the channel polarity (unipolar, bipolar); a conversion factor between voltages and physical units; the binary values "0" and "1"; etc.

  • Sub-device: a set of functionally identical channels that are physically implemented on the same (chip on an) interface card. For example, a set of 16 identical analog outputs. Each sub-device has parameters for: the number of channel and the type of the channels.

  • Device: a set of sub-devices 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 sub-device with 16 analog input channels, another sub-device with two analog output channels, and a third sub-device with eight digital inputs/outputs. Each device has parameters for: the device identification tag from the manufacturer, the identification tag given by the operating system (in order to discriminate between multiple interface cards of the same type), the number of sub-devices, etc.

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.

1.6. Acquisition terminology

This Section introduces the terminology that this document uses when talking about "acquisitions." Figure 1 depicts a typical acquisition sequence:

  • 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, each hardware has limits on the minimum conversion interval it can achieve, i.e., the minimum time it needs between subsequent conversions.

    Some hardware must multiplex the conversions onto one single AD/DA hardware, such that the conversions are done serially in time (as shown on the Figure); other cards have the hardware to do two or more acquisitions in parallel. The begin of each conversion is "triggered" by some internally or externally generated pulse, e.g., a timer.

In general, not only the begin of a conversion is triggered, but also the begin 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 to specify the channel list, i.e., the sequence of channels that needs to be acquired during each scan.

Figure 1. Acquisition sequence. (Figure courtesy of Kurt Mueller.)

1.7. DAQ functions

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 channel: comedi_data_read(), comedi_data_write(), comedi_dio_read(), comedi_dio_write(). "Synchronous" means that the calling process blocks until the data acquisition has finished.

  • Instruction: a comedi_do_insn() instruction performs (possibly multiple) data acquisitions on a specified channel, in a synchronous way. So, the function call blocks until the whole acquisition has finished.

    In addition, comedi_do_insnlist() executes a list of instructions (on different channels) in one single (blocking, synchronous) call, such that the overhead involved in configuring each individual acquisition is reduced.

  • Scan: a scan is an acquisition on a set of different channels, with a specified sequence and timing.

    Scans are not directly available as stand-alone function calls in the Comedi API. They are the internal building blocks of a Comedi command (see below).

  • Command: a command is sequence of scans, for which conditions have been specified that determine when the acquisition will start and stop. A comedi_command() function call generates 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 the timing of the data acquisition, and makes sure that the acquired data is delivered in a software buffer provided by the calling process. Asynchronous operation requires some form of "callback" functionality to prevent buffer overflow: after the calling process has launched the acquisition command, it goes off doing other things, but not after it has configured the "handler" that the interface card can use when it needs to put data in the calling process's buffer. Interrupt routines or DMA are typical techniques to allow such asynchronous operation. Their handlers are configured at driver load time, and can typically not be altered from user space.

    Buffer management is not the only asynchronous activity: a running acquisition must eventually be stopped too, or it must be started after the comedi_command() function call has prepared (but not started) the hardware for the acquisition. The command functionality is very configurable with respect to choosing which events will signal the starting or stopping of the programmed acquisition: external triggers, internal triggers, end of scan interrupts, timers, etc. The user of the driver can execute a Comedi instruction that sends a trigger signal to the device driver. What the driver does exactly with this trigger signal is determined in the specific driver. For example, it starts or stops the ongoing acquisition. The execution of the event associated with this trigger instruction is synchronous with the execution of the trigger instruction in the device driver, but it is asynchronous with respect to the instruction or command that initiated the current acquisition.

    Typically, there is one synchronous triggering instruction for each subdevice.

Note that software triggering is only relevant for commands, and not for instructions: instructions are executed synchronously in the sense that the instruction call blocks until the whole instruction has finished. The command call, on the other hand, activates an acquisition and returns before this acquisition has finished. So, the software trigger works asynchronously for the ongoing acquisition.

1.8. Supporting functionality

The full command functionality cannot be offered by DAQ cards that lack the hardware to autonomously sequence a series of scans, and/or to support interrupt or DMA callback functionality. For these cards, the command functionality must 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. Such a correct translation is the responsibility of the device driver developer for the card. However, Comedi provides the comedi_rt_timer kernel 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 on-line 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. Therefore, Comedi offers all functionality to configure and manage data buffers, abstracting away the intricacies of buffer management at the bare operating system level.

As already mentioned before, Comedi contains more than just procedural function calls, since it also offers event-driven ("asynchronous") functionality: the data acquisition can signal its completion by means of an interrupt or a callback function call. Callbacks are also used to signal errors during the data acquisition or when writing to buffers, or at the end of a scan or acquisition that has been launched previously to take place asynchronously (i.e., the card fills up som shared memory buffer autonomously, and only warns the user program after it has finished). The mechanisms for synchronization and interrupt handling are a bit different when used in real-time (RTAI or RTLinux/Free) or non real-time, but both contexts are encapsulated wihting the same Comedi calls.

Because multiple devices can all be active at the same time, Comedi provides locking primitives to ensure atomic operations on critical sections of the code or data structures.

Finally, Comedi offers the previously mentioned "high-level" interaction, i.e., at the level of user space device drivers, through file operations on entries in the /dev directory (for access to the device's functionality), or interactively from the command line through the "files" in the /proc directory (which allow to inspect the status of a Comedi device).