--- a/documentation/ethercat_doc.tex Wed Oct 22 10:35:41 2008 +0000
+++ b/documentation/ethercat_doc.tex Wed Oct 22 11:32:29 2008 +0000
@@ -398,12 +398,12 @@
%------------------------------------------------------------------------------
-\section{General Behavior} % FIXME
+\section{General Behavior}
\index{Master behavior}
\ldots
-% Behavior (Scanning) TODO
+% TODO Behavior (Scanning)
%------------------------------------------------------------------------------
@@ -561,15 +561,17 @@
\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
-% VoE handlers
+% TODO
+%
+% Interface version
+% Master Requesting and Releasing
+% Master Locking
+% Configuring Pdo assignment and mapping
+% Domains (memory)
+% Pdo entry registration
+% Sdo configuration
+% Sdo access
+% VoE handlers
The application interface provides functions and data structures for
applications to access an EtherCAT master. The complete documentation of the
@@ -701,8 +703,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
%------------------------------------------------------------------------------
@@ -828,8 +832,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
@@ -1884,7 +1888,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
@@ -2015,7 +2019,7 @@
\section{Command-line Tool}
\label{sec:tool}
-% --master
+% TODO --master
\subsection{Character Devices}
\label{sec:cdev}
@@ -2499,22 +2503,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
@@ -2523,24 +2529,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.
%------------------------------------------------------------------------------
@@ -2685,8 +2691,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}`