[etherlab-users] Is the installation know Xenomai style

[Jeroen Van den Keybus]

I'm in the process of studying the ec_master code in order to better
understand how a slave needs to be constructed. From what I learnt until
know, I believe it works like this:

1. First, you need to insmod ec_master with the option 'main_devices=<MAC
addresses>'. Then you have 2 options.

a) You load one of the EtherCAT enabled NIC drivers (ec_e1000.ko), which
will register itself for every NIC instance to the running ec_master. If
there's a match of MAC address, the master will immediately start using it
in idle mode and it lets the driver know that it has to do EtherCAT
specific things and not become a Linux eth<x> device. If there is no match,
the driver continues to register with Linux and becomes an eth<x> device as
usual. Beware that if a driver is already loaded for a NIC type (e.g.
e1000), the ec_... drivers will load but will not be 'attached' to the
device until the original driver is unloaded first (rmmod e1000) and then
the ec_ driver is reloaded. It's how the Linux PCI subsystem works.

b) You can use ec_generic.ko. It similarly registers the MAC addresses of
any eth<x> adapter in the Linux system and if the adapter MAC matches and
it is in the down state, the master will start using it.

For the up- and downsides, see my answer to your second question:

2. After moving from the INIT state, your application is solely responsible
for calling ec_master functions. It is then no more than a library with
functions like ecrt_master_send that in turn eventually end up in calling
the NIC driver. This is where a) and b) above fundamentally differ. In the
case of a), the code flow through the NIC send function never blocks, since
it has been designed that way. If you were running in a RT (primary mode)
Xenomai thread, that very thread would run without interruptions through
the ec_master functions, the driver code and return to your application. In
the case of b) however, the original Linux driver is called. It may contain
code that blocks and would cause a Xenomai thread to switch to secondary
mode. That could be e.g. due to the need to allocate socket buffers. It
breaks hard real-time. As an example of how the ec_ drivers avoid blocking:
they preallocate these buffers once and recycle them perpetually.

Also, it seems that, using RT-PREEMPT w/o anything like Xenomai, already
does a very good job of meeting deadlines. So ec_generic definitely has its
purposes.

If you want to run using native Xenomai API, be sure to link against
ethercat_rtdm and check /proc/xenomai/stat that no mode switches are
occurring.


J.



2013/9/17 Engel, Franz <Franz.Engel at eads.net>

> Hi everybody,
>
> I have the following system configuration: Ubuntu 10.04, Kernel 2.6.38,
> I-Pipe and Xenomai 2.6.2.1,  the developer version of etherlab from the
> mercurial repo
>
> I have two simple question:
> 1. How can I be sure if I installed the ethercatmaster with realtime
> capabilities. After the start of the master (with "./ethercat start") I get
> the following entries in my lsmod: ec_rtdm, ec_master, e1000. Is it correct
> that there is still the e1000 module?
> 2. Or is RTDM using the ethernet module (e1000). Is this realy realtime?
> Or should I replace the module with an realtime module from the
> rtnet-Project?
>
> Thanks and regards,
>       Franz
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20130918/5627dbce/attachment-0003.htm>