
diff -r 8fe6cd43787a -r 7db3d4f573fa documentation/ethercat_doc.tex
--- a/documentation/ethercat_doc.tex	Tue Sep 26 16:34:24 2006 +0000
+++ b/documentation/ethercat_doc.tex	Wed Sep 27 15:19:22 2006 +0000
@@ -114,14 +114,14 @@
 If shell commands have to be entered, this is marked by a prompt:
 
 \begin{lstlisting}[gobble=2]
-  host>
+  `\$`
 \end{lstlisting}
 
 Further, if a shell command has to be entered as the superuser, the
 prompt ends with a mesh:
 
 \begin{lstlisting}[gobble=2]
-  host#
+  #
 \end{lstlisting}
 
 %------------------------------------------------------------------------------
@@ -734,7 +734,7 @@
 and connecting it to the first master:
 
 \begin{lstlisting}
-  host# `\textbf{modprobe ec\_8139too ec\_device\_index=1}`
+  # `\textbf{modprobe ec\_8139too ec\_device\_index=1}`
 \end{lstlisting}
 
 Usually, this command does not have to be entered manually, but is
@@ -1272,7 +1272,7 @@
 For example, if the master module has been loaded with the command
 
 \begin{lstlisting}
-  host# `\textbf{modprobe ec\_master ec\_master\_count=2}`
+  # `\textbf{modprobe ec\_master ec\_master\_count=2}`
 \end{lstlisting}
 
 the two masters can be addressed by their indices 0 and 1 respectively
@@ -2137,13 +2137,13 @@
 
 By calling the \textit{ecrt\_master\_activate()} method, all slaves
 are configured according to the prior method calls and are brought
-into \textit{OP} state. In this case, the method has a return value of
-0. Otherwise (wrong configuration or bus failure) the method returns
+into OP state. In this case, the method has a return value of 0.
+Otherwise (wrong configuration or bus failure) the method returns
 non-zero.
 
 The \textit{ecrt\_master\_deactivate()} method is the counterpart to
-the activate call: It brings all slaves back into \textit{INIT} state
-again. This method should be called prior to
+the activate call: It brings all slaves back into INIT state again.
+This method should be called prior to
 \textit{ecrt\_\-master\_\-release()}.
 
 \paragraph{Locking Callbacks}
@@ -2887,7 +2887,7 @@
   machine. There is a datagram issued, that queries the ``AL Control
   Response'' attribute \cite[section~5.3.2]{alspec} of all slaves via
   broadcast. In this way, all slave states and the number of slaves
-  responding can be determined.  $\rightarrow$~\textit{BROADCAST}
+  responding can be determined.  $\rightarrow$~BROADCAST
 
 \item[BROADCAST] The broadcast datagram is evaluated. A change in the
   number of responding slaves is treates as a topology change. If the
@@ -2899,64 +2899,63 @@
   normal state and it has to be checked, if all slaves are valid. Now,
   the state of every single slave has to be determined. For that, a
   (unicast) datagram is issued, that queries the first slave's ``AL
-  Control Response'' attribute. $\rightarrow$~\textit{READ STATES}
+  Control Response'' attribute. $\rightarrow$~READ STATES
 
 \item[READ STATES] If the current slave did not respond to its
   configured station address, it is marked as offline, and the next
-  slave is queried. $\rightarrow$~\textit{READ STATES}
+  slave is queried. $\rightarrow$~READ STATES
 
   If the slave responded, it is marked as online and its current state
-  is stored. The next slave is queried. $\rightarrow$~\textit{READ
-    STATES}
+  is stored. The next slave is queried. $\rightarrow$~READ STATES
 
   If all slaves have been queried, and the bus is marked for
   validation, the validation is started by checking the first slaves
-  vendor ID. $\rightarrow$~\textit{VALIDATE VENDOR}
+  vendor ID. $\rightarrow$~VALIDATE VENDOR
 
   If no validation has to be done, it is checked, if all slaves are in
   the state they are supposed to be. If not, the first of slave with
   the wrong state is reconfigured and brought in the required state.
-  $\rightarrow$~\textit{CONFIGURE SLAVES}
+  $\rightarrow$~CONFIGURE SLAVES
 
   If all slaves are in the correct state, the state machine is
-  restarted. $\rightarrow$~\textit{START}
+  restarted. $\rightarrow$~START
 
 \item[CONFIGURE SLAVES] The slave configuration state machine is
-  executed until termination. $\rightarrow$~\textit{CONFIGURE SLAVES}
+  executed until termination. $\rightarrow$~CONFIGURE SLAVES
 
   If there are still slaves in the wrong state after another check,
   the first of these slaves is configured and brought into the correct
-  state again. $\rightarrow$~\textit{CONFIGURE SLAVES}
+  state again. $\rightarrow$~CONFIGURE SLAVES
 
   If all slaves are in the correct state, the state machine is
-  restarted. $\rightarrow$~\textit{START}
+  restarted. $\rightarrow$~START
 
 \item[VALIDATE VENDOR] The SII state machine is executed until
   termination. If the slave has the wrong vendor ID, the state machine
-  is restarted. $\rightarrow$~\textit{START}
+  is restarted. $\rightarrow$~START
 
   If the slave has the correct vendor ID, its product ID is queried.
-  $\rightarrow$~\textit{VALIDATE PRODUCT}
+  $\rightarrow$~VALIDATE PRODUCT
 
 \item[VALIDATE PRODUCT] The SII state machine is executed until
   termination. If the slave has the wrong product ID, the state
-  machine is restarted. $\rightarrow$~\textit{START}
+  machine is restarted. $\rightarrow$~START
 
   If the slave has the correct product ID, the next slave's vendor ID
-  is queried. $\rightarrow$~\textit{VALIDATE VENDOR}
+  is queried. $\rightarrow$~VALIDATE VENDOR
 
   If all slaves have the correct vendor IDs and product codes, the
   configured station addresses can be safely rewritten. This is done
   for the first slave marked as offline.
-  $\rightarrow$~\textit{REWRITE ADDRESSES}
+  $\rightarrow$~REWRITE ADDRESSES
 
 \item[REWRITE ADDRESSES] If the station address was successfully
   written, it is sear\-ched for the next slave marked as offline. If
   there is one, its address is reconfigured, too.
-  $\rightarrow$~\textit{REWRITE ADDRESSES}
+  $\rightarrow$~REWRITE ADDRESSES
 
   If there are no more slaves marked as offline, the state machine is
-  restarted. $\rightarrow$~\textit{START}
+  restarted. $\rightarrow$~START
 \end{description}
 
 %------------------------------------------------------------------------------
@@ -2982,72 +2981,72 @@
 \item[START] The beginning state of the idle state machine. Similar to
   the operation state machine, a broadcast datagram is issued, to
   query all slave states and the number of slaves.
-  $\rightarrow$~\textit{BROADCAST}
+  $\rightarrow$~BROADCAST
 
 \item[BROADCAST] The number of responding slaves is evaluated. If it
   has changed since the last time, this is treated as a topology
   change and the internal list of slaves is cleared and rebuild
   completely. The slave scan state machine is started for the first
-  slave. $\rightarrow$~\textit{SCAN FOR SLAVES}
+  slave. $\rightarrow$~SCAN FOR SLAVES
 
   If no topology change happened, every single slave state is fetched.
-  $\rightarrow$~\textit{READ STATES}
+  $\rightarrow$~READ STATES
 
 \item[SCAN FOR SLAVES] The slave scan state machine is executed until
-  termination. $\rightarrow$~\textit{SCAN FOR SLAVES}
+  termination. $\rightarrow$~SCAN FOR SLAVES
 
   If there is another slave to scan, the slave scan state machine is
-  started again. $\rightarrow$~\textit{SCAN FOR SLAVES}
+  started again. $\rightarrow$~SCAN FOR SLAVES
 
   If all slave information has been fetched, slave addresses are
   calculated and EoE processing is started. Then, the state machine is
-  restarted. $\rightarrow$~\textit{START}
+  restarted. $\rightarrow$~START
 
 \item[READ STATES] If the slave did not respond to the query, it is
   marked as offline. The next slave is queried.
-  $\rightarrow$~\textit{READ STATES}
+  $\rightarrow$~READ STATES
 
   If the slave responded, it is marked as online. And the next slave
-  is queried. $\rightarrow$~\textit{READ STATES}
+  is queried. $\rightarrow$~READ STATES
 
   If all slave states have been determined, it is checked, if any
   slaves are not in the state they supposed to be. If this is true,
   the slave configuration state machine is started for the first of
-  them. $\rightarrow$~\textit{CONFIGURE SLAVES}
+  them. $\rightarrow$~CONFIGURE SLAVES
 
   If all slaves are in the correct state, it is checked, if any
   E$^2$PROM write operations are pending. If this is true, the first
   pending operation is executed by starting the SII state machine for
-  writing access. $\rightarrow$~\textit{WRITE EEPROM}
+  writing access. $\rightarrow$~WRITE EEPROM
 
   If all these conditions are false, there is nothing to do and the
-  state machine is restarted. $\rightarrow$~\textit{START}
+  state machine is restarted. $\rightarrow$~START
 
 \item[CONFIGURE SLAVES] The slave configuration state machine is
-  executed until termination. $\rightarrow$~\textit{CONFIGURE SLAVES}
+  executed until termination. $\rightarrow$~CONFIGURE SLAVES
 
   After this, it is checked, if another slave needs a state change. If
   this is true, the slave state change state machine is started for
-  this slave. $\rightarrow$~\textit{CONFIGURE SLAVES}
+  this slave. $\rightarrow$~CONFIGURE SLAVES
 
   If all slaves are in the correct state, it is determined, if any
   E$^2$PROM write operations are pending. If this is true, the first
   pending operation is executed by starting the SII state machine for
-  writing access. $\rightarrow$~\textit{WRITE EEPROM}
+  writing access. $\rightarrow$~WRITE EEPROM
 
   If all prior conditions are false, the state machine is restarted.
-  $\rightarrow$~\textit{START}
+  $\rightarrow$~START
 
 \item[WRITE EEPROM] The SII state machine is executed until
-  termination. $\rightarrow$~\textit{WRITE EEPROM}
+  termination. $\rightarrow$~WRITE EEPROM
 
   If the current word has been written successfully, and there are
   still word to write, the SII state machine is started for the next
-  word. $\rightarrow$~\textit{WRITE EEPROM}
+  word. $\rightarrow$~WRITE EEPROM
 
   If all words have been written successfully, the new E$^2$PROM
   contents are evaluated and the state machine is restarted.
-  $\rightarrow$~\textit{START}
+  $\rightarrow$~START
 
 \end{description}
 
@@ -3073,22 +3072,22 @@
   the station address is written to the slave, which is always the
   ring position~+~$1$. In this way, the address 0x0000 (default
   address) is not used, which makes it easy to detect unconfigured
-  slaves.  $\rightarrow$~\textit{ADDRESS}
+  slaves.  $\rightarrow$~ADDRESS
 
 \item[ADDRESS] The writing of the station address is verified. After
   that, the slave's ``AL Control Response'' attribute is queried.
-  $\rightarrow$~\textit{STATE}
+  $\rightarrow$~STATE
 
 \item[STATE] The AL state is evaluated. A warning is output, if the
   slave has still the \textit{Change} bit set. After that, the slave's
   ``DL Information'' attribute is queried.
-  $\rightarrow$~\textit{BASE}
+  $\rightarrow$~BASE
 
 \item[BASE] The queried base data are evaluated: Slave type, revision
   and build number, and even more important, the number of supported
   sync managers and FMMUs are stored. After that, the slave's data
   link layer information is read from the ``DL Status'' attribute at
-  address 0x0110. $\rightarrow$~\textit{DATALINK}
+  address 0x0110. $\rightarrow$~DATALINK
 
 \item[DATALINK] In this state, the DL information is evaluated: This
   information about the communication ports contains, if the link is
@@ -3100,33 +3099,33 @@
   category header, until the last category is reached (type 0xFFFF).
   This procedure is started by querying the first category header at
   word address 0x0040 via the SII state machine.
-  $\rightarrow$~\textit{EEPROM SIZE}
+  $\rightarrow$~EEPROM SIZE
 
 \item[EEPROM SIZE] The SII state machine is executed until
-  termination. $\rightarrow$~\textit{EEPROM SIZE}
+  termination. $\rightarrow$~EEPROM SIZE
 
   If the category type does not mark the end of the categories, the
   position of the next category header is determined via the length of
   the current category, and the SII state machine is started again.
-  $\rightarrow$~\textit{EEPROM SIZE}
+  $\rightarrow$~EEPROM SIZE
 
   If the size of the E$^2$PROM contents has been determined, memory is
   allocated, to read all the contents. The SII state machine is
-  started to read the first word. $\rightarrow$~\textit{EEPROM DATA}
+  started to read the first word. $\rightarrow$~EEPROM DATA
 
 \item[EEPROM DATA] The SII state machine is executed until
-  termination. $\rightarrow$~\textit{EEPROM DATA}
+  termination. $\rightarrow$~EEPROM DATA
 
   Two words have been read. If more than one word is needed, the two
   words are written in the allocated memory. Otherwise only one word
   (the last word) is copied. If more words are to read, the SII state
   machine is started again to read the next two words.
-  $\rightarrow$~\textit{EEPROM DATA}
+  $\rightarrow$~EEPROM DATA
 
   The complete E$^2$PROM contents have been read. The slave's identity
   object and mailbox information are evaluated. Moreover the category
   types STRINGS, GENERAL, SYNC and PDO are evaluated. The slave
-  scanning has been completed. $\rightarrow$~\textit{END}
+  scanning has been completed. $\rightarrow$~END
 
 \item[END] Slave scanning has been finished.
 
@@ -3152,89 +3151,88 @@
 
 \begin{description}
 \item[INIT] The state change state machine has been initialized to
-  bring the slave into the \textit{INIT} state. Now, the slave state
-  change state machine is executed until termination.
-  $\rightarrow$~\textit{INIT}
+  bring the slave into the INIT state. Now, the slave state change
+  state machine is executed until termination. $\rightarrow$~INIT
 
   If the slave state change failed, the configuration has to be
-  aborted. $\rightarrow$~\textit{END}
-
-  The slave state change succeeded and the slave is now in
-  \textit{INIT} state. If this is the target state, the configuration
-  is finished. $\rightarrow$~\textit{END}
+  aborted. $\rightarrow$~END
+
+  The slave state change succeeded and the slave is now in INIT state.
+  If this is the target state, the configuration is finished.
+  $\rightarrow$~END
 
   If the slave does not support any sync managers, the sync manager
   configuration can be skipped. The state change state machine is
-  started to bring the slave into \textit{PREOP} state.
-  $\rightarrow$~\textit{PREOP}
+  started to bring the slave into PREOP state.
+  $\rightarrow$~PREOP
 
   Sync managers are configured conforming to the sync manager category
   information provided in the slave's E$^2$PROM. The corresponding
-  datagram is issued. $\rightarrow$~\textit{SYNC}
+  datagram is issued. $\rightarrow$~SYNC
 
 \item[SYNC] If the sync manager configuration datagram is accepted,
   the sync manager configuration was successful. The slave may now
-  enter the \textit{PREOP} state, and the state change state machine
-  is started. $\rightarrow$~\textit{PREOP}
+  enter the PREOP state, and the state change state machine is
+  started. $\rightarrow$~PREOP
 
 \item[PREOP] The state change state machine is executed until
-  termination. $\rightarrow$~\textit{PREOP}
+  termination. $\rightarrow$~PREOP
 
   If the state change failed, the configuration has to be aborted.
-  $\rightarrow$~\textit{END}
-
-  If the \textit{PREOP} state was the target state, the configuration
-  is finished. $\rightarrow$~\textit{END}
+  $\rightarrow$~END
+
+  If the PREOP state was the target state, the configuration is
+  finished. $\rightarrow$~END
 
   If the slave supports no FMMUs, the FMMU configuration can be
   skipped. If the slave has SDOs to configure, it is begun with
-  sending the first SDO. $\rightarrow$~\textit{SDO\_CONF}
+  sending the first SDO. $\rightarrow$~SDO\_CONF
 
   If no SDO configurations are provided, the slave can now directly be
-  brought into the \textit{SAVEOP} state and the state change state
-  machine is started again. $\rightarrow$~\textit{SAVEOP}
+  brought into the SAVEOP state and the state change state machine is
+  started again. $\rightarrow$~SAVEOP
 
   Otherwise, all supported FMMUs are configured according to the PDOs
   requested via the master's realtime interface. The appropriate
-  datagram is issued. $\rightarrow$~\textit{FMMU}
+  datagram is issued. $\rightarrow$~FMMU
 
 \item[FMMU] The FMMU configuration datagram was accepted. If the slave
   has SDOs to configure, it is begun with sending the first SDO.
-  $\rightarrow$~\textit{SDO\_CONF}
-
-  Otherwise, the slave can now be brought into the \textit{SAVEOP}
-  state. The state change state machine is started.
-  $\rightarrow$~\textit{SAVEOP}
+  $\rightarrow$~SDO\_CONF
+
+  Otherwise, the slave can now be brought into the SAVEOP state. The
+  state change state machine is started.
+  $\rightarrow$~SAVEOP
 
 \item[SDO\_CONF] The CoE state machine is executed until termination.
-  $\rightarrow$~\textit{SDO\_CONF}
+  $\rightarrow$~SDO\_CONF
 
   If another SDO has to be configured, a new SDO download sequence is
-  begun. $\rightarrow$~\textit{SDO\_CONF}
-
-  Otherwise, the slave can now be brought into the \textit{SAVEOP}
-  state. The state change state machine is started.
-  $\rightarrow$~\textit{SAVEOP}
+  begun. $\rightarrow$~SDO\_CONF
+
+  Otherwise, the slave can now be brought into the SAVEOP state. The
+  state change state machine is started.
+  $\rightarrow$~SAVEOP
 
 \item[SAVEOP] The state change state machine is executed until
-  termination. $\rightarrow$~\textit{SAVEOP}
+  termination. $\rightarrow$~SAVEOP
 
   If the state change failed, the configuration has to be aborted.
-  $\rightarrow$~\textit{END}
-
-  If the \textit{SAVEOP} state was the target state, the configuration
-  is finished. $\rightarrow$~\textit{END}
-
-  The slave can now directly be brought into the \textit{OP} state and
-  the state change state machine is started a last time.
-  $\rightarrow$~\textit{OP}
+  $\rightarrow$~END
+
+  If the SAVEOP state was the target state, the configuration is
+  finished. $\rightarrow$~END
+
+  The slave can now directly be brought into the OP state and the
+  state change state machine is started a last time.
+  $\rightarrow$~OP
 
 \item[OP] The state change state machine is executed until
-  termination. $\rightarrow$~\textit{OP}
+  termination. $\rightarrow$~OP
 
   If the state change state machine terminates, the slave
   configuration is finished, regardless of its success.
-  $\rightarrow$~\textit{END}
+  $\rightarrow$~END
 
 \item[END] The termination state.
 
@@ -3261,26 +3259,26 @@
 \begin{description}
 \item[START] The beginning state, where a datagram with the state
   change command is written to the slave's ``AL Control Request''
-  attribute. Nothing can fail. $\rightarrow$~\textit{CHECK}
+  attribute. Nothing can fail. $\rightarrow$~CHECK
 
 \item[CHECK] After the state change datagram has been sent, the ``AL
   Control Response'' attribute is queried with a second datagram.
-  $\rightarrow$~\textit{STATUS}
+  $\rightarrow$~STATUS
 
 \item[STATUS] The read memory contents are evaluated: While the
   parameter \textit{State} still contains the old slave state, the
   slave is busy with reacting on the state change command. In this
   case, the attribute has to be queried again.
-  $\rightarrow$~\textit{STATUS}
+  $\rightarrow$~STATUS
 
   In case of success, the \textit{State} parameter contains the new
   state and the \textit{Change} bit is cleared. The slave is in the
-  requested state.  $\rightarrow$~\textit{END}
+  requested state.  $\rightarrow$~END
 
   If the slave can not process the state change, the \textit{Change}
   bit is set: Now the master tries to get the reason for this by
   querying the \textit{AL Status Code} parameter.
-  $\rightarrow$~\textit{CODE}
+  $\rightarrow$~CODE
 
 \item[END] If the state machine ends in this state, the slaves's state
   change has been successful.
@@ -3290,23 +3288,23 @@
   this parameter. Anyway, the master has to acknowledge the state
   change error by writing the current slave state to the ``AL Control
   Request'' attribute with the \textit{Acknowledge} bit set.
-  $\rightarrow$~\textit{ACK}
+  $\rightarrow$~ACK
 
 \item[ACK] After that, the ``AL Control Response'' attribute is
   queried for the state of the acknowledgement.
-  $\rightarrow$~\textit{CHECK ACK}
+  $\rightarrow$~CHECK ACK
 
 \item[CHECK ACK] If the acknowledgement has been accepted by the
   slave, the old state is kept. Still, the state change was
-  unsuccessful. $\rightarrow$~\textit{ERROR}
+  unsuccessful. $\rightarrow$~ERROR
 
   If the acknowledgement is ignored by the slave, a timeout happens.
   In any case, the overall state change was unsuccessful.
-  $\rightarrow$~\textit{ERROR}
+  $\rightarrow$~ERROR
 
   If there is still now response from the slave, but the timer did not
   run out yet, the slave's ``AL Control Response'' attribute is
-  queried again.  $\rightarrow$~\textit{CHECK ACK}
+  queried again.  $\rightarrow$~CHECK ACK
 
 \item[ERROR] If the state machine ends in this state, the slave's
   state change was unsuccessful.
@@ -3334,24 +3332,24 @@
 \item[READ\_START] The beginning state for reading access, where the
   read request and the requested address are written to the SII
   attribute. Nothing can fail up to now.
-  $\rightarrow$~\textit{READ\_CHECK}
+  $\rightarrow$~READ\_CHECK
 
 \item[READ\_CHECK] When the SII read request has been sent
   successfully, a timer is started. A check/fetch datagram is issued,
   that reads out the SII attribute for state and data.
-  $\rightarrow$~\textit{READ\_FETCH}
+  $\rightarrow$~READ\_FETCH
 
 \item[READ\_FETCH] Upon reception of the check/fetch datagram, the
   \textit{Read Operation} and \textit{Busy} parameters are checked:
   \begin{itemize}
   \item If the slave is still busy with fetching E$^2$PROM data into
     the interface, the timer is checked. If it timed out, the reading
-    is aborted ($\rightarrow$~\textit{ERROR}), if not, the check/fetch
-    datagram is issued again. $\rightarrow$~\textit{READ\_FETCH}
+    is aborted ($\rightarrow$~ERROR), if not, the check/fetch datagram
+    is issued again. $\rightarrow$~READ\_FETCH
 
   \item If the slave is ready with reading data, these are copied from
     the datagram and the read cycle is completed.
-    $\rightarrow$~\textit{END}
+    $\rightarrow$~END
   \end{itemize}
 \end{description}
 
@@ -3361,22 +3359,22 @@
 \item[WRITE\_START] The beginning state for writing access,
   respectively. A write request, the target address and the data word
   are written to the SII attribute. Nothing can fail.
-  $\rightarrow$~\textit{WRITE\_CHECK}
+  $\rightarrow$~WRITE\_CHECK
 
 \item[WRITE\_CHECK] When the SII write request has been sent
   successfully, the timer is started. A check datagram is issued, that
   reads out the SII attribute for the state of the write operation.
-  $\rightarrow$~\textit{WRITE\_CHECK2}
+  $\rightarrow$~WRITE\_CHECK2
 
 \item[WRITE\_CHECK2] Upon reception of the check datagram, the
   \textit{Write Operation} and \textit{Busy} parameters are checked:
   \begin{itemize}
   \item If the slave is still busy with writing E$^2$PROM data, the
     timer is checked. If it timed out, the operation is aborted
-    ($\rightarrow$~\textit{ERROR}), if not, the check datagram is
-    issued again. $\rightarrow$~\textit{WRITE\_CHECK2}
+    ($\rightarrow$~ERROR), if not, the check datagram is issued again.
+    $\rightarrow$~WRITE\_CHECK2
   \item If the slave is ready with writing data, the write cycle is
-    completed. $\rightarrow$~\textit{END}
+    completed. $\rightarrow$~END
   \end{itemize}
 \end{description}
 
@@ -3466,12 +3464,12 @@
 the number of EoE interfaces (and handlers) per master to create. This
 parameter can either be specified when manually loading the master
 module, or (when using the init script) by setting the
-\textit{EOE\_INTERFACES} variable in the sysconfig file (see
+\$EOE\_INTERFACES variable in the sysconfig file (see
 section~\ref{sec:sysconfig}). Upon loading of the master module, the
 virtual interfaces become available:
 
 \begin{lstlisting}
-  host# `\textbf{ifconfig -a}`
+  # `\textbf{ifconfig -a}`
   eoe0      Link encap:Ethernet  HWaddr 00:11:22:33:44:06
             BROADCAST MULTICAST  MTU:1500  Metric:1
             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
@@ -3518,19 +3516,19 @@
 \begin{description}
 \item[RX\_START] The beginning state of the EoE state machine. A
   mailbox check datagram is sent, to query the slave's mailbox for new
-  frames. $\rightarrow$~\textit{RX\_CHECK}
+  frames. $\rightarrow$~RX\_CHECK
 
 \item[RX\_CHECK] The mailbox check datagram is received. If the
   slave's mailbox did not contain data, a transmit cycle is started.
-  $\rightarrow$~\textit{TX\_START}
+  $\rightarrow$~TX\_START
 
   If there are new data in the mailbox, a datagram is sent to fetch
-  the new data. $\rightarrow$~\textit{RX\_FETCH}
+  the new data. $\rightarrow$~RX\_FETCH
 
 \item[RX\_FETCH] The fetch datagram is received. If the mailbox data
   do not contain a ``EoE Fragment request'' command, the data are
   dropped and a transmit sequence is started.
-  $\rightarrow$~\textit{TX\_START}
+  $\rightarrow$~TX\_START
 
   If the received Ethernet frame fragment is the first fragment, a new
   socket buffer is allocated. In either case, the data are copied into
@@ -3538,26 +3536,26 @@
 
   If the fragment is the last fragment, the socket buffer is forwarded
   to the network stack and a transmit sequence is started.
-  $\rightarrow$~\textit{TX\_START}
+  $\rightarrow$~TX\_START
 
   Otherwise, a new receive sequence is started to fetch the next
-  fragment. $\rightarrow$~\textit{RX\_\-START}
+  fragment. $\rightarrow$~RX\_\-START
 
 \item[TX\_START] The beginning state of a transmit sequence. It is
   checked, if the transmittion queue contains a frame to send. If not,
-  a receive sequence is started. $\rightarrow$~\textit{RX\_START}
+  a receive sequence is started. $\rightarrow$~RX\_START
 
   If there is a frame to send, it is dequeued. If the queue was
   inactive before (because it was full), the queue is woken up with a
   call to \textit{netif\_wake\_queue()}. The first fragment of the
-  frame is sent. $\rightarrow$~\textit{TX\_SENT}
+  frame is sent. $\rightarrow$~TX\_SENT
 
 \item[TX\_SENT] It is checked, if the first fragment was sent
   successfully. If the current frame consists of further fragments,
-  the next one is sent. $\rightarrow$~\textit{TX\_SENT}
+  the next one is sent. $\rightarrow$~TX\_SENT
 
   If the last fragment was sent, a new receive sequence is started.
-  $\rightarrow$~\textit{RX\_START}
+  $\rightarrow$~RX\_START
 \end{description}
 
 \paragraph{EoE Processing}
@@ -3602,12 +3600,11 @@
 
 \paragraph{Automatic Configuration}
 
-By default, slaves are left in \textit{INIT} state during idle mode.
-If an EoE interface is set to running state (i.~e. with the
-\textit{ifconfig up} command), the requested slave state of the
-related slave is automatically set to \textit{OP}, whereupon the idle
-state machine will attempt to configure the slave and put it into
-operation.
+By default, slaves are left in INIT state during idle mode. If an EoE
+interface is set to running state (i.~e. with the \textit{ifconfig up}
+command), the requested slave state of the related slave is
+automatically set to OP, whereupon the idle state machine will attempt
+to configure the slave and put it into operation.
 
 %------------------------------------------------------------------------------
 
@@ -3629,15 +3626,15 @@
 
 \paragraph{SDO Download State Machine}
 
-The best time to apply SDO configurations is during the slave's
-\textit{PREOP} state, because mailbox communication is already
-possible and slave's application will start with updating input data
-in the succeeding \textit{SAVEOP} state. Therefore the SDO
-configuration has to be part of the slave configuration state machine
-(see section~\ref{sec:fsm-conf}): It is implemented via an SDO
-download state machine, that is executed just before entering the
-slave's \textit{SAVEOP} state. In this way, it is guaranteed that the
-SDO configurations are applied each time, the slave is reconfigured.
+The best time to apply SDO configurations is during the slave's PREOP
+state, because mailbox communication is already possible and slave's
+application will start with updating input data in the succeeding
+SAVEOP state. Therefore the SDO configuration has to be part of the
+slave configuration state machine (see section~\ref{sec:fsm-conf}): It
+is implemented via an SDO download state machine, that is executed
+just before entering the slave's SAVEOP state. In this way, it is
+guaranteed that the SDO configurations are applied each time, the
+slave is reconfigured.
 
 The transition diagram of the SDO Download state machine can be seen
 in figure~\ref{fig:fsm-coedown}.
@@ -3652,30 +3649,30 @@
 \begin{description}
 \item[START] The beginning state of the CoE download state
   machine. The ``SDO Download Normal Request'' mailbox command is
-  sent. $\rightarrow$~\textit{REQUEST}
+  sent. $\rightarrow$~REQUEST
 
 \item[REQUEST] It is checked, if the CoE download request has been
   received by the slave. After that, a mailbox check command is issued
-  and a timer is started. $\rightarrow$~\textit{CHECK}
+  and a timer is started. $\rightarrow$~CHECK
 
 \item[CHECK] If no mailbox data is available, the timer is checked.
   \begin{itemize}
   \item If it timed out, the SDO download is aborted.
-    $\rightarrow$~\textit{ERROR}
+    $\rightarrow$~ERROR
   \item Otherwise, the mailbox is queried again.
-    $\rightarrow$~\textit{CHECK}
+    $\rightarrow$~CHECK
   \end{itemize}
 
   If the mailbox contains new data, the response is fetched.
-  $\rightarrow$~\textit{RESPONSE}
+  $\rightarrow$~RESPONSE
 
 \item[RESPONSE] If the mailbox response could not be fetched, the data
   is invalid, the wrong protocol was received, or a ``Abort SDO
   Transfer Request'' was received, the SDO download is aborted.
-  $\rightarrow$~\textit{ERROR}
+  $\rightarrow$~ERROR
 
   If a ``SDO Download Normal Response'' acknowledgement was received,
-  the SDO download was successful. $\rightarrow$~\textit{END}
+  the SDO download was successful. $\rightarrow$~END
 
 \item[END] The SDO download was successful.
 
@@ -3757,7 +3754,7 @@
 file system representation of the master's kobject):
 
 \begin{lstlisting}
-  host> `\textbf{ls /sys/ethercat0}`
+  `\$` `\textbf{ls /sys/ethercat0}`
   debug_level          slave000  slave003  slave006
   eeprom_write_enable  slave001  slave004  slave007
   info                 slave002  slave005  slave008
@@ -3773,7 +3770,7 @@
   defined. Writing is done with command like
 
   \begin{lstlisting}[gobble=4]
-    host# `\textbf{echo 1 > /sys/ethercat0/debug\_level}`
+    # `\textbf{echo 1 > /sys/ethercat0/debug\_level}`
   \end{lstlisting}
 
   and is receipted with a syslog message by the master:
@@ -3789,7 +3786,7 @@
   master. Example contents are below:
 
   \begin{lstlisting}[gobble=4]
-    host> `\textbf{cat /sys/ethercat0/info}`
+    `\$` `\textbf{cat /sys/ethercat0/info}`
 
     Mode: IDLE
     Slaves: 9
@@ -3815,7 +3812,7 @@
 the domain directory contents:
 
 \begin{lstlisting}
-  host> `\textbf{ls /sys/ethercat0/domain0}`
+  `\$` `\textbf{ls /sys/ethercat0/domain0}`
   image_size
 \end{lstlisting}
 
@@ -3831,7 +3828,7 @@
 the EtherCAT bus. Below is a listing of a slave directory:
 
 \begin{lstlisting}
-  host> `\textbf{ls /sys/ethercat0/slave003}`
+  `\$` `\textbf{ls /sys/ethercat0/slave003}`
   eeprom  info  state
 \end{lstlisting}
 
@@ -3843,7 +3840,7 @@
   about the slave. Below is an example output:
 
   \begin{lstlisting}[gobble=4]
-    host> `\textbf{cat /sys/ethercat0/slave003/info}`
+    `\$` `\textbf{cat /sys/ethercat0/slave003/info}`
 
     Name: EL4132 2K. Ana. Ausgang +/-10V
     Vendor ID: 0x00000002
@@ -3889,9 +3886,9 @@
   It can be read or written:
 
   \begin{lstlisting}[gobble=4]
-    host# `\textbf{cat /sys/ethercat0/slave003/state}`
+    # `\textbf{cat /sys/ethercat0/slave003/state}`
     OP
-    host# `\textbf{echo SAVEOP > /sys/ethercat0/slave003/state}`
+    # `\textbf{echo SAVEOP > /sys/ethercat0/slave003/state}`
   \end{lstlisting}
 
   This command should also be receipted with a syslog message:
@@ -3934,7 +3931,7 @@
 easier with a tool like \textit{hexdump}:
 
 \begin{lstlisting}
-  host> `\textbf{cat /sys/ethercat0/slave003/eeprom | hexdump}`
+  `\$` `\textbf{cat /sys/ethercat0/slave003/eeprom | hexdump}`
   0000000 0103 0000 0000 0000 0000 0000 0000 008c
   0000010 0002 0000 3052 07f0 0000 0000 0000 0000
   0000020 0000 0000 0000 0000 0000 0000 0000 0000
@@ -3944,7 +3941,7 @@
 Backing up E$^2$PROM contents gets as easy as copying a file:
 
 \begin{lstlisting}
-  host> `\textbf{cp /sys/ethercat0/slave003/eeprom slave003.eep}`
+  `\$` `\textbf{cp /sys/ethercat0/slave003/eeprom slave003.eep}`
 \end{lstlisting}
 
 Writing access is only possible as \textit{root}. Moreover writing has
@@ -3956,7 +3953,7 @@
 E$^2$PROM writing is enabled with the command below:
 
 \begin{lstlisting}
-  host# `\textbf{echo 1 > /sys/ethercat0/eeprom\_write\_enable}`
+  # `\textbf{echo 1 > /sys/ethercat0/eeprom\_write\_enable}`
 \end{lstlisting}
 
 The success can be seen in the syslog messages again:
@@ -3971,7 +3968,7 @@
 This validation checks the complete size and the category headers.
 
 \begin{lstlisting}
-  host# `\textbf{cat slave003.eep > /sys/ethercat0/slave003/eeprom}`
+  # `\textbf{cat slave003.eep > /sys/ethercat0/slave003/eeprom}`
 \end{lstlisting}
 
 The write operation can take a few seconds.
@@ -3992,7 +3989,7 @@
 in an output like this:
 
 \begin{lstlisting}
-  host> `\textbf{lsec}`
+  `\$` `\textbf{lsec}`
   EtherCAT bus listing for master 0:
      0  1:0  OP      EK1100 Ethernet Kopplerklemme (2A E-Bus)
      1  1:1  INIT    EL4132 2K. Ana. Ausgang +/-10V
@@ -4017,7 +4014,7 @@
 default, but the master index can be specified via command line:
 
 \begin{lstlisting}
-  host> `\textbf{lsec -h}`
+  `\$` `\textbf{lsec -h}`
   Usage: ec_list [OPTIONS]
           -m <IDX>    Query master <IDX>.
           -h          Show this help.
@@ -4074,10 +4071,10 @@
 
 The init script can also be used for manually starting and stopping
 the EtherCAT master. It has to be executed with one of the parameters
-\textit{start}, \textit{stop}, \textit{restart} or \textit{status}.
+\texttt{start}, \texttt{stop}, \texttt{restart} or \texttt{status}.
 
 \begin{lstlisting}
-  host# `\textbf{/etc/init.d/ethercat restart}`
+  # `\textbf{/etc/init.d/ethercat restart}`
   Shutting down EtherCAT master                done
   Starting EtherCAT master                     done
 \end{lstlisting}
@@ -4102,23 +4099,23 @@
   added to a network bridge according to IEEE 802.1D after master
   startup. The variable must contain the name of the bridge. To use
   this functionality, the kernel must be configured with the
-  \textit{CONFIG\_BRIDGE} option and the \textit{bridge-utils} package
-  must be installed (i.~e. the \textit{brctl} command is needed).
+  CONFIG\_BRIDGE option and the \textit{bridge-utils} package must be
+  installed (i.~e. the \textit{brctl} command is needed).
 \item[EOE\_IP\_ADDRESS] The IP address of the EoE bridge. Setting this
-  together with \textit{EOE\_IP\_NETMASK} will let the local host
-  communicate with devices on the EoE bridge.
+  together with \$EOE\_IP\_NETMASK will let the local host communicate
+  with devices on the EoE bridge.
 \item[EOE\_IP\_NETMASK] IP netmask of the EoE bridge.
 \item[EOE\_EXTRA\_INTERFACES] The list of extra interfaces to include
   in the EoE brid\-ge. Set this to interconnect the EoE bridge with
-  other local interfaces. If \textit{EOE\_\-BRIDGE} is empty or
-  undefined, setting this variable has no effect. Important: The IP
-  address of the listed interfaces will be cleared. Setting
-  \textit{EOE\_\-IP\_\-ADDRESS} and \textit{EOE\_IP\_NETMASK} will
-  re-enable them for IP traffic.
+  other local interfaces. If \$EOE\_\-BRIDGE is empty or undefined,
+  setting this variable has no effect. Important: The IP address of
+  the listed interfaces will be cleared. Setting
+  \$EOE\_\-IP\_\-ADDRESS and \$EOE\_IP\_NETMASK will re-enable them
+  for IP traffic.
 \item[EOE\_GATEWAY] The IP address of the default gateway. If this
   variable is set, the gateway will be renewed after bridge
   installation. This is necessary, if the default gateway's interface
-  is one of the \textit{EOE\_EXTRA\_INTERFACES}.
+  is one of the \$EOE\_EXTRA\_INTERFACES.
 \end{description}
 
 %------------------------------------------------------------------------------
@@ -4306,16 +4303,16 @@
 (or similar):
 
 \begin{lstlisting}
-  host> `\textbf{tar xjf ethercat-1.1-rXXX.tar.bz2}`
-  host> `\textbf{cd ethercat-1.1-rXXX/}`
+  `\$` `\textbf{tar xjf ethercat-1.1-rXXX.tar.bz2}`
+  `\$` `\textbf{cd ethercat-1.1-rXXX/}`
 \end{lstlisting}
 
 The tarball was created with GNU Autotools, so the build process
 follows the usual commands:
 
 \begin{lstlisting}
-  host> `\textbf{./configure}`
-  host> `\textbf{make}`
+  `\$` `\textbf{./configure}`
+  `\$` `\textbf{make}`
 \end{lstlisting}
 
 The default installation prefix is \textit{/opt/etherlab}. It can be
@@ -4329,8 +4326,8 @@
 argument. Example:
 
 \begin{lstlisting}
-  host> `\textbf{./configure --with-linux="2.6.17-ipipe"}`
-  host> `\textbf{make}`
+  `\$` `\textbf{./configure --with-linux="2.6.17-ipipe"}`
+  `\$` `\textbf{make}`
 \end{lstlisting}
 
 The following commands have to be entered as \textit{root}: To install
@@ -4338,7 +4335,7 @@
 the user space tools, the below command has to be executed:
 
 \begin{lstlisting}
-  host# `\textbf{make install}`
+  # `\textbf{make install}`
 \end{lstlisting}
 
 If the EtherCAT master shall be run as a service
@@ -4349,21 +4346,21 @@
 suitable for SUSE Linux.  It may vary for other distributions.
 
 \begin{lstlisting}
-  host# `\textbf{cd /opt/etherlab}`
-  host# `\textbf{cp etc/sysconfig/ethercat /etc/sysconfig/}`
-  host# `\textbf{cp etc/init.d/ethercat /etc/init.d/}`
-  host# `\textbf{insserv ethercat}`
+  # `\textbf{cd /opt/etherlab}`
+  # `\textbf{cp etc/sysconfig/ethercat /etc/sysconfig/}`
+  # `\textbf{cp etc/init.d/ethercat /etc/init.d/}`
+  # `\textbf{insserv ethercat}`
 \end{lstlisting}
 
 Now the sysconfig file \texttt{/etc/sysconfig/ethercat} (see
 section~\ref{sec:sysconfig}) has to be customized: This is mainly done
-by uncommenting and adjusting the \textit{DEVICE\_INDEX} variable. It
-has to be set to the index of the compatible network device to use
-with EtherCAT, where the order of devices is dependent on their
-position in the PCI bus:
+by uncommenting and adjusting the \$DEVICE\_INDEX variable. It has to
+be set to the index of the compatible network device to use with
+EtherCAT, where the order of devices is dependent on their position in
+the PCI bus:
 
 \begin{lstlisting}[numbers=left,basicstyle=\ttfamily\scriptsize]
-  host# `\textbf{lspci}`
+  # `\textbf{lspci}`
   00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
   00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
   00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
@@ -4380,14 +4377,14 @@
 
 In the above output of the \textit{lspci} command, two compatible
 network devices can be found in lines~\textcircled{\tiny 9} and
-\textcircled{\tiny 11}. The \textit{DEVICE\_INDEX} variable should be
-set to $0$ or $1$, respectively.
+\textcircled{\tiny 11}. The \$DEVICE\_INDEX variable should be set to
+$0$ or $1$, respectively.
 
 After the basic configuration is done, the master can be started with
 the below command:
 
 \begin{lstlisting}
-  host# `\textbf{/etc/init.d/ethercat start}`
+  # `\textbf{/etc/init.d/ethercat start}`
 \end{lstlisting}
 
 The operation of the master can be observed by looking at the
@@ -4550,7 +4547,7 @@
 \item[\normalfont\textcircled{\tiny 16}] After the configuration of
   process data mapping, the master can be activated for cyclic
   operation. This will configure all slaves and bring them into
-  \textit{OP} state.
+  OP state.
 \item[\normalfont\textcircled{\tiny 20}] This call is needed to avoid
   a case differentiation in cyclic operation: The first operation in
   cyclic mode is a receive call. Due to the fact, that there is
@@ -4585,8 +4582,8 @@
   object. It is assured, that no cyclic work will be done after this
   call returns.
 \item[\normalfont\textcircled{\tiny 4}] This call deactivates the
-  master, which results in all slaves being brought to their
-  \textit{INIT} state again.
+  master, which results in all slaves being brought to their INIT
+  state again.
 \item[\normalfont\textcircled{\tiny 5}] This call releases the master,
   removes any existing configuration and silently starts the idle
   mode. The value of the master pointer is invalid after this call and




