Regenerated docs
authorDavid Schleef <ds@schleef.org>
Sun, 15 Jul 2001 23:58:14 +0000 (23:58 +0000)
committerDavid Schleef <ds@schleef.org>
Sun, 15 Jul 2001 23:58:14 +0000 (23:58 +0000)
doc/comedilib-1.html
doc/comedilib-2.html
doc/comedilib-3.html
doc/comedilib-4.html
doc/comedilib-5.html
doc/comedilib-6.html
doc/comedilib.html
doc/comedilib.txt

index 67d8b0f80f6bd0617a77c24622d783fb93b63fd8..186db2ea95d83df36d7a9f047eece7ec3f53f561 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
 <HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.8.1">
  <TITLE>Comedi Documentation: Introduction</TITLE>
  <LINK HREF="comedilib-2.html" REL=next>
 
index b54ebc0b4dacb66e1e90deb0ab3bd2fa7ab6641a..eec582570950b36f5a58f94bfe80f58e25bc9413 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
 <HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.8.1">
  <TITLE>Comedi Documentation: Installation and configuration</TITLE>
  <LINK HREF="comedilib-3.html" REL=next>
  <LINK HREF="comedilib-1.html" REL=previous>
index 1becb2b4cd33ed9d4864d2a3ebfb64f5e205b05d..cc2b1d48d566bb2b1e0484921ce1e89c76e528b6 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
 <HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.8.1">
  <TITLE>Comedi Documentation: Individual drivers</TITLE>
  <LINK HREF="comedilib-4.html" REL=next>
  <LINK HREF="comedilib-2.html" REL=previous>
index e8fa9e56dfa6e9aa222495165ad5d9f96c0b99c4..c054c5c6b56496d0e4f1d520d6a5e1293918a49f 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
 <HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.8.1">
  <TITLE>Comedi Documentation: Writing programs that use comedi and comedilib</TITLE>
  <LINK HREF="comedilib-5.html" REL=next>
  <LINK HREF="comedilib-3.html" REL=previous>
index 311824d6042824cfd3bb7013158ee3a0ce3f2b08..6267789b2ddd71a6f705acf55f219e2b8dd6e918 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
 <HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.8.1">
  <TITLE>Comedi Documentation: Application-specific functions</TITLE>
  <LINK HREF="comedilib-6.html" REL=next>
  <LINK HREF="comedilib-4.html" REL=previous>
@@ -102,7 +102,7 @@ is only accurate to part-per-thousand.</P>
 
 
 
-<H2><A NAME="ss5.3">5.3 Commands</A>
+<H2><A NAME="command_section"></A> <A NAME="ss5.3">5.3 Commands</A>
 </H2>
 
 
@@ -124,7 +124,7 @@ A/D or D/A conversion.  The start and end of the sequence, and
 the start and end of each scan, and each conversion is called an
 event.</P>
 <P>Each of these 5 types of events are caused by a triggering
-source, specified through the *_src members of the
+source, specified through the <CODE>*_src</CODE> members of the
 <A HREF="comedilib-6.html#comedi_cmd">comedi_cmd</A> structure.  The source types are:</P>
 <P>
 <UL>
@@ -139,36 +139,37 @@ source, specified through the *_src members of the
 <LI>TRIG_OTHER: driver-specific meaning</LI>
 </UL>
 </P>
+<P>Not all triggers are applicable to all events.  Supported triggers
+for specific events depend significantly on your particular
+device.  The 
+<A HREF="comedilib-6.html#comedi_get_cmd_src_mask">comedi_get_cmd_src_mask()</A>
+function is useful for determining what triggers a subdevice supports.</P>
 <P>For every trigger, there is a corresponding
-argument (the *_arg members of the 
+argument (the <CODE>*_arg</CODE> members of the 
 <A HREF="comedilib-6.html#comedi_cmd">comedi_cmd</A>
 structure) whose meaning depends on the type of trigger.  The meanings
 of the arguments are as follows:</P>
-
-<P>Not all triggers are applicable to all events.  Supported triggers
-for specific events depends significantly on your particular
-device.</P>
-<P>TRIG_NONE is typically used only as a stop_src.  The arg for TRIG_NONE
+<P>TRIG_NONE is typically used only as a <CODE>stop_src</CODE>.  The argument for TRIG_NONE
 is reserved and should be set to 0.</P>
-<P>TRIG_NOW is most often used as a start_src.  The arg for TRIG_NOW is
+<P>TRIG_NOW is most often used as a <CODE>start_src</CODE>.  The argument for TRIG_NOW is
 the number of nanoseconds between when the command is issued and when
-the event should occur.  In the case of using TRIG now as a start_src,
+the event should occur.  In the case of using TRIG now as a <CODE>start_src</CODE>,
 it indicates a delay between issuing the command and the start of
 acquisition.  Most drivers only support a delay of 0.</P>
 <P>TRIG_FOLLOW is a special type of trigger for events that trigger on
 the completion of some other, logically connected event.  The argument
 is reserved and should be set to 0.  When used
-as a scan_begin_src, it indicates that a trigger should occur as a
+as a <CODE>scan_begin_src</CODE>, it indicates that a trigger should occur as a
 logical continuation of convert events.  This is done in order to
 properly describe boards that do not have separate timers for
-convert and scan_begin events.  When used as a start_src for analog
+convert and scan_begin events.  When used as a <CODE>start_src</CODE> for analog
 output subdevices, it indicates that conversion of output samples
 should begin when samples are written to the buffer.</P>
 <P>TRIG_TIME is reserved for future use.</P>
-<P>TRIG_TIMER is most often used as a convert_src, a scan_begin_src, or
+<P>TRIG_TIMER is most often used as a <CODE>convert_src</CODE>, a <CODE>scan_begin_src</CODE>, or
 both.  It indicates that triggers should occur at a specific rate.
 The argument specifies the interval between triggers in nanoseconds.</P>
-<P>TRIG_COUNT is used for scan_end_src and stop_src.  It indicates that
+<P>TRIG_COUNT is used for <CODE>scan_end_src</CODE> and <CODE>stop_src</CODE>.  It indicates that
 a trigger should occur when the specified number of corresponding
 lower-level triggers (convert and scan_begin, respectively) occur.
 The argument is the count of lower-level triggers.</P>
@@ -178,7 +179,7 @@ The exact meaning of digital line is device-dependent.  Some devices
 have one dedicated line, others may allow generic digital input
 lines to be used.  The argument indicates the particular external
 line to use as the trigger.</P>
-<P>TRIG_INT is typically used as a start_src.  This trigger occurs when
+<P>TRIG_INT is typically used as a <CODE>start_src</CODE>.  This trigger occurs when
 the application performs an INSN_INTTRIG instruction.  Using TRIG_INT
 is a method by which the application can accurately record the time of
 the start of acquisition, since the parsing and setup time of a
@@ -189,18 +190,26 @@ meaning of TRIG_OTHER is driver-specific, and implements a feature
 that otherwise does not fit into the command interface.  Configuration
 of TRIG_OTHER features are done by INSN_CONFIG insns.  The argument
 is reserved and should be set to 0.</P>
-
-<P>The chanlist member of the 
+<P>Ths <CODE>subdev</CODE> member of the 
+<A HREF="comedilib-6.html#comedi_cmd">comedi_cmd</A>
+structure is the index of the subdevice the command is intended for.  The
+<A HREF="comedilib-6.html#comedi_find_subdevice_by_type">comedi_find_subdevice_by_type()</A>
+function can be useful in discovering the index of your desired subdevice.</P>
+<P>The <CODE>chanlist</CODE> member of the 
 <A HREF="comedilib-6.html#comedi_cmd">comedi_cmd</A>
-structure should point to an array whose number of elements is specificed by chanlist_len
+structure should point to an array whose number of elements is specificed by <CODE>chanlist_len</CODE>
 (this will generally be the same as the scan_end_arg).
 The chanlist specifies the sequence of channels and gains (and analog references)
 that should be stepped through for each scan.  The elements of the chanlist array
 should be initialized by packing the channel, range and reference information
 together with the 
-<A HREF="comedilib-6.html#CR_PACK">CR_PACK(channel, range, aref)</A> macro.</P>
+<A HREF="comedilib-6.html#CR_PACK">CR_PACK()</A> macro.</P>
+<P>The <CODE>data</CODE> and <CODE>data_len</CODE> members can be safely ignored when issueing commands
+from a user-space program.  They only have meaning when a command is sent from a kernel
+module using the kcomedilib interface, in which case they specify the buffer where
+the driver should write/read its data to/from.</P>
 <P>The final member of the 
-<A HREF="comedilib-6.html#comedi_cmd">comedi_cmd</A> structure is 'flags'.
+<A HREF="comedilib-6.html#comedi_cmd">comedi_cmd</A> structure is <CODE>flags</CODE>.
 The following flags are valid, and can be bitwise-or'd together.</P>
 <P>
 <UL>
@@ -212,11 +221,12 @@ reduce latency in handling interrupts from your data aquisition hardware.  It ca
 be useful if you are sampling at high frequency, or if your hardware has a small onboard
 fifo.  You must have a real-time kernel (RTAI or RTLinux) and must compile
 comedi with real-time support or this flag will do nothing.</LI>
-<LI>TRIG_CONFIG:        perform configuration, not triggering.</LI>
+<LI>TRIG_CONFIG:        perform configuration, not triggering.  This is a legacy of the
+deprecated comedi_trig_struct, and has no function at present.</LI>
 <LI>TRIG_WAKE_EOS:      some drivers will change their behaviour when this flag is set,
 trying to transfer data at the end of every scan (instead of, for example, passing
 data in chunks whenever the board's onboard fifo is half full).  This flag
-may degrade a driver's performance at higher frequencies.</LI>
+may degrade a driver's performance at high frequencies.</LI>
 <LI>TRIG_WRITE: write to bidirectional devices.  Could be useful in principle, if someone
 wrote a driver that supported commands for a digital i/o device that could do either
 input or output.</LI>
@@ -234,7 +244,15 @@ to do??</LI>
 </P>
 
 
-
+<P>The typical sequence for executing a command is to first send
+the command through
+<A HREF="comedilib-6.html#comedi_command_test">comedi_command_test()</A>
+once or twice.  The test will check that the command is valid for the particular
+device, and often makes some adjustments to the command arguments, which
+can then be read back by the user to see the actual values used.  The
+command is executed with
+<A HREF="comedilib-6.html#comedi_command">comedi_command()</A>.  For input/output commands, data
+is read from or written to the device file /dev/comedi[0..3] you are using.</P>
 
 <HR>
 <A HREF="comedilib-6.html">Next</A>
index 0c2c13ed8790b7a806db2dd2e8b94587b9b46849..81135d56d20fd48729d9fec0bac1716a1be551b6 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
 <HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.8.1">
  <TITLE>Comedi Documentation: Libcomedi Reference</TITLE>
  <LINK HREF="comedilib-5.html" REL=previous>
  <LINK HREF="comedilib.html#toc6" REL=contents>
@@ -20,10 +20,36 @@ Next
 
 
 
-<H3><A NAME="CR_PACK"></A> CR_PACK(channel, range, aref)</H3>
+<H3><A NAME="CR_PACK"></A> CR_PACK()</H3>
 
 
-<P>undocumented</P>
+<P><CODE>CR_PACK(channel, range, aref)</CODE></P>
+<P><CODE>CR_PACK</CODE> is used to initialize the elements of the <CODE>chanlist array</CODE> in the
+<A HREF="#comedi_cmd">comedi_cmd</A> structure, and the <CODE>chanspec</CODE> member
+of the 
+<A HREF="#comedi_insn">comedi_insn</A> structure.</P>
+<P>The <CODE>channel</CODE> argument is the channel you wish to use, with the channel numbering
+starting at zero.</P>
+<P>The <CODE>range</CODE> is an index, starting at zero, whose meaning
+is device dependent.  The
+<A HREF="#comedi_get_n_ranges">comedi_get_n_ranges()</A> and
+<A HREF="#comedi_get_range">comedi_get_range()</A> functions
+are useful in discovering information about the available ranges.</P>
+<P>The <CODE>aref</CODE> argument indicates what reference you want the device to use.  It
+can be any of the following:
+<UL>
+<LI>AREF_GROUND is for inputs/outputs referenced to ground</LI>
+<LI>AREF_COMMON is for a `common' reference (the low inputs of all the channels are tied
+together, but are isolated from ground)</LI>
+<LI>AREF_DIFF   is for differential inputs/outputs</LI>
+<LI>AREF_OTHER  is for any reference that does not fit into the above categories</LI>
+</UL>
+
+Particular drivers may or may not use the AREF flags.  If they are not supported, they
+are silently ignored.</P>
+
+<P>Source: <CODE>/include/comedi.h</CODE></P>
+
 
 <H3>RANGE_LENGTH() <I>(deprecated)</I></H3>
 
@@ -142,9 +168,42 @@ details.</P>
 <H3><A NAME="comedi_cmd"></A> comedi_cmd</H3>
 
 
-<P>undocumented</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+typedef struct comedi_cmd_struct comedi_cmd;
 
-<P>Related functions are described in section XXX.</P>
+struct comedi_cmd_struct{
+        unsigned int subdev;
+        unsigned int flags;
+
+        unsigned int start_src;
+        unsigned int start_arg;
+
+        unsigned int scan_begin_src;
+        unsigned int scan_begin_arg;
+
+        unsigned int convert_src;
+        unsigned int convert_arg;
+
+        unsigned int scan_end_src;
+        unsigned int scan_end_arg;
+
+        unsigned int stop_src;
+        unsigned int stop_arg;
+
+        unsigned int *chanlist;
+        unsigned int chanlist_len;
+
+        sampl_t *data;
+        unsigned int data_len;
+};
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+
+<P>More information on using commands can be found in the
+<A HREF="comedilib-5.html#command_section">command</A> section.</P>
 
 <P>This structure is defined as part of the Comedi kernel interface.</P>
 
@@ -189,7 +248,14 @@ order to match <CODE>fclose</CODE>.</P>
 
 
 <P><CODE>int comedi_command(comedi_t *it, comedi_cmd *cmd);</CODE></P>
-<P>undocumented</P>
+<P>Issues the command pointed at by <CODE>cmd</CODE> to the open device <CODE>it</CODE>.  It
+is usually necessary to pass the command through
+<A HREF="#comedi_command_test">comedi_command_test()</A> to
+fix up the command before it can be successfully executed with
+<CODE>comedi_command()</CODE>.
+See
+<A HREF="comedilib-5.html#command_section">commands</A> for more information.</P>
+
 <P>Source: <CODE>/lib/comedi.c</CODE></P>
 
 
@@ -197,7 +263,36 @@ order to match <CODE>fclose</CODE>.</P>
 
 
 <P><CODE>int comedi_command_test(comedi_t *it, comedi_cmd *cmd);</CODE></P>
-<P>undocumented</P>
+
+<P>Tests and fixes up the command pointed at by <CODE>cmd</CODE> according
+to the limitations of the driver configured on the open device <CODE>it</CODE>.
+The return value has the following meaning:
+<UL>
+<LI>0:  the command passed the test and can be successfully executed
+by 
+<A HREF="#comedi_command">comedi_command()</A>.  The one exception
+to this rule is that the test will allow a NULL chanlist for the command.</LI>
+<LI>1: invalid trigger.  One or more of the trigger sources (the *_src members
+of the 
+<A HREF="#comedi_cmd">comedi_cmd</A> structure) is not
+supported by the driver.</LI>
+<LI>2: incompatible triggers.  Two or more of the triggers selected are
+incompatible with each other.  For example, a driver might allow either
+the scan_begin_src or the convert_src to be TRIG_TIMER, but not both.</LI>
+<LI>3: argument invalid.  One or more argument is invalid, for example
+a timing argument might be in excess of the card's maximum speed.  The
+command test will correct the arguments by modifying the command pointed
+at by <CODE>cmd</CODE>.</LI>
+<LI>4: argument fix up.  The command underwent minor adjustment and should
+now be valid.  For example, a timing argument might not be exactly achievable
+by the card so the timing argument will be adjusted to the actual timing
+the card will use.</LI>
+<LI>negative: some other error has occured.</LI>
+</UL>
+
+See
+<A HREF="comedilib-5.html#command_section">commands</A> for more information.</P>
+
 <P>Source: <CODE>/lib/comedi.c</CODE></P>
 
 
@@ -417,7 +512,7 @@ is the same as the C library.</P>
 
 
 
-<H3>comedi_find_subdevice_by_type()</H3>
+<H3><A NAME="comedi_find_subdevice_by_type"></A> comedi_find_subdevice_by_type()</H3>
 
 
 <P><CODE>int comedi_find_subdevice_by_type(comedi_t *it,int type,unsigned int
@@ -512,7 +607,7 @@ and having index <CODE>subdevice</CODE>.  This function returns -1 on error.</P>
 
 
 
-<H3>comedi_get_n_ranges()</H3>
+<H3><A NAME="comedi_get_n_ranges"></A> comedi_get_n_ranges()</H3>
 
 
 <P><CODE>int comedi_get_n_ranges(comedi_t *it,unsigned int subdevice, unsigned int
@@ -535,7 +630,7 @@ number of subdevices associated with the comedi descriptor
 
 
 
-<H3>comedi_get_range()</H3>
+<H3><A NAME="comedi_get_range"></A> comedi_get_range()</H3>
 
 
 <P><CODE>comedi_range * comedi_get_range(comedi_t *it,unsigned int subdevice,unsigned int chan,unsigned int
@@ -907,8 +1002,6 @@ returns 0.  On error, this function returns -1.</P>
 <LI>comedi_get_cmd_src_mask()</LI>
 <LI>comedi_get_cmd_generic_timed()</LI>
 <LI>comedi_cancel()</LI>
-<LI>comedi_command()</LI>
-<LI>comedi_command_test()</LI>
 <LI>comedi_poll()</LI>
 <LI>comedi_get_buffer_contents()</LI>
 <LI>comedi_mark_buffer_read()</LI>
index 593b8811ac53c1156a0a94aca7872affc1d29caf..3a8eac00a07c2fc04b2d789a4946c1cdafa271c5 100644 (file)
@@ -1,7 +1,7 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
 <HEAD>
- <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.8.1">
  <TITLE>Comedi Documentation</TITLE>
  <LINK HREF="comedilib-1.html" REL=next>
 
index d044ac79f1ce41c44eb72aa8931f97023ea10881..b2d8258d7d615573e5a95324f9073b35fca53ad7 100644 (file)
        int main(int argc,char *argv[])
        {
                comedi_t *it;
-               int chan=0;
                lsampl_t data;
 
                it=comedi_open("/dev/comedi0");
 
-               comedi_data_read(it,subdev,chan,range,aref,XXX data);
+               comedi_data_read(it,subdev,chan,range,aref,&data);
 
                printf("%d\n",data);
 
 
 
 
-  Should be understandable.  Open the device, get the data, print it
-  out.  This is basically the guts of demo/inp.c, without error checking
-  or fancy options.  Compile it using
+  Should be understandable: open the device, get the data, print it out.
+  This is basically the guts of demo/inp.c, without error checking or
+  fancy options.  Compile it using
 
 
 
   4\b4.\b.2\b2.\b.  C\bCo\bon\bnv\bve\ber\brt\bti\bin\bng\bg s\bsa\bam\bmp\bpl\ble\bes\bs t\bto\bo v\bvo\bol\blt\bta\bag\bge\bes\bs
 
 
-  If you selected an analog input subdevice, you should notice that the
-  output of tut1 is a number between 0 and 4095, or 0 and 65535,
+  If you selected an analog input subdevice, you probably noticed that
+  the output of tut1 is a number between 0 and 4095, or 0 and 65535,
   depending on the number of bits in the A/D converter.  Comedi samples
   are a\bal\blw\bwa\bay\bys\bs unsigned, with 0 representing the lowest voltage of the
   ADC, and 4095 the highest.  Comedi compensates for anything else the
   Most devices give you a choice of gain and unipolar/bipolar input, and
   Comedi allows you to select which of these to use.  This parameter is
   called the "range parameter", since it specifies the "input range" for
-  analog input (or "output range" analog output.)  The range parameter
-  represents both the gain and the unipolar/bipolar aspects.
+  analog input (or "output range" for analog output.)  The range
+  parameter represents both the gain and the unipolar/bipolar aspects.
 
   Comedi keeps the number of available ranges and the largest sample
   value for each subdevice/channel combination.  (Some devices allow
   added what we've learned.
        #include <stdio.h>      /* for printf() */
        #include <comedi.h>     /* also included by comedilib.h */
-       #include <comedilib.h>  /* for comedi_get() */
+       #include <comedilib.h>  /* 'cuz we're using comedilib */
 
        int subdev = 0;         /* change this to your input subdevice */
        int chan = 0;           /* change this to your channel */
 
                rangetype=comedi_get_rangetype(cf,subdev,chan);
 
-               comedi_data_read(cf->fd,subdev,chan,range,aref,XXX data);
+               comedi_data_read(cf->fd,subdev,chan,range,aref,&data);
 
                volts=comedi_to_phys(data,rangetype,range,maxdata);
 
   The source types are:
 
 
-  +\bo  TRIG_NONE:      don't ever cause an event, sometimes used as a
-     stop_src.
+  +\bo  TRIG_NONE:      don't ever cause an event
 
-  +\bo  TRIG_NOW:       cause event to occur immediately, the most common
-     start_src.  It is also used sometimes as a convert_src for 'burst
-     mode' aquisition where the individual channels in a scan are
-     scanned through as quickly as possible.
+  +\bo  TRIG_NOW:       cause event to occur immediately
 
-  +\bo  TRIG_FOLLOW:    see notes below, usually used as a scan_begin_src.
+  +\bo  TRIG_FOLLOW:    see notes below
 
   +\bo  TRIG_TIME:      cause event to occur at a particular time
 
-  +\bo  TRIG_TIMER:     cause event to occur repeatedly at a specific rate,
-     often used as a scan_begin_src or convert_src.
+  +\bo  TRIG_TIMER:     cause event to occur repeatedly at a specific rate
+
+  +\bo  TRIG_COUNT:     cause event when count reaches specific value
 
-  +\bo  TRIG_COUNT:     cause event when count reaches specific value,
-     almost always used as the scan_end_src and often for stop_src.
+  +\bo  TRIG_EXT:       external signal causes event
 
-  +\bo  TRIG_EXT:       external signal causes event, used as start_src for
-     externally triggered conversions, and as scan_begin_src or
-     convert_src for externally paced conversions.
+  +\bo  TRIG_INT:       internal signal causes event
 
-  +\bo  TRIG_INT:       internal signal causes event, will probably be used
-     as start_src for output commands in the future.
+  +\bo  TRIG_OTHER:     driver-specific meaning
+
+  Not all triggers are applicable to all events.  Supported triggers for
+  specific events depend significantly on your particular device.  The
+  ``comedi_get_cmd_src_mask()'' function is useful for determining what
+  triggers a subdevice supports.
 
   For every trigger, there is a corresponding argument (the *_arg
   members of the ``comedi_cmd'' structure) whose meaning depends on the
   type of trigger.  The meanings of the arguments are as follows:
 
-
-  +\bo  trigger src = TRIG_NONE: argument has no meaning
-
-  +\bo  trigger src = TRIG_NOW: argument is the delay in nanoseconds before
-     triggering
-
-  +\bo  trigger src = TRIG_FOLLOW: argument has no meaning
-
-  +\bo  trigger src = TRIG_TIME: argument is the time at which to trigger
-     (in what units??), but no drivers support this yet.
-
-  +\bo  trigger src = TRIG_TIMER: argument is the period in nanoseconds
-     between triggers
-
-
-  +\bo  trigger src = TRIG_COUNT: argument is the number of 'counts' per
-     trigger.  For comedi_cmd.stop_arg, this is the number of scans to
-     perform before ending aquisition.  For comedi_cmd.scan_end_arg,
-     this is the number of conversions to perform per scan.
-
-  +\bo  trigger src = TRIG_EXT: argument is the digital input channel to
-     trigger on.
-
-  +\bo  trigger src = TRIG_INT: argument meaning is unknown??
-
-  Not all triggers are applicable to all events.  Supported triggers for
-  specific events depends significantly on your particular device.
-
-  TRIG_FOLLOW is a special type of trigger for scan_begin events that
-  triggers on the next lower level trigger, in this case, the trigger
-  for convert events.  It may or may not be supported.  Later, it may
-  also be used for start events if you want to chain multiple commands.
+  TRIG_NONE is typically used only as a stop_src.  The argument for
+  TRIG_NONE is reserved and should be set to 0.
+
+  TRIG_NOW is most often used as a start_src.  The argument for TRIG_NOW
+  is the number of nanoseconds between when the command is issued and
+  when the event should occur.  In the case of using TRIG now as a
+  start_src, it indicates a delay between issuing the command and the
+  start of acquisition.  Most drivers only support a delay of 0.
+
+  TRIG_FOLLOW is a special type of trigger for events that trigger on
+  the completion of some other, logically connected event.  The argument
+  is reserved and should be set to 0.  When used as a scan_begin_src, it
+  indicates that a trigger should occur as a logical continuation of
+  convert events.  This is done in order to properly describe boards
+  that do not have separate timers for convert and scan_begin events.
+  When used as a start_src for analog output subdevices, it indicates
+  that conversion of output samples should begin when samples are
+  written to the buffer.
+
+  TRIG_TIME is reserved for future use.
+
+  TRIG_TIMER is most often used as a convert_src, a scan_begin_src, or
+  both.  It indicates that triggers should occur at a specific rate.
+  The argument specifies the interval between triggers in nanoseconds.
+
+  TRIG_COUNT is used for scan_end_src and stop_src.  It indicates that a
+  trigger should occur when the specified number of corresponding lower-
+  level triggers (convert and scan_begin, respectively) occur.  The
+  argument is the count of lower-level triggers.
+
+  TRIG_EXT can be useful as any of the trigger sources.  It indicates
+  that an external digital line should be used to trigger the event.
+  The exact meaning of digital line is device-dependent.  Some devices
+  have one dedicated line, others may allow generic digital input lines
+  to be used.  The argument indicates the particular external line to
+  use as the trigger.
+
+  TRIG_INT is typically used as a start_src.  This trigger occurs when
+  the application performs an INSN_INTTRIG instruction.  Using TRIG_INT
+  is a method by which the application can accurately record the time of
+  the start of acquisition, since the parsing and setup time of a
+  particular command may be significant.  The argument associated with
+  TRIG_INT is reserved and should be set to 0.
+
+  TRIG_OTHER can be useful as any of the trigger sources.  The exact
+  meaning of TRIG_OTHER is driver-specific, and implements a feature
+  that otherwise does not fit into the command interface.  Configuration
+  of TRIG_OTHER features are done by INSN_CONFIG insns.  The argument is
+  reserved and should be set to 0.
+
+  Ths subdev member of the ``comedi_cmd'' structure is the index of the
+  subdevice the command is intended for.  The
+  ``comedi_find_subdevice_by_type()'' function can be useful in
+  discovering the index of your desired subdevice.
 
   The chanlist member of the ``comedi_cmd'' structure should point to an
   array whose number of elements is specificed by chanlist_len (this
   specifies the sequence of channels and gains (and analog references)
   that should be stepped through for each scan.  The elements of the
   chanlist array should be initialized by packing the channel, range and
-  reference information together with the ``CR_PACK(channel, range,
-  aref)'' macro.
+  reference information together with the ``CR_PACK()'' macro.
 
-  The final member of the ``comedi_cmd'' structure is 'flags'.  The
+  The data and data_len members can be safely ignored when issueing
+  commands from a user-space program.  They only have meaning when a
+  command is sent from a kernel module using the kcomedilib interface,
+  in which case they specify the buffer where the driver should
+  write/read its data to/from.
+
+  The final member of the ``comedi_cmd'' structure is flags.  The
   following flags are valid, and can be bitwise-or'd together.
 
 
      must have a real-time kernel (RTAI or RTLinux) and must compile
      comedi with real-time support or this flag will do nothing.
 
-  +\bo  TRIG_CONFIG:    perform configuration, not triggering.
+  +\bo  TRIG_CONFIG:    perform configuration, not triggering.  This is a
+     legacy of the deprecated comedi_trig_struct, and has no function at
+     present.
 
   +\bo  TRIG_WAKE_EOS:  some drivers will change their behaviour when this
      flag is set, trying to transfer data at the end of every scan
      (instead of, for example, passing data in chunks whenever the
      board's onboard fifo is half full).  This flag may degrade a
-     driver's performance at higher frequencies.
+     driver's performance at high frequencies.
 
   +\bo  TRIG_WRITE:     write to bidirectional devices.  Could be useful in
      principle, if someone wrote a driver that supported commands for a
 
   +\bo  TRIG_ROUND_DOWN: round period down.
 
-
   +\bo  TRIG_ROUND_UP: round period up.
 
   +\bo  TRIG_ROUND_UP_NEXT: this one doesn't do anything, and I don't know
 
 
 
+  The typical sequence for executing a command is to first send the
+  command through ``comedi_command_test()'' once or twice.  The test
+  will check that the command is valid for the particular device, and
+  often makes some adjustments to the command arguments, which can then
+  be read back by the user to see the actual values used.  The command
+  is executed with ``comedi_command()''.  For input/output commands,
+  data is read from or written to the device file /dev/comedi[0..3] you
+  are using.
+
+
   6\b6.\b.  L\bLi\bib\bbc\bco\bom\bme\bed\bdi\bi R\bRe\bef\bfe\ber\bre\ben\bnc\bce\be
 
 
 
 
 
-  6\b6.\b.1\b1.\b.1\b1.\b.  C\bCR\bR_\b_P\bPA\bAC\bCK\bK(\b(c\bch\bha\ban\bnn\bne\bel\bl,\b, r\bra\ban\bng\bge\be,\b, a\bar\bre\bef\bf)\b)
+  6\b6.\b.1\b1.\b.1\b1.\b.  C\bCR\bR_\b_P\bPA\bAC\bCK\bK(\b()\b)
 
 
-  undocumented
+  CR_PACK(channel, range, aref)
+
+  CR_PACK is used to initialize the elements of the chanlist array in
+  the ``comedi_cmd'' structure, and the chanspec member of the
+  ``comedi_insn'' structure.
+
+  The channel argument is the channel you wish to use, with the channel
+  numbering starting at zero.
+
+  The range is an index, starting at zero, whose meaning is device
+  dependent.  The ``comedi_get_n_ranges()'' and ``comedi_get_range()''
+  functions are useful in discovering information about the available
+  ranges.
+
+  The aref argument indicates what reference you want the device to use.
+  It can be any of the following:
+
+  +\bo  AREF_GROUND     is for inputs/outputs referenced to ground
+
+  +\bo  AREF_COMMON     is for a `common' reference (the low inputs of all
+     the channels are tied together, but are isolated from ground)
+
+  +\bo  AREF_DIFF       is for differential inputs/outputs
+
+  +\bo  AREF_OTHER      is for any reference that does not fit into the
+     above categories
+
+     Particular drivers may or may not use the AREF flags.  If they are
+     not supported, they are silently ignored.
+
+
+  Source: /include/comedi.h
+
 
 
   6\b6.\b.1\b1.\b.2\b2.\b.  R\bRA\bAN\bNG\bGE\bE_\b_L\bLE\bEN\bNG\bGT\bTH\bH(\b()\b) (\b(d\bde\bep\bpr\bre\bec\bca\bat\bte\bed\bd)\b)
   6\b6.\b.2\b2.\b.6\b6.\b.  c\bco\bom\bme\bed\bdi\bi_\b_c\bcm\bmd\bd
 
 
-  undocumented
+
+       typedef struct comedi_cmd_struct comedi_cmd;
+
+       struct comedi_cmd_struct{
+               unsigned int subdev;
+               unsigned int flags;
+
+               unsigned int start_src;
+               unsigned int start_arg;
+
+               unsigned int scan_begin_src;
+               unsigned int scan_begin_arg;
+
+               unsigned int convert_src;
+               unsigned int convert_arg;
+
+               unsigned int scan_end_src;
+               unsigned int scan_end_arg;
+
+               unsigned int stop_src;
+               unsigned int stop_arg;
+
+               unsigned int *chanlist;
+               unsigned int chanlist_len;
+
+               sampl_t *data;
+               unsigned int data_len;
+       };
 
 
-  Related functions are described in section XXX.
+
+  More information on using commands can be found in the ``command''
+  section.
 
 
   This structure is defined as part of the Comedi kernel interface.
 
   int comedi_command(comedi_t *it, comedi_cmd *cmd);
 
-  undocumented
+  Issues the command pointed at by cmd to the open device it.  It is
+  usually necessary to pass the command through
+  ``comedi_command_test()'' to fix up the command before it can be
+  successfully executed with comedi_command().  See ``commands'' for
+  more information.
+
 
   Source: /lib/comedi.c
 
 
   int comedi_command_test(comedi_t *it, comedi_cmd *cmd);
 
-  undocumented
+
+  Tests and fixes up the command pointed at by cmd according to the
+  limitations of the driver configured on the open device it.  The
+  return value has the following meaning:
+
+  +\bo  0:      the command passed the test and can be successfully
+     executed by ``comedi_command()''.  The one exception to this rule
+     is that the test will allow a NULL chanlist for the command.
+
+  +\bo  1: invalid trigger.  One or more of the trigger sources (the *_src
+     members of the ``comedi_cmd'' structure) is not supported by the
+     driver.
+
+  +\bo  2: incompatible triggers.  Two or more of the triggers selected are
+     incompatible with each other.  For example, a driver might allow
+     either the scan_begin_src or the convert_src to be TRIG_TIMER, but
+     not both.
+
+  +\bo  3: argument invalid.  One or more argument is invalid, for example
+     a timing argument might be in excess of the card's maximum speed.
+     The command test will correct the arguments by modifying the
+     command pointed at by cmd.
+
+  +\bo  4: argument fix up.  The command underwent minor adjustment and
+     should now be valid.  For example, a timing argument might not be
+     exactly achievable by the card so the timing argument will be
+     adjusted to the actual timing the card will use.
+
+  +\bo  negative: some other error has occured.
+
+     See ``commands'' for more information.
+
 
   Source: /lib/comedi.c
 
 
   +\bo  comedi_cancel()
 
-  +\bo  comedi_command()
-
-  +\bo  comedi_command_test()
-
   +\bo  comedi_poll()
 
   +\bo  comedi_get_buffer_contents()