stv0g/comedilib
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Updated to docbook 4.2. Fixed broken </link> in tutorial.sgml

Browse source
This commit is contained in:
Frank Mori Hess 2006-10-25 18:53:42 +00:00
parent 261de96d3a
commit 01da122c40
6 changed files with 35 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/comedilib.sgml
View file

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

6
doc/glossary.sgml
View file

@ -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>

2
doc/install.sgml
View file

@ -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>

26
doc/intro.sgml
View file

@ -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>

2
doc/reference.sgml
View file

@ -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>

23
doc/tutorial.sgml
View file

@ -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){