330   \caption{Master architecture}

   330   \caption{Master Architecture}

   334 \paragraph{Master Module}

   334 The components of the master environment are described below:

   335 \index{Master module}

   335 

   336 

   336 \begin{description}

   337 Kernel module containing one or more EtherCAT master instances (see

   337 

   338 sec.~\ref{sec:mastermod}), the ``Device Interface'' (see sec.~\ref{sec:ecdev})

   338 \item[Master Module]\index{Master Module} Kernel module containing one or more

   339 and the ``Application Interface'' (see chap.~\ref{chap:api}).

   339 EtherCAT master instances (see sec.~\ref{sec:mastermod}), the ``Device

   340 

   340 Interface'' (see sec.~\ref{sec:ecdev}) and the ``Application Interface'' (see

   341 \paragraph{Device Modules}

   341 chap.~\ref{chap:api}).

   342 \index{Device modules}

   342 

   343 

   343 \item[Device Modules]\index{Device modules} EtherCAT-capable Ethernet device

   344 EtherCAT-capable Ethernet device driver modules\index{Device modules}, that

   344 driver modules\index{Device modules}, that offer their devices to the EtherCAT

   345 offer their devices to the EtherCAT master via the device interface (see

   345 master via the device interface (see sec.~\ref{sec:ecdev}). These modified

   346 sec.~\ref{sec:ecdev}). These modified network drivers can handle network

   346 network drivers can handle network devices used for EtherCAT operation and

   347 devices used for EtherCAT operation and ``normal'' Ethernet devices in

   347 ``normal'' Ethernet devices in parallel. A master can accept a certain device

   348 parallel. A master can accept a certain device and then is able to send and

   348 and then is able to send and receive EtherCAT frames. Ethernet devices

   349 receive EtherCAT frames. Ethernet devices declined by the master module are

   349 declined by the master module are connected to the kernel's network stack as

   350 connected to the kernel's network stack as usual.

   350 usual.

   351 

   351 

   352 \paragraph{Application Modules}

   352 \item[Application]\index{Application} A program that uses the EtherCAT master

   353 \index{Application module}

   353 (usually for cyclic exchange of process data with EtherCAT slaves). These

   354 

   354 programs are not part of the EtherCAT master code\footnote{Although there are

   355 Kernel modules, that use the EtherCAT master (usually for cyclic exchange of

   355 some examples provided in the \textit{examples/} directory.}, but have to be

   356 process data with EtherCAT slaves). These modules are not part of the EtherCAT

   356 generated or written by the user. An application can ``request'' a master

   357 master code\footnote{Although there are some examples provided in the

   357 through the application interface (see chap.~\ref{chap:api}). If this

   358 \textit{examples/} directory.}, but have to be generated or written by the

   358 succeeds, it has the control over the master: It can provide a bus

   359 user. An application module can ``request'' a master through the application

   359 configuration and exchange process data.  Applications can be kernel modules

   360 interface (see chap.~\ref{chap:api}). If this succeeds, the module has the

   360 (that use the kernel application interface directly) or userspace programs,

   361 control over the master: It can provide a bus configuration and exchange

   361 that use the application interface via the EtherCAT library (see

   362 process data.

   362 sec.~\ref{sec:userlib}).

   363 

   364 \end{description}

   593 sec.~\ref{sec:cyclic}).

   596 sec.~\ref{sec:cyclic}). To enter operation mode, the master has to be

   597 ``activated'' to calculate the process data image and apply the bus

   598 configuration for the first time. After activation, the application is in

   599 charge to send and receive frames.

   639 to know the appropriate kind of lock. For example if the application uses RTAI

   645 to know the appropriate kind of lock. For example if the application is in

   640 functionality, ordinary kernel semaphores would not be sufficient. For that, an

   646 kernelspace and uses RTAI functionality, ordinary kernel semaphores would not

   641 important design decision was made: The application that reserved a master must

   647 be sufficient. For that, an important design decision was made: The

   642 have the total control, therefore it has to take responsibility for providing

   648 application that reserved a master must have the total control, therefore it

   643 the appropriate locking mechanisms. If another instance wants to access the

   649 has to take responsibility for providing the appropriate locking mechanisms.

   644 master, it has to request the master lock by callbacks, that have to be set by

   650 If another instance wants to access the master, it has to request the master

   645 the application. Moreover the application can deny access to the master if it

   651 lock by callbacks, that have to be set by the application. Moreover the

   646 considers it to be awkward at the moment.

   652 application can deny access to the master if it considers it to be awkward at

   653 the moment.