etherlabmaster: comparison documentation/ethercat

equal deleted inserted replaced

-:6b835fae2cab
+:7853befa1a83
 \item It runs well even without realtime extensions.
 \end{itemize}
 \item Common ``Application Interface'' for applications, that want to use
-EtherCAT functionality (see section~\ref{sec:ecrt}).
+EtherCAT functionality (see chap.~\ref{sec:ecrt}).
 \item \textit{Domains} are introduced, to allow grouping of process
 data transfers with different slave groups and task periods.
 \begin{itemize}
 \index{Master module}
 Kernel module containing one or more EtherCAT master instances (see
 section~\ref{sec:mastermod}), the ``Device Interface'' (see
 section~\ref{sec:ecdev}) and the ``Application Interface'' (see
-section~\ref{sec:ecrt}).
+chap.~\ref{sec:ecrt}).
 \paragraph{Device Modules}
 \index{Device modules}
 EtherCAT-capable Ethernet device driver modules\index{Device modules}, that
 Kernel modules, that use the EtherCAT master (usually for cyclic exchange of
 process data with EtherCAT slaves). These modules are not part of the EtherCAT
 master code\footnote{Although there are some examples provided in the
 \textit{examples/} directory.}, but have to be generated or written by the
 user. An application module can ``request'' a master through the application
-interface (see section~\ref{sec:ecrt}). If this succeeds, the module has the
+interface (see chap.~\ref{sec:ecrt}). If this succeeds, the module has the
 control over the master: It can provide a bus configuration and exchange
 process data.
 %------------------------------------------------------------------------------
 \end{lstlisting}
 The two masters can be addressed by their indices 0 and 1 respectively (see
 figure~\ref{fig:masters}). The master index is needed for the
 \lstinline+ecrt_master_request()+ function of the application interface (see
-section~\ref{sec:ecrt}) and the \lstinline+--master+ option of the
+chap.~\ref{sec:ecrt}) and the \lstinline+--master+ option of the
 \textit{ethercat} command-line tool (see section~\ref{sec:ethercat}), which
 defaults to $0$.
 \begin{figure}[htbp]
 \centering
 \index{Concurrency}
 In some cases, one master is used by several instances, for example when an
 application does cyclic process data exchange, and there are EoE-capable slaves
 that require to exchange Ethernet data with the kernel (see
-section~\ref{sec:eoeimp}). For this reason, the master is a shared resource,
+section~\ref{sec:eoe}). For this reason, the master is a shared resource,
 and access to it has to be sequentialized. This is usually done by locking with
 semaphores, or other methods to protect critical sections.
 The master itself can not provide locking mechanisms, because it has no chance
 to know the appropriate kind of lock. For example if the application uses RTAI
 Figure~\ref{fig:locks} exemplary shows, how two processes share one master:
 The application's cyclic task uses the master for process data exchange, while
 the master-internal EoE process uses it to communicate with EoE-capable
 slaves.  Both have to acquire the master lock before access: The application
 task can access the lock natively, while the EoE process has to use the
-callbacks.  See the application interface documentation
+callbacks.  See the application interface documentation (chap.~\ref{sec:ecrt}
-(section~\ref{sec:ecrt} of how to use the locking callbacks.
+of how to use the locking callbacks.
 %------------------------------------------------------------------------------
 \chapter{Ethernet Devices}
 \label{sec:devices}
 lines of code. The disadvantage is, that the master is blocked for the
 time it waits for datagram reception. There is no difficulty when only
 one instance is using the master, but if more instances want to
 (synchronously\footnote{At this time, synchronous master access will
 be adequate to show the advantages of an FSM. The asynchronous
-approach will be discussed in section~\ref{sec:eoeimp}}) use the
+approach will be discussed in section~\ref{sec:eoe}}) use the
 master, it is inevitable to think about an alternative to the
 sequential model.
 Master access has to be sequentialized for more than one instance
 wanting to send and receive datagrams synchronously. With the present
 The Pdo state machines are a set of state machines that read or write the Pdo
 assignment and the Pdo mapping via the ``CoE Communication Area'' described in
 \cite[section 5.6.7.4]{alspec}. For the object access, the
 CANopen-over-EtherCAT access primitives are used (see
-section~\ref{sec:coeimp}), so the slave must support the CoE mailbox protocol.
+section~\ref{sec:coe}), so the slave must support the CoE mailbox protocol.
 \paragraph{Pdo Reading FSM} This state machine (fig.~\ref{fig:fsm-pdo-read})
 has the purpose to read the complete Pdo configuration of a slave. It reads
 the Pdo assignment for each Sync Manager and uses the Pdo Entry Reading FSM
 (fig.~\ref{fig:fsm-pdo-entry-read}) to read the mapping for each assigned Pdo.
 protocols. See the below section for details.
 %------------------------------------------------------------------------------
 \section{Ethernet-over-EtherCAT (EoE)}
-\label{sec:eoeimp}
+\label{sec:eoe}
 \index{EoE}
 The EtherCAT master implements the Ethernet-over-EtherCAT mailbox protocol to
 enable the tunneling of Ethernet frames to special slaves, that can either
 have physical Ethernet ports to forward the frames to, or have an own IP stack
 application-layer state is automatically set to OP.
 %------------------------------------------------------------------------------
 \section{CANopen-over-EtherCAT (CoE)}
-\label{sec:coeimp}
+\label{sec:coe}
 \index{CoE}
 The CANopen-over-EtherCAT protocol \cite[section~5.6]{alspec} is used to
 configure slaves and exchange data objects on application level.

branch	stable-1.4
changeset 1655	7853befa1a83
parent 1654	6b835fae2cab
child 1656	7d3996955804