[etherlab-users] Is the installation know Xenomai style
Franz.Engel at eads.net
Thu Sep 19 15:28:54 CEST 2013
Thank you very much for your detailed response. If I understand your answer and the answer of Florian correct, I don't need the ec_rtdm. I have to compile the code for my NIC and I have to link against the ethercat_rtdm library. Before, I thought that an installation without the ec_rtdm module is not correct. That's why I use the default tree of the mercurial. But Florian means also, that I have to change to the 1.5 stable tree.
Xenomai is not an option for me, it is absolute needed because of other parts of my system. So it is easier for me to run everything with the same API and the same method.
So, after my holiday I will try it.
Thank you and have a good time,
Von: Jeroen Van den Keybus [mailto:jeroen.vandenkeybus at gmail.com]
Gesendet: Mittwoch, 18. September 2013 21:14
An: Engel, Franz
Cc: etherlab-users at etherlab.org
Betreff: Re: [etherlab-users] Is the installation know Xenomai style
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.
2013/9/17 Engel, Franz <Franz.Engel at eads.net>
I have the following system configuration: Ubuntu 10.04, Kernel 2.6.38, I-Pipe and Xenomai 184.108.40.206, 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,
etherlab-users mailing list
etherlab-users at etherlab.org
More information about the Etherlab-users