Updated to docbook 4.2. Fixed broken </link> in tutorial.sgml
This commit is contained in:
parent
261de96d3a
commit
01da122c40
6 changed files with 35 additions and 35 deletions
|
@ -1,4 +1,4 @@
|
|||
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
|
||||
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [
|
||||
<!ENTITY intro SYSTEM "intro.sgml">
|
||||
<!ENTITY install SYSTEM "install.sgml">
|
||||
<!ENTITY tutorial SYSTEM "tutorial.sgml">
|
||||
|
@ -14,10 +14,9 @@
|
|||
]>
|
||||
|
||||
<article>
|
||||
|
||||
<artheader>
|
||||
<articleinfo>
|
||||
<title>
|
||||
Comedi
|
||||
Comedi
|
||||
</title>
|
||||
<subtitle>
|
||||
The <emphasis>Control and Measurement Device Interface</emphasis>
|
||||
|
@ -104,7 +103,7 @@ USA.
|
|||
</para>
|
||||
</legalnotice>
|
||||
|
||||
</artheader>
|
||||
</articleinfo>
|
||||
|
||||
&intro;
|
||||
|
||||
|
@ -130,7 +129,7 @@ USA.
|
|||
&comedi; Reference
|
||||
</title>
|
||||
<para>
|
||||
Reference for
|
||||
Reference for
|
||||
<link linkend="constantsmacros">constants and macros</link>,
|
||||
<link linkend="datatypesstructures">data types and structures</link>,
|
||||
and <link linkend="functionreference">functions</link>.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> -->
|
||||
<!-- <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook V4.2//EN"> -->
|
||||
|
||||
<glossary id="comedilib-glossary">
|
||||
<title>
|
||||
|
@ -29,7 +29,7 @@ buffer
|
|||
&comedi; uses permanently allocated kernel memory for streaming input
|
||||
and output to store data that has been measured by a device, but has
|
||||
not been read by an application. These buffers can be resized by the
|
||||
Comedilib function <function>comedi_buffer_XXX()</function> or the
|
||||
Comedilib function <function>comedi_buffer_XXX()</function> or the
|
||||
<function>comedi_config</function>
|
||||
utility.
|
||||
</para>
|
||||
|
@ -45,7 +45,7 @@ buffer overflow
|
|||
This is an error message that indicates that the driver ran out of
|
||||
space in a &comedi; buffer to put samples. It means that the application
|
||||
is not copying data out of the buffer quickly enough. Often, this
|
||||
problem can be fixed by making the &comedi; buffer larger. See
|
||||
problem can be fixed by making the &comedi; buffer larger. See
|
||||
<function>comedi_buffer_XXX</function> for more information.
|
||||
</para>
|
||||
</glossdef>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> -->
|
||||
<!-- <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook V4.2//EN"> -->
|
||||
|
||||
<section id="install">
|
||||
<title>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> -->
|
||||
<!-- <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook V4.2//EN"> -->
|
||||
|
||||
<section id="introduction">
|
||||
|
||||
|
@ -52,7 +52,7 @@ configuration and calibration utilities, and demonstration programs.
|
|||
the same interface as <emphasis>comedilib</emphasis> in kernel space,
|
||||
and suitable for <emphasis>real-time</emphasis> tasks. It is
|
||||
effectively a <quote>kernel library</quote> for using &comedi; from
|
||||
real-time tasks.
|
||||
real-time tasks.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -99,7 +99,7 @@ encoders, pulse generators, frequency and pulse timers, etc.).
|
|||
Schleef designed a structure which is a balance between
|
||||
<emphasis>modularity</emphasis> and <emphasis>complexity</emphasis>:
|
||||
it's fairly easy to integrate a new card because most of the
|
||||
infrastructure part of other, similar drivers can be reused, and
|
||||
infrastructure part of other, similar drivers can be reused, and
|
||||
learning the generic and hence somewhat <quote>heavier</quote> &comedi;
|
||||
API doesn't scare away new contributors from integrating their drivers
|
||||
into the &comedi; framework.
|
||||
|
@ -286,8 +286,8 @@ available in the kernel of the real-time operating systems
|
|||
<ulink
|
||||
url="http://www.rtlinux-gpl.org/">RTLinux/GPL
|
||||
</ulink>
|
||||
or <ulink url="http://www.rtai.org">RTAI</ulink>.
|
||||
The APIs of RTAI and RTLinux/Free differ in
|
||||
or <ulink url="http://www.rtai.org">RTAI</ulink>.
|
||||
The APIs of RTAI and RTLinux/Free differ in
|
||||
different ways, so the &comedi; developers have spent a lot of efforts
|
||||
to make generic wrappers to the required RTOS primitives: timers,
|
||||
memory allocation, registration of interrupt handlers, etc.
|
||||
|
@ -333,7 +333,7 @@ memory.
|
|||
<listitem>
|
||||
<para>
|
||||
<emphasis role="strong">Pulse</emphasis>-based signals (counters,
|
||||
timers, encoders, etc.) are conceptually
|
||||
timers, encoders, etc.) are conceptually
|
||||
only a bit more complex than digital inputs and outputs, in that
|
||||
they only add some <emphasis>timing specifications</emphasis> to the
|
||||
signal. &comedi; has still only a limited number of drivers for this
|
||||
|
@ -378,7 +378,7 @@ outputs. Each sub-device has parameters for: the number of channel
|
|||
and the type of the channels.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis role="strong">Device</emphasis>: a set of sub-devices that are physically implemented on the
|
||||
|
@ -398,7 +398,7 @@ sub-device with two analog output channels, and a
|
|||
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 <quote>sub-devices</quote> in
|
||||
special components are also classified as <quote>sub-devices</quote> in
|
||||
&comedi;.
|
||||
</para>
|
||||
|
||||
|
@ -566,7 +566,7 @@ Scans are not directly available as stand-alone function calls in the
|
|||
<emphasis role="strong">Command</emphasis>: a command is
|
||||
<emphasis>sequence</emphasis> of
|
||||
<emphasis>scans</emphasis>, for which conditions have been specified
|
||||
that determine when the acquisition will start and stop. A
|
||||
that determine when the acquisition will start and stop. A
|
||||
<function>comedi_command()</function> function call generates
|
||||
<emphasis role="strong">aynchronous</emphasis> data acquisition:
|
||||
as soon as the command information has been filled in, the
|
||||
|
@ -592,7 +592,7 @@ prepared (but not started) the hardware for the acquisition.
|
|||
The command functionality is very configurable with respect to
|
||||
choosing which <emphasis role="strong">events</emphasis> will signal
|
||||
the starting or stopping of the programmed acquisition: external triggers,
|
||||
internal triggers, end of scan interrupts, timers, etc.
|
||||
internal triggers, end of scan interrupts, timers, etc.
|
||||
The user of the driver can execute a &comedi;
|
||||
<emphasis>instruction</emphasis> that sends a
|
||||
trigger signal to the device driver. What the driver does exactly with
|
||||
|
@ -606,7 +606,7 @@ instruction or command that initiated the current acquisition.
|
|||
</para>
|
||||
<para>
|
||||
Typically, there is one synchronous triggering instruction for each
|
||||
<emphasis>subdevice</emphasis>.
|
||||
<emphasis>subdevice</emphasis>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -678,7 +678,7 @@ 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
|
||||
different when used in real-time
|
||||
(<application>RTAI</application> or
|
||||
<application>RTLinux/Free</application>) or non real-time, but both
|
||||
contexts are encapsulated wihting the same &comedi; calls.
|
||||
|
@ -699,7 +699,7 @@ device drivers, through file operations on entries in the
|
|||
device's functionality), or interactively from the command line
|
||||
through the <quote>files</quote> in the
|
||||
<filename class=directory>/proc</filename> directory (which allow to
|
||||
inspect the status of a &comedi; device).
|
||||
inspect the status of a &comedi; device).
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN" -->
|
||||
<!-- <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN" -->
|
||||
|
||||
<section id="comedi-comedilib-h">
|
||||
<title>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN" "docbook/dtd/3.1/docbook.dtd"> -->
|
||||
<!-- <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.2//EN" "docbook/dtd/4.2/docbook.dtd"> -->
|
||||
|
||||
<section id="writingprograms">
|
||||
<title>
|
||||
|
@ -134,7 +134,7 @@ The number of available ranges can be found using the function:
|
|||
For each value of the range parameter for a particular
|
||||
subdevice/channel, you can get range information using:
|
||||
<programlisting>
|
||||
<link linkend="ref-type-comedi-range">comedi_range</link> * <link linkend="func-ref-comedi-get-range">comedi_get_range</link>(<link linkend="ref-type-comedi-t">comedi_t</link> * device,
|
||||
<link linkend="ref-type-comedi-range">comedi_range</link> * <link linkend="func-ref-comedi-get-range">comedi_get_range</link>(<link linkend="ref-type-comedi-t">comedi_t</link> * device,
|
||||
unsigned int subdevice, unsigned int channel, unsigned int range);
|
||||
</programlisting>
|
||||
which returns a pointer to a
|
||||
|
@ -206,12 +206,12 @@ file=<link linkend="func-ref-comedi-open">comedi_open</link>("/dev/comedi0");
|
|||
</programlisting>
|
||||
|
||||
<para>
|
||||
where <parameter class=function>file</parameter> is of type
|
||||
where <parameter class=function>file</parameter> is of type
|
||||
<parameter>(<link linkend="ref-type-comedi-t">comedi_t</link> *)</parameter>.
|
||||
This function calls <function>open()</function>, as done explicitly in
|
||||
a previous section, but also fills the
|
||||
<link linkend="ref-type-comedi-t">comedi_t</link>
|
||||
structure with lots of goodies; this information will be useful soon.
|
||||
structure with lots of goodies; this information will be useful soon.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -226,7 +226,8 @@ maxdata=<link linkend="func-ref-comedi-get-maxdata">comedi_get_maxdata</link>(fi
|
|||
Wow! How easy. And the range information?
|
||||
|
||||
<programlisting>
|
||||
<link linkend="ref-type-comedi-range">comedi_range</link> * <link linkend="func-ref-comedi-get-range">comedi_get_range(<link linkend="ref-type-comedi-t">comedi_t</link>comedi_t</link> *it,unsigned int subdevice,unsigned int chan,unsigned int range);
|
||||
<link linkend="ref-type-comedi-range">comedi_range</link> * <link linkend="func-ref-comedi-get-range">comedi_get_range</link>
|
||||
(<link linkend="ref-type-comedi-t">comedi_t</link>comedi_t *it,unsigned int subdevice,unsigned int chan,unsigned int range);
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
@ -386,7 +387,7 @@ Your fourth &comedi; program: commands
|
|||
<para>
|
||||
This example programs an analog output subdevice with &comedi;'s most
|
||||
powerful acquisition function, the asynchronous
|
||||
<link linkend="commandsstreaming">command</link>, to generate a waveform.
|
||||
<link linkend="commandsstreaming">command</link>, to generate a waveform.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -407,11 +408,11 @@ for output to the DAC.
|
|||
<para>
|
||||
Once you have
|
||||
issued the command, &comedi; expects you to keep the buffer full of
|
||||
data to output to the acquisition card. This is done by
|
||||
<function>write()</function>. Since there may be a delay between the
|
||||
data to output to the acquisition card. This is done by
|
||||
<function>write()</function>. Since there may be a delay between the
|
||||
<link linkend="func-ref-comedi-command">comedi_command()</link>
|
||||
and a subsequent <function>write()</function>, you
|
||||
should fill the buffer using <function>write()</function> before you call
|
||||
should fill the buffer using <function>write()</function> before you call
|
||||
<link linkend="func-ref-comedi-command">comedi_command()</link>,
|
||||
as is done here.
|
||||
<programlisting>
|
||||
|
@ -480,7 +481,7 @@ int main(int argc, char *argv[])
|
|||
unsigned int maxdata;
|
||||
<link linkend="ref-type-comedi-range">comedi_range</link> *rng;
|
||||
int ret;
|
||||
<link linkend="ref-type-lsampl-t">lsampl_t</link> insn_data = 0;
|
||||
<link linkend="ref-type-lsampl-t">lsampl_t</link> insn_data = 0;
|
||||
|
||||
parse_options(argc,argv);
|
||||
|
||||
|
@ -540,7 +541,7 @@ int main(int argc, char *argv[])
|
|||
exit(1);
|
||||
}
|
||||
printf("m=%d\n",m);
|
||||
|
||||
|
||||
ret = <link linkend="comedi-internal-trigger">comedi_internal_trigger</link>(dev, subdevice, 0);
|
||||
<![CDATA[
|
||||
if(ret<0){
|
||||
|
|
Loading…
Add table
Reference in a new issue