From: Frank Mori Hess Date: Wed, 25 Oct 2006 18:53:42 +0000 (+0000) Subject: Updated to docbook 4.2. Fixed broken in tutorial.sgml X-Git-Tag: v0_8_0~48 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=01da122c40e55971ab6bc3a7071dfe1c076d9361;p=comedilib.git Updated to docbook 4.2. Fixed broken in tutorial.sgml --- diff --git a/doc/comedilib.sgml b/doc/comedilib.sgml index 14e9a77..28fc36c 100644 --- a/doc/comedilib.sgml +++ b/doc/comedilib.sgml @@ -1,4 +1,4 @@ - @@ -14,10 +14,9 @@ ]>
- - + - Comedi + Comedi The Control and Measurement Device Interface @@ -104,7 +103,7 @@ USA. - + &intro; @@ -130,7 +129,7 @@ USA. &comedi; Reference - Reference for + Reference for constants and macros, data types and structures, and functions. diff --git a/doc/glossary.sgml b/doc/glossary.sgml index b673253..79e23f2 100644 --- a/doc/glossary.sgml +++ b/doc/glossary.sgml @@ -1,4 +1,4 @@ - + @@ -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> diff --git a/doc/install.sgml b/doc/install.sgml index a1c942f..c78d35f 100644 --- a/doc/install.sgml +++ b/doc/install.sgml @@ -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> diff --git a/doc/intro.sgml b/doc/intro.sgml index cd0fd29..14026d0 100644 --- a/doc/intro.sgml +++ b/doc/intro.sgml @@ -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> diff --git a/doc/reference.sgml b/doc/reference.sgml index 57f6315..fe3e825 100644 --- a/doc/reference.sgml +++ b/doc/reference.sgml @@ -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> diff --git a/doc/tutorial.sgml b/doc/tutorial.sgml index 8d3d2c2..9d37f28 100644 --- a/doc/tutorial.sgml +++ b/doc/tutorial.sgml @@ -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){