/usr/share/doc/libcomedi-dev/html/index.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>    Comedi
  </TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="NEXT"
TITLE="Configuration"
HREF="x333.html"></HEAD
><BODY
CLASS="ARTICLE"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="ARTICLE"
><DIV
CLASS="TITLEPAGE"
><H1
CLASS="TITLE"
><A
NAME="AEN2"
>Comedi</A
></H1
><H2
CLASS="SUBTITLE"
>The <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>Control and Measurement Device Interface</I
></SPAN
>
handbook</H2
><H3
CLASS="AUTHOR"
><A
NAME="AEN6"
>David Schleef</A
></H3
><DIV
CLASS="AFFILIATION"
><DIV
CLASS="ADDRESS"
><P
CLASS="ADDRESS"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ds@schleef.org<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</P
></DIV
></DIV
><H3
CLASS="AUTHOR"
><A
NAME="AEN11"
>Frank Hess</A
></H3
><DIV
CLASS="AFFILIATION"
><DIV
CLASS="ADDRESS"
><P
CLASS="ADDRESS"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fmhess@users.sourceforge.net<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</P
></DIV
></DIV
><H3
CLASS="AUTHOR"
><A
NAME="AEN16"
>Herman Bruyninckx</A
></H3
><DIV
CLASS="AFFILIATION"
><DIV
CLASS="ADDRESS"
><P
CLASS="ADDRESS"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Herman.Bruyninckx@mech.kuleuven.ac.be<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</P
></DIV
></DIV
><P
CLASS="COPYRIGHT"
>Copyright &copy; 1998-2003 David Schleef</P
><P
CLASS="COPYRIGHT"
>Copyright &copy; 2001-2003, 2005 Frank Mori Hess</P
><P
CLASS="COPYRIGHT"
>Copyright &copy; 2002-2003 Herman Bruyninckx</P
><DIV
><DIV
CLASS="ABSTRACT"
><P
></P
><A
NAME="AEN30"
></A
><P
> <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Abstract</B
></SPAN
>
 </P
><P
><ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> is a free software project to interface
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>digital acquisition</I
></SPAN
> (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.
 </P
><P
></P
></DIV
></DIV
><HR></DIV
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>1. <A
HREF="index.html#INTRODUCTION"
>Overview</A
></DT
><DD
><DL
><DT
>1.1. <A
HREF="index.html#WHATISDEVICEDRIVER"
>What is a <SPAN
CLASS="QUOTE"
>"device driver"</SPAN
>?</A
></DT
><DT
>1.2. <A
HREF="index.html#POLICYMECHANISM"
>Policy vs. mechanism</A
></DT
><DT
>1.3. <A
HREF="index.html#GENERALDAQPACKAGE"
>A general DAQ device driver package</A
></DT
><DT
>1.4. <A
HREF="index.html#COMEDIOSIGNALS"
>DAQ signals</A
></DT
><DT
>1.5. <A
HREF="index.html#COMEDIDEVICES"
>Device hierarchy</A
></DT
><DT
>1.6. <A
HREF="index.html#ACQUISITIONTERMINOLOGY"
>Acquisition terminology</A
></DT
><DT
>1.7. <A
HREF="index.html#COMEDIFUNCTIONS"
>DAQ functions</A
></DT
><DT
>1.8. <A
HREF="index.html#COMEDISUPPORTING"
>Supporting functionality</A
></DT
></DL
></DD
><DT
>2. <A
HREF="x333.html"
>Configuration</A
></DT
><DD
><DL
><DT
>2.1. <A
HREF="x333.html#CARDCONFIGURATION"
>Configuration</A
></DT
><DT
>2.2. <A
HREF="x333.html#GETTINGINFORMATION"
>Getting information about a card</A
></DT
></DL
></DD
><DT
>3. <A
HREF="x403.html"
>Writing <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> programs</A
></DT
><DD
><DL
><DT
>3.1. <A
HREF="x403.html#FIRSTPROGRAM"
>Your first <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> program</A
></DT
><DT
>3.2. <A
HREF="x403.html#CONVERTINGSAMPLES"
>Converting samples to voltages</A
></DT
><DT
>3.3. <A
HREF="x403.html#USINGFILEINTERFACE"
>Using the file interface</A
></DT
><DT
>3.4. <A
HREF="x403.html#SECONDPROGRAM"
>Your second <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> program: simple acquisition</A
></DT
><DT
>3.5. <A
HREF="x403.html#THIRDPROGRAM"
>Your third <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> program: instructions</A
></DT
><DT
>3.6. <A
HREF="x403.html#FOURTHPROGRAM"
>Your fourth <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> program: commands</A
></DT
></DL
></DD
><DT
>4. <A
HREF="x621.html"
>Acquisition and configuration functions</A
></DT
><DD
><DL
><DT
>4.1. <A
HREF="x621.html#SINGLEACQUISITION"
>Functions for single acquisition</A
></DT
><DD
><DL
><DT
>4.1.1. <A
HREF="x621.html#DIO"
>Single digital acquisition</A
></DT
><DT
>4.1.2. <A
HREF="x621.html#SINGLEANALOG"
>Single analog acquisition</A
></DT
></DL
></DD
><DT
>4.2. <A
HREF="x621.html#INSTRUCTIONS"
>Instructions for multiple acquisitions</A
></DT
><DD
><DL
><DT
>4.2.1. <A
HREF="x621.html#COMEDIINSNSTRUCTURE"
>The instruction data structure</A
></DT
><DT
>4.2.2. <A
HREF="x621.html#INSTRUCTIONEXECUTION"
>Instruction execution</A
></DT
></DL
></DD
><DT
>4.3. <A
HREF="x621.html#INSTRUCTIONSCONFIGURATION"
>Instructions for configuration</A
></DT
><DT
>4.4. <A
HREF="x621.html#INTTRIGCONFIGURATION"
>Instruction for internal triggering</A
></DT
><DT
>4.5. <A
HREF="x621.html#COMMANDSSTREAMING"
>Commands for streaming acquisition</A
></DT
><DD
><DL
><DT
>4.5.1. <A
HREF="x621.html#EXECUTINGCOMMAND"
>Executing a command</A
></DT
><DT
>4.5.2. <A
HREF="x621.html#COMEDICMDSTRUCTURE"
>The command data structure</A
></DT
><DT
>4.5.3. <A
HREF="x621.html#COMEDICMDSOURCES"
>The command trigger events
<A
NAME="SOURCE.TRIGGER.ANCHOR"
></A
></A
></DT
><DT
>4.5.4. <A
HREF="x621.html#COMEDICMDFLAGS"
>The command flags
<A
NAME="SOURCE.FLAGS.ANCHOR"
></A
></A
></DT
><DT
>4.5.5. <A
HREF="x621.html#AEN1109"
>Anti-aliasing</A
></DT
></DL
></DD
><DT
>4.6. <A
HREF="x621.html#SLOWLYVARYING"
>Slowly-varying inputs</A
></DT
><DT
>4.7. <A
HREF="x621.html#EXPERIMENTALFUNCTIONALITY"
>Experimental functionality</A
></DT
><DD
><DL
><DT
>4.7.1. <A
HREF="x621.html#DIGITALINPUTCOMBINING"
>Digital input combining machines</A
></DT
><DT
>4.7.2. <A
HREF="x621.html#ANALOGCONVERSION"
>Analog filtering configuration</A
></DT
><DT
>4.7.3. <A
HREF="x621.html#WAVEFORMGENERATION"
>Analog Output Waveform Generation</A
></DT
><DT
>4.7.4. <A
HREF="x621.html#EXTENDEDTRIGGERING"
>Extended Triggering</A
></DT
><DT
>4.7.5. <A
HREF="x621.html#ANALOGTRIGGERING"
>Analog Triggering</A
></DT
><DT
>4.7.6. <A
HREF="x621.html#BITFIELDMATCHING"
>Bitfield Pattern Matching Extended Trigger</A
></DT
><DT
>4.7.7. <A
HREF="x621.html#COUNTERTIMER"
>Counter configuration</A
></DT
><DT
>4.7.8. <A
HREF="x621.html#AUXCOUNTER"
>One source plus auxiliary counter configuration</A
></DT
><DT
>4.7.9. <A
HREF="x621.html#RTSI"
>National instruments RTSI trigger bus</A
></DT
></DL
></DD
></DL
></DD
><DT
>5. <A
HREF="x1394.html"
>Writing a <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> driver</A
></DT
><DD
><DL
><DT
>5.1. <A
HREF="x1394.html#USERKERNELHOW"
>Communication user space-kernel space</A
></DT
><DT
>5.2. <A
HREF="x1394.html#COMEDIKERNELGENERIC"
>Generic functionality</A
></DT
><DD
><DL
><DT
>5.2.1. <A
HREF="x1394.html#DRIVERDATASTRUCTURES"
>Data structures</A
></DT
><DT
>5.2.2. <A
HREF="x1394.html#DRIVERSUPPORTFUNCTIONS"
>Generic driver support functions</A
></DT
></DL
></DD
><DT
>5.3. <A
HREF="x1394.html#BOARDSPECIFIC"
>Board-specific functionality</A
></DT
><DT
>5.4. <A
HREF="x1394.html#DRIVERCALLBACKS"
>Callbacks, events and interrupts</A
></DT
><DT
>5.5. <A
HREF="x1394.html#DRIVERCAVEATS"
>Device driver caveats</A
></DT
><DT
>5.6. <A
HREF="x1394.html#INTEGRATINGDRIVER"
>Integrating the driver in the <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> library</A
></DT
></DL
></DD
><DT
>6. <A
HREF="x1781.html"
>Low-level drivers</A
></DT
><DD
><DL
><DT
>6.1. <A
HREF="x1781.html#AEN1783"
>Low-level drivers</A
></DT
><DD
><DL
><DT
>6.1.1. <A
HREF="x1781.html#AEN1785"
>8255.o -- generic 8255 support</A
></DT
><DT
>6.1.2. <A
HREF="x1781.html#AEN1802"
>acl7225b.o -- Adlink NuDAQ ACL-7225b &#38; compatibles</A
></DT
><DT
>6.1.3. <A
HREF="x1781.html#AEN1823"
>adl_pci6208.o -- ADLink PCI-6208A</A
></DT
><DT
>6.1.4. <A
HREF="x1781.html#AEN1840"
>adl_pci7296.o -- Driver for the Adlink PCI-7296 96 ch. digital io board</A
></DT
><DT
>6.1.5. <A
HREF="x1781.html#AEN1857"
>adl_pci7432.o -- Driver for the Adlink PCI-7432 64 ch. isolated digital io board</A
></DT
><DT
>6.1.6. <A
HREF="x1781.html#AEN1874"
>adl_pci8164.o -- Driver for the Adlink PCI-8164 4 Axes Motion Control board</A
></DT
><DT
>6.1.7. <A
HREF="x1781.html#AEN1891"
>adl_pci9111.o -- Adlink PCI-9111HR</A
></DT
><DT
>6.1.8. <A
HREF="x1781.html#AEN1908"
>adl_pci9118.o -- Adlink PCI-9118DG, PCI-9118HG, PCI-9118HR</A
></DT
><DT
>6.1.9. <A
HREF="x1781.html#AEN1933"
>adv_pci1710.o -- Advantech PCI-1710, PCI-1710HG, PCI-1711, PCI-1713,              Advantech PCI-1720, PCI-1731</A
></DT
><DT
>6.1.10. <A
HREF="x1781.html#AEN1970"
>adv_pci_dio.o -- Advantech PCI-1730, PCI-1733, PCI-1734, PCI-1750, PCI-1751,              PCI-1752, PCI-1753/E, PCI-1754, PCI-1756, PCI-1762</A
></DT
><DT
>6.1.11. <A
HREF="x1781.html#AEN2031"
>aio_aio12_8.o -- Acces I/O Products PC-104 AIO12-8 Analog I/O Board</A
></DT
><DT
>6.1.12. <A
HREF="x1781.html#AEN2048"
>aio_iiro_16.o -- Acces I/O Products PC-104 IIRO16 Relay And Isolated Input Board</A
></DT
><DT
>6.1.13. <A
HREF="x1781.html#AEN2065"
>amplc_dio200.o -- Amplicon PC272E, PCI272</A
></DT
><DT
>6.1.14. <A
HREF="x1781.html#AEN2106"
>amplc_pc236.o -- Amplicon PC36AT, PCI236</A
></DT
><DT
>6.1.15. <A
HREF="x1781.html#AEN2127"
>amplc_pc263.o -- Amplicon PC263, PCI263</A
></DT
><DT
>6.1.16. <A
HREF="x1781.html#AEN2148"
>amplc_pci224.o -- Amplicon PCI224, PCI234</A
></DT
><DT
>6.1.17. <A
HREF="x1781.html#AEN2169"
>amplc_pci230.o -- Amplicom PCI230, PCI260 Multifunction I/O boards</A
></DT
><DT
>6.1.18. <A
HREF="x1781.html#AEN2190"
>c6xdigio.o -- Mechatronic Systems Inc. C6x_DIGIO DSP daughter card</A
></DT
><DT
>6.1.19. <A
HREF="x1781.html#AEN2207"
>cb_das16_cs.o -- Computer Boards PC-CARD DAS16/16</A
></DT
><DT
>6.1.20. <A
HREF="x1781.html#AEN2228"
>cb_pcidas64.o -- MeasurementComputing PCI-DAS64xx, 60XX, and 4020 series with the PLX 9080 PCI controller</A
></DT
><DT
>6.1.21. <A
HREF="x1781.html#AEN2349"
>cb_pcidas.o -- MeasurementComputing PCI-DAS series with the AMCC S5933 PCI controller</A
></DT
><DT
>6.1.22. <A
HREF="x1781.html#AEN2394"
>cb_pcidda.o -- MeasurementComputing PCI-DDA series</A
></DT
><DT
>6.1.23. <A
HREF="x1781.html#AEN2431"
>cb_pcidio.o -- ComputerBoards' DIO boards with PCI interface</A
></DT
><DT
>6.1.24. <A
HREF="x1781.html#AEN2452"
>cb_pcimdas.o -- Measurement Computing PCI Migration series boards</A
></DT
><DT
>6.1.25. <A
HREF="x1781.html#AEN2469"
>cb_pcimdda.o -- Measurement Computing PCIM-DDA06-16</A
></DT
><DT
>6.1.26. <A
HREF="x1781.html#AEN2486"
>comedi_bond.o -- A driver to 'bond' (merge) multiple subdevices from multiple devices together as one.</A
></DT
><DT
>6.1.27. <A
HREF="x1781.html#AEN2491"
>comedi_parport.o -- Standard PC parallel port</A
></DT
><DT
>6.1.28. <A
HREF="x1781.html#AEN2508"
>comedi_rt_timer.o -- Command emulator using real-time tasks</A
></DT
><DT
>6.1.29. <A
HREF="x1781.html#AEN2513"
>comedi_test.o -- generates fake waveforms</A
></DT
><DT
>6.1.30. <A
HREF="x1781.html#AEN2518"
>contec_pci_dio.o -- Contec PIO1616L digital I/O board</A
></DT
><DT
>6.1.31. <A
HREF="x1781.html#AEN2535"
>daqboard2000.o -- IOTech DAQBoard/2000</A
></DT
><DT
>6.1.32. <A
HREF="x1781.html#AEN2552"
>das08.o -- DAS-08 compatible boards</A
></DT
><DT
>6.1.33. <A
HREF="x1781.html#AEN2617"
>das08_cs.o -- DAS-08 PCMCIA boards</A
></DT
><DT
>6.1.34. <A
HREF="x1781.html#AEN2634"
>das16.o -- DAS16 compatible boards</A
></DT
><DT
>6.1.35. <A
HREF="x1781.html#AEN2727"
>das16m1.o -- CIO-DAS16/M1</A
></DT
><DT
>6.1.36. <A
HREF="x1781.html#AEN2744"
>das1800.o -- Keithley Metrabyte DAS1800 (&#38; compatibles)</A
></DT
><DT
>6.1.37. <A
HREF="x1781.html#AEN2829"
>das6402.o -- Keithley Metrabyte DAS6402 (&#38; compatibles)</A
></DT
><DT
>6.1.38. <A
HREF="x1781.html#AEN2846"
>das800.o -- Keithley Metrabyte DAS800 (&#38; compatibles)</A
></DT
><DT
>6.1.39. <A
HREF="x1781.html#AEN2887"
>dmm32at.o -- Diamond Systems mm32at driver.</A
></DT
><DT
>6.1.40. <A
HREF="x1781.html#AEN2892"
>dt2801.o -- Data Translation DT2801 series and DT01-EZ</A
></DT
><DT
>6.1.41. <A
HREF="x1781.html#AEN2941"
>dt2811.o -- Data Translation DT2811</A
></DT
><DT
>6.1.42. <A
HREF="x1781.html#AEN2962"
>dt2814.o -- Data Translation DT2814</A
></DT
><DT
>6.1.43. <A
HREF="x1781.html#AEN2979"
>dt2815.o -- Data Translation DT2815</A
></DT
><DT
>6.1.44. <A
HREF="x1781.html#AEN2996"
>dt2817.o -- Data Translation DT2817</A
></DT
><DT
>6.1.45. <A
HREF="x1781.html#AEN3013"
>dt282x.o -- Data Translation DT2821 series (including DT-EZ)</A
></DT
><DT
>6.1.46. <A
HREF="x1781.html#AEN3086"
>dt3000.o -- Data Translation DT3000 series</A
></DT
><DT
>6.1.47. <A
HREF="x1781.html#AEN3131"
>dt9812.o -- Data Translation DT9812 USB module</A
></DT
><DT
>6.1.48. <A
HREF="x1781.html#AEN3148"
>fl512.o -- unknown</A
></DT
><DT
>6.1.49. <A
HREF="x1781.html#AEN3165"
>gsc_hpdi.o -- General Standards Corporation High     Speed Parallel Digital Interface rs485 boards</A
></DT
><DT
>6.1.50. <A
HREF="x1781.html#AEN3186"
>icp_multi.o -- Inova ICP_MULTI</A
></DT
><DT
>6.1.51. <A
HREF="x1781.html#AEN3203"
>ii_pci20kc.o -- Intelligent Instruments PCI-20001C carrier board</A
></DT
><DT
>6.1.52. <A
HREF="x1781.html#AEN3220"
>jr3_pci.o -- JR3/PCI force sensor board</A
></DT
><DT
>6.1.53. <A
HREF="x1781.html#AEN3237"
>ke_counter.o -- Driver for Kolter Electronic Counter Card</A
></DT
><DT
>6.1.54. <A
HREF="x1781.html#AEN3254"
>me4000.o -- Meilhaus ME-4000 series boards</A
></DT
><DT
>6.1.55. <A
HREF="x1781.html#AEN3287"
>me_daq.o -- Meilhaus PCI data acquisition cards</A
></DT
><DT
>6.1.56. <A
HREF="x1781.html#AEN3308"
>mpc624.o -- Micro/sys MPC-624 PC/104 board</A
></DT
><DT
>6.1.57. <A
HREF="x1781.html#AEN3325"
>mpc8260cpm.o -- MPC8260 CPM module generic digital I/O lines</A
></DT
><DT
>6.1.58. <A
HREF="x1781.html#AEN3342"
>multiq3.o -- Quanser Consulting MultiQ-3</A
></DT
><DT
>6.1.59. <A
HREF="x1781.html#AEN3359"
>ni_6527.o -- National Instruments 6527</A
></DT
><DT
>6.1.60. <A
HREF="x1781.html#AEN3380"
>ni_65xx.o -- National Instruments 65xx static dio boards</A
></DT
><DT
>6.1.61. <A
HREF="x1781.html#AEN3481"
>ni_660x.o -- National Instruments 660x counter/timer boards</A
></DT
><DT
>6.1.62. <A
HREF="x1781.html#AEN3502"
>ni_670x.o -- National Instruments 670x</A
></DT
><DT
>6.1.63. <A
HREF="x1781.html#AEN3523"
>ni_at_a2150.o -- National Instruments AT-A2150</A
></DT
><DT
>6.1.64. <A
HREF="x1781.html#AEN3544"
>ni_at_ao.o -- National Instruments AT-AO-6/10</A
></DT
><DT
>6.1.65. <A
HREF="x1781.html#AEN3565"
>ni_atmio16d.o -- National Instruments AT-MIO-16D</A
></DT
><DT
>6.1.66. <A
HREF="x1781.html#AEN3586"
>ni_atmio.o -- National Instruments AT-MIO-E series</A
></DT
><DT
>6.1.67. <A
HREF="x1781.html#AEN3631"
>ni_daq_dio24.o -- National Instruments PCMCIA DAQ-Card DIO-24</A
></DT
><DT
>6.1.68. <A
HREF="x1781.html#AEN3648"
>ni_labpc.o -- National Instruments Lab-PC (&#38; compatibles)</A
></DT
><DT
>6.1.69. <A
HREF="x1781.html#AEN3677"
>ni_labpc_cs.o -- National Instruments Lab-PC (&#38; compatibles)</A
></DT
><DT
>6.1.70. <A
HREF="x1781.html#AEN3694"
>ni_mio_cs.o -- National Instruments DAQCard E series</A
></DT
><DT
>6.1.71. <A
HREF="x1781.html#AEN3727"
>ni_pcidio.o -- National Instruments PCI-DIO32HS, PCI-DIO96, PCI-6533, PCI-6503</A
></DT
><DT
>6.1.72. <A
HREF="x1781.html#AEN3784"
>ni_pcimio.o -- National Instruments PCI-MIO-E series and M series (all boards)</A
></DT
><DT
>6.1.73. <A
HREF="x1781.html#AEN4005"
>ni_tio.o -- National Instruments general purpose counters</A
></DT
><DT
>6.1.74. <A
HREF="x1781.html#AEN4010"
>pcl711.o -- Advantech PCL-711 and 711b, ADLink ACL-8112</A
></DT
><DT
>6.1.75. <A
HREF="x1781.html#AEN4039"
>pcl724.o -- Advantech PCL-724, PCL-722, PCL-731 ADLink ACL-7122, ACL-7124,   PET-48DIO</A
></DT
><DT
>6.1.76. <A
HREF="x1781.html#AEN4076"
>pcl725.o -- Advantech PCL-725 (&#38; compatibles)</A
></DT
><DT
>6.1.77. <A
HREF="x1781.html#AEN4093"
>pcl726.o -- Advantech PCL-726 &#38; compatibles</A
></DT
><DT
>6.1.78. <A
HREF="x1781.html#AEN4126"
>pcl730.o -- Advantech PCL-730 (&#38; compatibles)</A
></DT
><DT
>6.1.79. <A
HREF="x1781.html#AEN4151"
>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</A
></DT
><DT
>6.1.80. <A
HREF="x1781.html#AEN4232"
>pcl816.o -- Advantech PCL-816 cards, PCL-814</A
></DT
><DT
>6.1.81. <A
HREF="x1781.html#AEN4253"
>pcl818.o -- Advantech PCL-818 cards, PCL-718</A
></DT
><DT
>6.1.82. <A
HREF="x1781.html#AEN4290"
>pcm3724.o -- Advantech PCM-3724</A
></DT
><DT
>6.1.83. <A
HREF="x1781.html#AEN4307"
>pcm3730.o -- PCM3730</A
></DT
><DT
>6.1.84. <A
HREF="x1781.html#AEN4324"
>pcmad.o -- Winsystems PCM-A/D12, PCM-A/D16</A
></DT
><DT
>6.1.85. <A
HREF="x1781.html#AEN4345"
>pcmda12.o -- A driver for the Winsystems PCM-D/A-12</A
></DT
><DT
>6.1.86. <A
HREF="x1781.html#AEN4362"
>pcmmio.o -- A driver for the PCM-MIO multifunction board</A
></DT
><DT
>6.1.87. <A
HREF="x1781.html#AEN4379"
>pcmuio.o -- A driver for the PCM-UIO48A and PCM-UIO96A boards from Winsystems.</A
></DT
><DT
>6.1.88. <A
HREF="x1781.html#AEN4400"
>poc.o -- Generic driver for very simple devices</A
></DT
><DT
>6.1.89. <A
HREF="x1781.html#AEN4425"
>quatech_daqp_cs.o -- Quatech DAQP PCMCIA data capture cards</A
></DT
><DT
>6.1.90. <A
HREF="x1781.html#AEN4446"
>rtd520.o -- Real Time Devices PCI4520/DM7520</A
></DT
><DT
>6.1.91. <A
HREF="x1781.html#AEN4475"
>rti800.o -- Analog Devices RTI-800/815</A
></DT
><DT
>6.1.92. <A
HREF="x1781.html#AEN4496"
>rti802.o -- Analog Devices RTI-802</A
></DT
><DT
>6.1.93. <A
HREF="x1781.html#AEN4513"
>s526.ko -- Sensoray 526 driver</A
></DT
><DT
>6.1.94. <A
HREF="x1781.html#AEN4530"
>s626.ko -- Sensoray 626 driver</A
></DT
><DT
>6.1.95. <A
HREF="x1781.html#AEN4547"
>serial2002.o -- Driver for serial connected hardware</A
></DT
><DT
>6.1.96. <A
HREF="x1781.html#AEN4552"
>skel.o -- Skeleton driver, an example for driver writers</A
></DT
><DT
>6.1.97. <A
HREF="x1781.html#AEN4557"
>ssv_dnp.o -- SSV Embedded Systems DIL/Net-PC</A
></DT
><DT
>6.1.98. <A
HREF="x1781.html#AEN4574"
>unioxx5.o -- Driver for Fastwel UNIOxx-5 (analog and digital i/o) boards.</A
></DT
><DT
>6.1.99. <A
HREF="x1781.html#AEN4595"
>usbdux.c -- University of Stirling USB DAQ &#38; INCITE Technology Limited</A
></DT
><DT
>6.1.100. <A
HREF="x1781.html#AEN4612"
>usbduxfast.c -- ITL USB-DUXfast</A
></DT
></DL
></DD
></DL
></DD
><DT
>7. <A
HREF="x4629.html"
><ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> Reference</A
></DT
><DD
><DL
><DT
>7.1. <A
HREF="x4629.html#COMEDI-COMEDILIB-H"
>Headerfiles: <TT
CLASS="FILENAME"
>comedi.h</TT
> and <TT
CLASS="FILENAME"
>comedilib.h</TT
></A
></DT
><DT
>7.2. <A
HREF="x4629.html#CONSTANTSMACROS"
>Constants and Macros</A
></DT
><DD
><DL
><DT
>7.2.1. <A
HREF="x4629.html#REF-MACRO-CR-PACK"
>CR_PACK</A
></DT
><DT
>7.2.2. <A
HREF="x4629.html#REF-MACRO-RANGE-LENGTH"
>RANGE_LENGTH (deprecated)</A
></DT
><DT
>7.2.3. <A
HREF="x4629.html#REF-ENUM-COMEDI-CONVERSION-DIRECTION"
>enum comedi_conversion_direction</A
></DT
></DL
></DD
><DT
>7.3. <A
HREF="x4629.html#DATATYPESSTRUCTURES"
>Data Types and Structures</A
></DT
><DD
><DL
><DT
>7.3.1. <A
HREF="x4629.html#REF-TYPE-SUBDEVICE-STRUCT"
>subdevice_struct</A
></DT
><DT
>7.3.2. <A
HREF="x4629.html#REF-TYPE-COMEDI-DEVINFO"
>comedi_devinfo</A
></DT
><DT
>7.3.3. <A
HREF="x4629.html#REF-TYPE-COMEDI-T"
>comedi_t</A
></DT
><DT
>7.3.4. <A
HREF="x4629.html#REF-TYPE-SAMPL-T"
>sampl_t</A
></DT
><DT
>7.3.5. <A
HREF="x4629.html#REF-TYPE-LSAMPL-T"
>lsampl_t</A
></DT
><DT
>7.3.6. <A
HREF="x4629.html#REF-TYPE-COMEDI-TRIG"
>comedi_trig (deprecated)</A
></DT
><DT
>7.3.7. <A
HREF="x4629.html#REF-TYPE-COMEDI-SV-T"
>comedi_sv_t</A
></DT
><DT
>7.3.8. <A
HREF="x4629.html#REF-TYPE-COMEDI-CMD"
>comedi_cmd</A
></DT
><DT
>7.3.9. <A
HREF="x4629.html#REF-TYPE-COMEDI-INSN"
>comedi_insn</A
></DT
><DT
>7.3.10. <A
HREF="x4629.html#REF-TYPE-COMEDI-RANGE"
>comedi_range</A
></DT
><DT
>7.3.11. <A
HREF="x4629.html#REF-TYPE-COMEDI-KRANGE"
>comedi_krange</A
></DT
><DT
>7.3.12. <A
HREF="x4629.html#REF-TYPE-COMEDI-INSNLIST"
>comedi_insnlist</A
></DT
></DL
></DD
><DT
>7.4. <A
HREF="x4629.html#FUNCTIONREFERENCE"
>Comedi Function Reference</A
></DT
><DD
><DL
><DT
><A
HREF="r4835.html"
>comedi_close</A
>&nbsp;--&nbsp;close a Comedi device</DT
><DT
><A
HREF="r4857.html"
>comedi_open</A
>&nbsp;--&nbsp;open a Comedi device</DT
><DT
><A
HREF="r4879.html"
>comedi_loglevel</A
>&nbsp;--&nbsp;change Comedilib logging properties</DT
><DT
><A
HREF="r4909.html"
>comedi_perror</A
>&nbsp;--&nbsp;print a Comedilib error message</DT
><DT
><A
HREF="r4930.html"
>comedi_strerror</A
>&nbsp;--&nbsp;return string describing Comedilib error code</DT
><DT
><A
HREF="r4951.html"
>comedi_errno</A
>&nbsp;--&nbsp;number of last Comedilib error</DT
><DT
><A
HREF="r4973.html"
>comedi_fileno</A
>&nbsp;--&nbsp;integer descriptor of Comedilib device</DT
><DT
><A
HREF="r4992.html"
>comedi_get_n_subdevices</A
>&nbsp;--&nbsp;number of subdevices</DT
><DT
><A
HREF="r5011.html"
>comedi_get_version_code</A
>&nbsp;--&nbsp;Comedi version code</DT
><DT
><A
HREF="r5032.html"
>comedi_get_driver_name</A
>&nbsp;--&nbsp;Comedi driver name</DT
><DT
><A
HREF="r5051.html"
>comedi_get_board_name</A
>&nbsp;--&nbsp;Comedi device name</DT
><DT
><A
HREF="r5070.html"
>comedi_get_subdevice_type</A
>&nbsp;--&nbsp;type of subdevice</DT
><DT
><A
HREF="r5092.html"
>comedi_find_subdevice_by_type</A
>&nbsp;--&nbsp;search for subdevice type</DT
><DT
><A
HREF="r5115.html"
>comedi_get_read_subdevice</A
>&nbsp;--&nbsp;find streaming input subdevice</DT
><DT
><A
HREF="r5134.html"
>comedi_get_write_subdevice</A
>&nbsp;--&nbsp;find streaming output subdevice</DT
><DT
><A
HREF="r5153.html"
>comedi_get_subdevice_flags</A
>&nbsp;--&nbsp;properties of subdevice</DT
><DT
><A
HREF="r5268.html"
>comedi_get_n_channels</A
>&nbsp;--&nbsp;number of subdevice channels</DT
><DT
><A
HREF="r5289.html"
>comedi_range_is_chan_specific</A
>&nbsp;--&nbsp;range information depends on channel</DT
><DT
><A
HREF="r5310.html"
>comedi_maxdata_is_chan_specific</A
>&nbsp;--&nbsp;maximum sample depends on channel</DT
><DT
><A
HREF="r5331.html"
>comedi_get_maxdata</A
>&nbsp;--&nbsp;maximum sample of channel</DT
><DT
><A
HREF="r5360.html"
>comedi_get_n_ranges</A
>&nbsp;--&nbsp;number of ranges of channel</DT
><DT
><A
HREF="r5383.html"
>comedi_get_range</A
>&nbsp;--&nbsp;range information of channel</DT
><DT
><A
HREF="r5408.html"
>comedi_find_range</A
>&nbsp;--&nbsp;search for range</DT
><DT
><A
HREF="r5437.html"
>comedi_get_buffer_size</A
>&nbsp;--&nbsp;streaming buffer size of subdevice</DT
><DT
><A
HREF="r5458.html"
>comedi_get_max_buffer_size</A
>&nbsp;--&nbsp;maximum streaming buffer size</DT
><DT
><A
HREF="r5479.html"
>comedi_set_buffer_size</A
>&nbsp;--&nbsp;streaming buffer size of subdevice</DT
><DT
><A
HREF="r5503.html"
>comedi_trigger</A
>&nbsp;--&nbsp;perform streaming input/output (deprecated)</DT
><DT
><A
HREF="r5527.html"
>comedi_do_insnlist</A
>&nbsp;--&nbsp;perform multiple instructions</DT
><DT
><A
HREF="r5553.html"
>comedi_do_insn</A
>&nbsp;--&nbsp;perform instruction</DT
><DT
><A
HREF="r5574.html"
>comedi_lock</A
>&nbsp;--&nbsp;subdevice reservation</DT
><DT
><A
HREF="r5598.html"
>comedi_unlock</A
>&nbsp;--&nbsp;subdevice reservation</DT
><DT
><A
HREF="r5619.html"
>comedi_to_phys</A
>&nbsp;--&nbsp;convert sample to physical units</DT
><DT
><A
HREF="r5644.html"
>comedi_to_physical</A
>&nbsp;--&nbsp;convert sample to physical units</DT
><DT
><A
HREF="r5673.html"
>comedi_from_phys</A
>&nbsp;--&nbsp;convert physical units to sample</DT
><DT
><A
HREF="r5697.html"
>comedi_from_physical</A
>&nbsp;--&nbsp;convert physical units to sample</DT
><DT
><A
HREF="r5725.html"
>comedi_data_read</A
>&nbsp;--&nbsp;read single sample from channel</DT
><DT
><A
HREF="r5758.html"
>comedi_data_read_delayed</A
>&nbsp;--&nbsp;read single sample from channel after delaying for specified settling time</DT
><DT
><A
HREF="r5790.html"
>comedi_data_read_hint</A
>&nbsp;--&nbsp;tell driver which channel/range/aref you are going to read from next</DT
><DT
><A
HREF="r5818.html"
>comedi_data_write</A
>&nbsp;--&nbsp;write single sample to channel</DT
><DT
><A
HREF="r5849.html"
>comedi_dio_config</A
>&nbsp;--&nbsp;change input/output properties of channel</DT
><DT
><A
HREF="r5876.html"
>comedi_dio_get_config</A
>&nbsp;--&nbsp;query input/output properties of channel</DT
><DT
><A
HREF="r5903.html"
>comedi_dio_read</A
>&nbsp;--&nbsp;read single bit from digital channel</DT
><DT
><A
HREF="r5929.html"
>comedi_dio_write</A
>&nbsp;--&nbsp;write single bit to digital channel</DT
><DT
><A
HREF="r5955.html"
>comedi_dio_bitfield</A
>&nbsp;--&nbsp;read/write multiple digital channels</DT
><DT
><A
HREF="r5983.html"
>comedi_dio_bitfield2</A
>&nbsp;--&nbsp;read/write multiple digital channels</DT
><DT
><A
HREF="r6018.html"
>comedi_sv_init</A
>&nbsp;--&nbsp;slowly-varying inputs</DT
><DT
><A
HREF="r6046.html"
>comedi_sv_update</A
>&nbsp;--&nbsp;slowly-varying inputs</DT
><DT
><A
HREF="r6068.html"
>comedi_sv_measure</A
>&nbsp;--&nbsp;slowly-varying inputs</DT
><DT
><A
HREF="r6092.html"
>comedi_get_cmd_src_mask</A
>&nbsp;--&nbsp;streaming input/output capabilities</DT
><DT
><A
HREF="r6115.html"
>comedi_get_cmd_generic_timed</A
>&nbsp;--&nbsp;streaming input/output capabilities</DT
><DT
><A
HREF="r6142.html"
>comedi_cancel</A
>&nbsp;--&nbsp;stop streaming input/output in progress</DT
><DT
><A
HREF="r6164.html"
>comedi_command</A
>&nbsp;--&nbsp;start streaming input/output</DT
><DT
><A
HREF="r6186.html"
>comedi_command_test</A
>&nbsp;--&nbsp;test streaming input/output configuration</DT
><DT
><A
HREF="r6214.html"
>comedi_poll</A
>&nbsp;--&nbsp;force updating of streaming buffer</DT
><DT
><A
HREF="r6235.html"
>comedi_set_max_buffer_size</A
>&nbsp;--&nbsp;streaming buffer size of subdevice</DT
><DT
><A
HREF="r6258.html"
>comedi_get_buffer_contents</A
>&nbsp;--&nbsp;streaming buffer status</DT
><DT
><A
HREF="r6279.html"
>comedi_mark_buffer_read</A
>&nbsp;--&nbsp;streaming buffer control</DT
><DT
><A
HREF="r6302.html"
>comedi_mark_buffer_written</A
>&nbsp;--&nbsp;streaming buffer control</DT
><DT
><A
HREF="r6325.html"
>comedi_get_buffer_offset</A
>&nbsp;--&nbsp;streaming buffer status</DT
><DT
><A
HREF="r6346.html"
>comedi_get_timer</A
>&nbsp;--&nbsp;timer information (deprecated)</DT
><DT
><A
HREF="r6376.html"
>comedi_timed_1chan</A
>&nbsp;--&nbsp;streaming input (deprecated)</DT
><DT
><A
HREF="r6412.html"
>comedi_set_global_oor_behavior</A
>&nbsp;--&nbsp;out-of-range behavior</DT
><DT
><A
HREF="r6435.html"
>comedi_apply_calibration</A
>&nbsp;--&nbsp;set hardware calibration from file</DT
><DT
><A
HREF="r6475.html"
>comedi_apply_parsed_calibration</A
>&nbsp;--&nbsp;set calibration from memory</DT
><DT
><A
HREF="r6512.html"
>comedi_cleanup_calibration_file</A
>&nbsp;--&nbsp;free calibration resources</DT
><DT
><A
HREF="r6535.html"
>comedi_get_default_calibration_path</A
>&nbsp;--&nbsp;get default calibration file path</DT
><DT
><A
HREF="r6561.html"
>comedi_parse_calibration_file</A
>&nbsp;--&nbsp;load contents of calibration file</DT
><DT
><A
HREF="r6587.html"
>comedi_get_hardcal_converter</A
>&nbsp;--&nbsp;get converter for hardware-calibrated subdevice</DT
><DT
><A
HREF="r6633.html"
>comedi_get_softcal_converter</A
>&nbsp;--&nbsp;get converter for software-calibrated subdevice</DT
></DL
></DD
></DL
></DD
><DT
><A
HREF="g6679.html"
>Glossary</A
></DT
></DL
></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="INTRODUCTION"
>1. Overview</A
></H1
><P
><ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> is a <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>free software</I
></SPAN
> project that develops
drivers, tools, and libraries for various forms of
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>data acquisition</I
></SPAN
>: 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,
<TT
CLASS="LITERAL"
><A
HREF="http://www.comedi.org/download.php"
TARGET="_top"
>comedi</A
></TT
> and
<TT
CLASS="LITERAL"
><A
HREF="http://www.comedi.org/download.php"
TARGET="_top"
>comedilib</A
></TT
>, and provides several Linux
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>kernel modules</I
></SPAN
> and a
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>user space</I
></SPAN
> library:
<P
></P
><UL
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Comedi</B
></SPAN
> is a collection of drivers for a variety
of common data acquisition plug-in boards (which are called
<SPAN
CLASS="QUOTE"
>"devices"</SPAN
> in <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> terminology). The drivers are
implemented as the combination of (i) one single core Linux kernel module
(called <SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>comedi</TT
>"</SPAN
>) providing common
functionality, and (ii) individual low-level driver modules for
each device.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Comedilib</B
></SPAN
> is a separately distributed package
containing a user-space library that provides a
developer-friendly interface to the <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> devices. Included in the
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>Comedilib</I
></SPAN
> package are documentation,
configuration and calibration utilities, and demonstration programs.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Kcomedilib</B
></SPAN
> is a Linux kernel module
(distributed with the <TT
CLASS="LITERAL"
>comedi</TT
> package) that provides
the same interface as <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>comedilib</I
></SPAN
> in kernel space,
and suitable for <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>real-time</I
></SPAN
> tasks. It is
effectively a <SPAN
CLASS="QUOTE"
>"kernel library"</SPAN
> for using <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> from
real-time tasks.</P
></LI
></UL
>
<ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> works with standard Linux kernels, but also with its
real-time extensions <A
HREF="http://www.rtai.org"
TARGET="_top"
>RTAI</A
> and
<A
HREF="http://www.rtlinux-gpl.org/"
TARGET="_top"
>RTLinux/GPL</A
>.</P
><P
>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.</P
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="WHATISDEVICEDRIVER"
>1.1. What is a <SPAN
CLASS="QUOTE"
>"device driver"</SPAN
>?</A
></H2
><P
>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.</P
><P
>David Schleef started the <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> 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 <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>data acquisition</I
></SPAN
>
(or <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>DAQ</B
></SPAN
>) cards.</P
><P
><SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>Analog input and output</I
></SPAN
> cards were the first goal
of the project, but now <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> also provides a device
independent interface to digital <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>input and output</I
></SPAN
>
cards, and <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>counter and timer</I
></SPAN
> cards (including
encoders, pulse generators, frequency and pulse timers, etc.).</P
><P
>Schleef designed a structure which is a balance between
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>modularity</I
></SPAN
> and <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>complexity</I
></SPAN
>:
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 <SPAN
CLASS="QUOTE"
>"heavier"</SPAN
> <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
>
API doesn't scare away new contributors from integrating their drivers
into the <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> framework.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="POLICYMECHANISM"
>1.2. Policy vs. mechanism</A
></H2
><P
>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:
<P
></P
><UL
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Mechanism.</B
></SPAN
>
  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.</P
></LI
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Policy.</B
></SPAN
>
  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.</P
></LI
></UL
>
So, <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> focuses only on the <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>mechanism</I
></SPAN
> 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.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="GENERALDAQPACKAGE"
>1.3. A general DAQ device driver package</A
></H2
><P
>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:
<P
></P
><UL
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>API</B
></SPAN
>: 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.</P
></LI
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Architectural structure</B
></SPAN
>: 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, <SPAN
CLASS="QUOTE"
>"lower-level"</SPAN
> 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.</P
></LI
></UL
></P
><P
>In the case of Linux as the host operating system, device driver
writers must keep the following Linux-specific issues in mind:
<P
></P
><UL
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Kernel space vs. User space.</B
></SPAN
>
  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 <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>system calls</I
></SPAN
>.</P
><P
>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 <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>Comedi</I
></SPAN
>, while
<ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> device driver writers use the API offered by
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>Kcomedilib</I
></SPAN
>. Typical examples of the latter are
the registration of interrupt handler routines, and the handling of
events.</P
></LI
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Device files or device file system.</B
></SPAN
>
  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 <SPAN
CLASS="QUOTE"
>"files"</SPAN
>
  in the <TT
CLASS="FILENAME"
>/dev</TT
> directory (2.2.x kernels or
earlier) or <TT
CLASS="FILENAME"
>/devfs</TT
> 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:
<CODE
CLASS="FUNCTION"
>open</CODE
>,
<CODE
CLASS="FUNCTION"
>close</CODE
>, <CODE
CLASS="FUNCTION"
>read</CODE
>,
  <CODE
CLASS="FUNCTION"
>write</CODE
>, and <CODE
CLASS="FUNCTION"
>ioctl</CODE
>.</P
></LI
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
><TT
CLASS="FILENAME"
>/proc</TT
> interface.</B
></SPAN
>
  Linux (and some other UNIX operating systems) offer a file-like
interface to attached devices (and other OS-related information) via
the <TT
CLASS="FILENAME"
>/proc</TT
> directories. These
<SPAN
CLASS="QUOTE"
>"files"</SPAN
> do not really exist, but it gives a familiar
interface to users, with which they can inspect the current status of
each device.</P
></LI
><LI
><P
>  <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Direct Memory Access (DMA) vs. Programmed
Input/Output (PIO).</B
></SPAN
>
  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 <SPAN
CLASS="QUOTE"
>"talk"</SPAN
> 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).</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Real-time vs. non real-time.</B
></SPAN
>
If the device is to be used in a
<A
HREF="http://www.rtlinux-gpl.org/"
TARGET="_top"
>RTLinux/GPL</A
>
or <A
HREF="http://www.rtai.org"
TARGET="_top"
>RTAI</A
> application,
there are a few extra requirements, because not all system calls are
available in the kernel of the real-time operating systems
<A
HREF="http://www.rtlinux-gpl.org/"
TARGET="_top"
>RTLinux/GPL</A
>
or <A
HREF="http://www.rtai.org"
TARGET="_top"
>RTAI</A
>.
The APIs of RTAI and RTLinux/Free differ in
different ways, so the <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> developers have spent a lot of efforts
to make generic wrappers to the required RTOS primitives: timers,
memory allocation, registration of interrupt handlers, etc.</P
></LI
></UL
></P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMEDIOSIGNALS"
>1.4. DAQ signals</A
></H2
><P
>The cards supported in <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> have one or more of the following
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>signals</B
></SPAN
>: analog input, analog
output, digital input, digital output, counter input, counter output,
pulse input, pulse output:
<P
></P
><UL
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Digital</B
></SPAN
> 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.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Analog</B
></SPAN
> 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., <TT
CLASS="LITERAL"
>-10V</TT
> and
<TT
CLASS="LITERAL"
>+10V</TT
>); the card's electronics can be programmed to
automatically sample a set of channels, in a prescribed order, to
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>buffer</I
></SPAN
> sequences of data on the board; or to use
DMA or an interrupt routine to dump the data in a prescribed part of
memory.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Pulse</B
></SPAN
>-based signals (counters,
timers, encoders, etc.) are conceptually
only a bit more complex than digital inputs and outputs, in that
they only add some <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>timing specifications</I
></SPAN
> to the
signal. <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> has still only a limited number of drivers for this
kind of signals, although most of the necessary API and support
functionality is available.</P
></LI
></UL
>
In addition to these <SPAN
CLASS="QUOTE"
>"real"</SPAN
> DAQ functions, <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> also
offers basic timer access.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMEDIDEVICES"
>1.5. Device hierarchy</A
></H2
><P
><ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> organizes all hardware according to the following generic
hierarchy:
<P
></P
><UL
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Channel</B
></SPAN
>: 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 <SPAN
CLASS="QUOTE"
>"0"</SPAN
> and <SPAN
CLASS="QUOTE"
>"1"</SPAN
>; etc.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Sub-device</B
></SPAN
>: 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.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Device</B
></SPAN
>: a set of sub-devices that are physically implemented on the
  same interface card; in other words, the interface card itself.
  For example, the <TT
CLASS="LITERAL"
>National Instruments 6024E</TT
>
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.</P
></LI
></UL
>
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 <SPAN
CLASS="QUOTE"
>"sub-devices"</SPAN
> in
<ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
>.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ACQUISITIONTERMINOLOGY"
>1.6. Acquisition terminology</A
></H2
><P
>This Section introduces the terminology that this document uses when
talking about <SPAN
CLASS="QUOTE"
>"acquisitions."</SPAN
> <A
HREF="index.html#FIG-ACQ-SEQ"
>Figure 1</A
>
depicts a typical acquisition <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>sequence</B
></SPAN
>:
<P
></P
><UL
><LI
><P
>The sequence has a <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>start</B
></SPAN
> and an
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>end</B
></SPAN
>. At both sides, the software
and the hardware need some finite
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>initialization or settling time</B
></SPAN
>.</P
></LI
><LI
><P
><A
NAME="SCAN"
></A
>
The sequence consists of a number of identically repeated
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>scans</B
></SPAN
>. 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
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>begin</B
></SPAN
>, an
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>end</B
></SPAN
>, and a finite
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>setup time</B
></SPAN
>. Possibly, there is also
a settling time
(<SPAN
CLASS="QUOTE"
>"<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>scan delay</B
></SPAN
>"</SPAN
>) at the
end of a scan.</P
><P
>So, the hardware puts a
lower boundary (the <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>scan interval</B
></SPAN
>)
on the minimum time needed to complete a full scan.</P
></LI
><LI
><P
>Each scan contains one or more
<A
NAME="CONVERSION"
></A
>
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>conversions</B
></SPAN
> 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
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>conversion time</B
></SPAN
>, starting from the
moment in time called the
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>sample time</B
></SPAN
>
in <A
HREF="index.html#FIG-ACQ-SEQ"
>Figure 1</A
>
(sometimes also called the <SPAN
CLASS="QUOTE"
>"timestamp"</SPAN
>),
and caused by a
triggering event, called <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>convert</B
></SPAN
>.
In addition, each hardware has limits on the minimum
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>conversion interval</B
></SPAN
> it can achieve,
i.e., the minimum time it needs between
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>subsequent</I
></SPAN
> conversions.</P
><P
>Some hardware must <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>multiplex</I
></SPAN
> the conversions onto
one single AD/DA hardware, such that the conversions are done serially
in time (as shown on the <A
HREF="index.html#FIG-ACQ-SEQ"
>Figure</A
>);
other cards have the hardware to do two or more acquisitions in
parallel.  The begin of each conversion is <SPAN
CLASS="QUOTE"
>"triggered"</SPAN
> by
some internally or externally generated pulse, e.g., a timer.</P
></LI
></UL
>
In general, not only the begin of a <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>conversion</I
></SPAN
> is
triggered, but also the begin of a <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>scan</I
></SPAN
> and of a
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>sequence</I
></SPAN
>. <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> provides the API to configure
what <A
HREF="x621.html#COMEDICMDSOURCES"
>triggering source</A
>
one wants to use in each case. The API also
allows to specify the <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>channel list</B
></SPAN
>,
i.e., the sequence of channels that needs to be acquired during each
scan.</P
><P
><DIV
CLASS="FIGURE"
><A
NAME="FIG-ACQ-SEQ"
></A
><P
><B
>Figure 1.  Acquisition sequence. (Figure courtesy of
 <A
HREF="mailto:Kurt.Mueller@aerodynamics.ch"
TARGET="_top"
>Kurt Mueller</A
>.)</B
></P
><DIV
CLASS="MEDIAOBJECT"
><P
><IMG
SRC="acq-seq.gif"></P
></DIV
></DIV
>&#13;</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMEDIFUNCTIONS"
>1.7. DAQ functions</A
></H2
><P
>The basic data acquisition functionalities that <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> offers work
on channels, or sets of channels:
<P
></P
><UL
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Single acquisition</B
></SPAN
>: <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> has
function calls to synchronously perform
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>one single</I
></SPAN
> data acquisition on a specified
channel: <CODE
CLASS="FUNCTION"
>comedi_data_read()</CODE
>,
<CODE
CLASS="FUNCTION"
>comedi_data_write()</CODE
>,
<CODE
CLASS="FUNCTION"
>comedi_dio_read()</CODE
>,
<CODE
CLASS="FUNCTION"
>comedi_dio_write()</CODE
>.
<SPAN
CLASS="QUOTE"
>"Synchronous"</SPAN
> means that the calling process
blocks until the data acquisition has finished.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Instruction</B
></SPAN
>: a
<CODE
CLASS="FUNCTION"
>comedi_do_insn()</CODE
> instruction
performs (possibly multiple) data acquisitions on a specified channel,
in a <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>synchronous</B
></SPAN
> way. So, the
function call blocks until the whole acquisition has finished.</P
><P
>In addition, <CODE
CLASS="FUNCTION"
>comedi_do_insnlist()</CODE
> executes a
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>list</I
></SPAN
> of instructions (on different channels) in
one single (blocking, synchronous) call, such that the overhead
involved in configuring each individual acquisition is reduced.</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Scan</B
></SPAN
>: a scan is an acquisition on a
set of different channels, with a <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>specified sequence and
timing</I
></SPAN
>.</P
><P
>Scans are not directly available as stand-alone function calls in the
<ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> API. They are the internal building blocks of a <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
>
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>command</I
></SPAN
> (see below).</P
></LI
><LI
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Command</B
></SPAN
>: a command is
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>sequence</I
></SPAN
> of
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>scans</I
></SPAN
>, for which conditions have been specified
that determine when the acquisition will start and stop.  A
<CODE
CLASS="FUNCTION"
>comedi_command()</CODE
> function call generates
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>aynchronous</B
></SPAN
> data acquisition:
as soon as the command information has been filled in, the
<CODE
CLASS="FUNCTION"
>comedi_command()</CODE
> 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 <SPAN
CLASS="QUOTE"
>"callback"</SPAN
> 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 <SPAN
CLASS="QUOTE"
>"handler"</SPAN
>  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.</P
><P
>Buffer management is not the only asynchronous activity: a running
acquisition must eventually be stopped too, or it must be started
after the <CODE
CLASS="FUNCTION"
>comedi_command()</CODE
> function call has
prepared (but not started) the hardware for the acquisition.
The command functionality is very configurable with respect to
choosing which <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>events</B
></SPAN
> 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 <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
>
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>instruction</I
></SPAN
> 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
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>synchronous</B
></SPAN
> with the execution of
the trigger instruction in the device driver, but it is
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>asynchronous</B
></SPAN
> with respect to the
instruction or command that initiated the current acquisition.</P
><P
>Typically, there is one synchronous triggering instruction for each
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>subdevice</I
></SPAN
>.</P
></LI
></UL
>
Note that software triggering is only relevant for commands, and not
for instructions: instructions are executed
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>synchronously</I
></SPAN
> 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.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMEDISUPPORTING"
>1.8. Supporting functionality</A
></H2
><P
>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,
<ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> provides the <CODE
CLASS="FUNCTION"
>comedi_rt_timer</CODE
> kernel
module to support such a
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>virtual command execution</B
></SPAN
> under
<ACRONYM
CLASS="ACRONYM"
>RTAI</ACRONYM
> or <ACRONYM
CLASS="ACRONYM"
>RTLinux/Free</ACRONYM
>.</P
><P
><ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> not only offers the API
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>to access</B
></SPAN
> the functionality of the
cards, but also <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>to query</B
></SPAN
> the
capabilities of the installed devices. That is, a user process can
find out <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>on-line</I
></SPAN
> what channels are available, and
what their physical parameters are (range, direction of input/output,
etc.).</P
><P
><SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>Buffering</B
></SPAN
> 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, <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
>
offers all functionality to configure and manage data buffers,
abstracting away the intricacies of buffer management at the bare
operating system level.</P
><P
>As already mentioned before, <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> contains more than just
procedural function calls, since it also offers
<SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>event-driven</B
></SPAN
>
(<SPAN
CLASS="QUOTE"
>"asynchronous"</SPAN
>) functionality:
the data acquisition can signal
its completion by means of an interrupt or a
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>callback</I
></SPAN
> 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
(<SPAN
CLASS="APPLICATION"
>RTAI</SPAN
> or
<SPAN
CLASS="APPLICATION"
>RTLinux/Free</SPAN
>) or non real-time, but both
contexts are encapsulated wihting the same <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> calls.</P
><P
>Because multiple devices can all be active at the same time, <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
>
provides <SPAN
CLASS="strong"
><B
CLASS="EMPHASIS"
>locking</B
></SPAN
> primitives to
ensure atomic operations on critical sections of the code or data
structures.</P
><P
>Finally, <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> offers the previously mentioned
<SPAN
CLASS="QUOTE"
>"high-level"</SPAN
> interaction, i.e., at the level of user space
device drivers, through file operations on entries in the
<TT
CLASS="FILENAME"
>/dev</TT
> directory (for access to the
device's functionality), or interactively from the command line
through the <SPAN
CLASS="QUOTE"
>"files"</SPAN
> in the
<TT
CLASS="FILENAME"
>/proc</TT
> directory (which allow to
inspect the status of a <ACRONYM
CLASS="ACRONYM"
>Comedi</ACRONYM
> device).</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x333.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Configuration</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
libcomedi-dev 0.8.1-5ubuntu6 / usr / share / doc / libcomedi-dev / html / index.html
