# HG changeset patch # User Florian Pose # Date 1225882548 0 # Node ID 0fd56b9fbd3802251031a25be43def96e36cd1cb # Parent d1adfbdfa2a2158193cac0305f2e482879b5dd43 merge -r1545:1547 trunk: Removed ldots; FIXME, TODO; typos. diff -r d1adfbdfa2a2 -r 0fd56b9fbd38 documentation/ethercat_doc.tex --- 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}`