etherlabmaster: comparison documentation/ethercat

equal deleted inserted replaced

-:5212bb4a73e5
+:f04865a2454f
 Figure~\ref{fig:arch} gives a general overview of the master architecture.
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.9\textwidth]{images/architecture}
-\caption{Master architecture}
+\caption{Master Architecture}
 \label{fig:arch}
 \end{figure}
-\paragraph{Master Module}
+The components of the master environment are described below:
-\index{Master module}
+\begin{description}
-Kernel module containing one or more EtherCAT master instances (see
-sec.~\ref{sec:mastermod}), the ``Device Interface'' (see sec.~\ref{sec:ecdev})
+\item[Master Module]\index{Master Module} Kernel module containing one or more
-and the ``Application Interface'' (see chap.~\ref{chap:api}).
+EtherCAT master instances (see sec.~\ref{sec:mastermod}), the ``Device
+Interface'' (see sec.~\ref{sec:ecdev}) and the ``Application Interface'' (see
-\paragraph{Device Modules}
+chap.~\ref{chap:api}).
-\index{Device modules}
+\item[Device Modules]\index{Device modules} EtherCAT-capable Ethernet device
-EtherCAT-capable Ethernet device driver modules\index{Device modules}, that
+driver modules\index{Device modules}, that offer their devices to the EtherCAT
-offer their devices to the EtherCAT master via the device interface (see
+master via the device interface (see sec.~\ref{sec:ecdev}). These modified
-sec.~\ref{sec:ecdev}). These modified network drivers can handle network
+network drivers can handle network devices used for EtherCAT operation and
-devices used for EtherCAT operation and ``normal'' Ethernet devices in
+``normal'' Ethernet devices in parallel. A master can accept a certain device
-parallel. A master can accept a certain device and then is able to send and
+and then is able to send and receive EtherCAT frames. Ethernet devices
-receive EtherCAT frames. Ethernet devices declined by the master module are
+declined by the master module are connected to the kernel's network stack as
-connected to the kernel's network stack as usual.
+usual.
-\paragraph{Application Modules}
+\item[Application Modules]\index{Application} A kernel module that uses the
-\index{Application module}
+EtherCAT master (usually for cyclic exchange of process data with EtherCAT
+slaves). These modules are not part of the EtherCAT master
-Kernel modules, that use the EtherCAT master (usually for cyclic exchange of
+code\footnote{Although there are some examples provided in the
-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 chap.~\ref{chap:api}). If this succeeds, the module has the
+interface (see chap.~\ref{chap:api}). If this succeeds, it has the control
-control over the master: It can provide a bus configuration and exchange
+over the master: It can provide a bus configuration and exchange process data.
-process data.
+\end{description}
 %------------------------------------------------------------------------------
 \section{Phases}
 \index{Master phases}
 \centering
 \includegraphics[width=.9\textwidth]{images/phases}
 \caption{Master phases and transitions}
 \label{fig:phases}
 \end{figure}
 \begin{description}
 \item[Orphaned phase]\index{Orphaned phase} This mode takes effect, when the
 master still waits for its Ethernet device to connect. No bus communication is
 possible until then.
 \item[Configuration] The master is requested and the configuration is applied.
 Domains are created Slaves are configured and Pdo entries are registered (see
 sec.~\ref{sec:masterconfig}).
 \item[Operation] Cyclic code is run, process data is exchanged (see
-sec.~\ref{sec:cyclic}).
+sec.~\ref{sec:cyclic}). To enter operation mode, the master has to be
+``activated'' to calculate the process data image and apply the bus
+configuration for the first time. After activation, the application is in
+charge to send and receive frames.
 \end{description}
 \paragraph{Example Applications} \index{Example Applications} There are a few
 example applications in the \textit{examples/} subdirectory of the master
 sec.~\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
+to know the appropriate kind of lock. For example if the application module
-functionality, ordinary kernel semaphores would not be sufficient. For that, an
+uses RTAI functionality, ordinary kernel semaphores would not be sufficient.
-important design decision was made: The application that reserved a master must
+For that, an important design decision was made: The application that reserved
-have the total control, therefore it has to take responsibility for providing
+a master must have the total control, therefore it has to take responsibility
-the appropriate locking mechanisms. If another instance wants to access the
+for providing the appropriate locking mechanisms.  If another instance wants
-master, it has to request the master lock by callbacks, that have to be set by
+to access the master, it has to request the master lock by callbacks, that
-the application. Moreover the application can deny access to the master if it
+have to be set by the application. Moreover the application can deny access to
-considers it to be awkward at the moment.
+the master if it considers it to be awkward at the moment.
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.6\textwidth]{images/master-locks}
 \caption{Concurrent master access}

branch	stable-1.4
changeset 1659	f04865a2454f
parent 1657	3dbdb7392d7b
child 1660	f183b0c12b1f