--- a/documentation/ethercat_doc.tex Wed Nov 05 10:52:38 2008 +0000
+++ b/documentation/ethercat_doc.tex Wed Nov 05 10:55:48 2008 +0000
@@ -390,12 +390,12 @@
%------------------------------------------------------------------------------
-\section{General Behavior} % FIXME
+\section{General Behavior}
\index{Master behavior}
\ldots
-% Behavior (Scanning) TODO
+% TODO Behavior (Scanning)
%------------------------------------------------------------------------------
@@ -553,14 +553,16 @@
\label{chap:api}
\index{Application interface}
-% Interface version
-% Master Requesting and Releasing
-% Master Locking
-% Configuring Pdo assignment and mapping
-% Domains (memory)
-% Pdo entry registration
-% Sdo configuration
-% Sdo access
+% TODO
+%
+% Interface version
+% Master Requesting and Releasing
+% Master Locking
+% Configuring Pdo assignment and mapping
+% Domains (memory)
+% Pdo entry registration
+% Sdo configuration
+% Sdo access
The application interface provides functions and data structures for
applications to access an EtherCAT master. The complete documentation of the
@@ -692,8 +694,10 @@
time. After activation, the application is in charge to send and receive
frames.
-% TODO PDOS endianess
-% TODO Datagram injection
+% TODO
+%
+% PDO endianess
+% Datagram injection
%------------------------------------------------------------------------------
@@ -818,8 +822,8 @@
to be started, for example after a command \lstinline+ip link set ethX up+
from userspace. Frame reception has to be enabled by the driver.
-\item[\usebox\boxstop] The purpose of this callback is to ``close'' the device,
-i.~e. make the hardware stop receiving frames.
+\item[\usebox\boxstop] The purpose of this callback is to ``close'' the
+device, i.~e. make the hardware stop receiving frames.
\item[\usebox\boxxmit] This function is called for each frame that has to be
transmitted. The network stack passes the frame as a pointer to an
@@ -1001,7 +1005,7 @@
in the appropriate module of the interface documentation (see
sec.~\ref{sec:gendoc} for generation instructions).
-\ldots % FIXME general description of the device interface
+% TODO general description of the device interface
%------------------------------------------------------------------------------
@@ -1874,7 +1878,7 @@
The CANopen-over-EtherCAT protocol \cite[sec.~5.6]{alspec} is used to
configure slaves and exchange data objects on application level.
-% FIXME
+% TODO
%
% Download / Upload
% Expedited / Normal
@@ -1975,7 +1979,7 @@
\section{Command-line Tool}
\label{sec:tool}
-% --master
+% TODO --master
\subsection{Character Devices}
\label{sec:cdev}
@@ -2317,22 +2321,24 @@
\label{sec:timing-bus}
\index{Bus cycle}
-For measuring the time, a frame is ``on the wire'', two timestamps
-must be be taken:
+For measuring the time, a frame is ``on the wire'', two timestamps must be
+taken:
\begin{enumerate}
-\item The time, the Ethernet hardware begins with physically sending
- the frame.
-\item The time, the frame is completely received by the Ethernet
- hardware.
+
+\item The time, the Ethernet hardware begins with physically sending the
+frame.
+
+\item The time, the frame is completely received by the Ethernet hardware.
+
\end{enumerate}
Both times are difficult to determine. The first reason is, that the
-interrupts are disabled and the master is not notified, when a frame
-is sent or received (polling would distort the results). The second
-reason is, that even with interrupts enabled, the time from the event
-to the notification is unknown. Therefore the only way to confidently
-determine the bus cycle time is an electrical measuring.
+interrupts are disabled and the master is not notified, when a frame is sent
+or received (polling would distort the results). The second reason is, that
+even with interrupts enabled, the time from the event to the notification is
+unknown. Therefore the only way to confidently determine the bus cycle time is
+an electrical measuring.
Anyway, the bus cycle time is an important factor when designing realtime
code, because it limits the maximum frequency for the cyclic task of the
@@ -2341,24 +2347,24 @@
limits of the system.
The central question is: What happens, if the cycle frequency is too high? The
-answer is, that the EtherCAT frames that have been sent at the end of the cycle
-are not yet received, when the next cycle starts. First this is noticed by
-\textit{ecrt\_domain\_process()}, because the working counter of the process
-data datagrams were not increased. The function will notify the user via
-Syslog\footnote{To limit Syslog output, a mechanism has been implemented, that
-outputs a summarized notification at maximum once a second.}. In this case, the
-process data keeps being the same as in the last cycle, because it is not
-erased by the domain. When the domain datagrams are queued again, the master
-notices, that they are already queued (and marked as sent). The master will
-mark them as unsent again and output a warning, that datagrams were
+answer is, that the EtherCAT frames that have been sent at the end of the
+cycle are not yet received, when the next cycle starts. First this is noticed
+by \textit{ecrt\_domain\_process()}, because the working counter of the
+process data datagrams were not increased. The function will notify the user
+via Syslog\footnote{To limit Syslog output, a mechanism has been implemented,
+that outputs a summarized notification at maximum once a second.}. In this
+case, the process data keeps being the same as in the last cycle, because it
+is not erased by the domain. When the domain datagrams are queued again, the
+master notices, that they are already queued (and marked as sent). The master
+will mark them as unsent again and output a warning, that datagrams were
``skipped''.
On the mentioned \unit{2.0}{\giga\hertz} system, the possible cycle frequency
can be up to \unit{25}{\kilo\hertz} without skipped frames. This value can
-surely be increased by choosing faster hardware. Especially the RealTek network
-hardware could be replaced by a faster one. Besides, implementing a dedicated
-ISR for EtherCAT devices would also contribute to increasing the latency. These
-are two points on the author's to-do list.
+surely be increased by choosing faster hardware. Especially the RealTek
+network hardware could be replaced by a faster one. Besides, implementing a
+dedicated ISR for EtherCAT devices would also contribute to increasing the
+latency. These are two points on the author's to-do list.
%------------------------------------------------------------------------------
@@ -2499,8 +2505,8 @@
device offered) and selecting the driver(s) to load via the
\lstinline+DEVICE_MODULES+ variable.
-After the basic configuration is done, the master can be started with
-the below command:
+After the basic configuration is done, the master can be started with the
+below command:
\begin{lstlisting}
# `\textbf{/etc/init.d/ethercat start}`