# HG changeset patch # User Florian Pose # Date 1224675149 0 # Node ID 129a7224e01012dfb8944a9879cb9fce36c8f031 # Parent 69582b88e8fd785b5f10ede897563033a74978a0 FIXME, TODO; typos. diff -r 69582b88e8fd -r 129a7224e010 documentation/ethercat_doc.tex --- 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}`