[etherlab-dev] EtherCAT Master EoE with Xenomai
Rob Stocks
rjs at computerway.biz
Sun Feb 24 23:25:48 CET 2013
I am using the 1.5.2 master with a Xenomai user-space application which is
now working very well thanks to previous guidance from this mailing list.
However, I have been trying to get EoE working and have encountered a few
difficulties.
It would seem from looking at the documentation and the code that the
callbacks mechanism has to be used to allow the EoE datagrams to be sent
and received along with the application datagrams and appropriate locking
has to be provided by the application. This all makes sense but the problem
is that unless the application is in kernel space, the callback mechanism
is not supported and the necessary calls are not exposed via IOCTLs.
After studying the code, I noticed that there is not a problem for
receiving EoE datagrams as the callback simply calls ecrt_master_receive
which has to be called cyclically by the application anyway (in fact, I
would argue that the receive callback isn't necessary at all). However, for
sending datagrams, there is a problem since it is not easy to call into
user space from kernel space (and from a normal kernel thread to a Xenomai
RT user-space task).
I have come up with an idea that I think "has some legs" and I have tested
it and it appears to work well. The idea is that if EC_IOCTL_RTDM is
defined, instead of not registering any callbacks, the master registers an
empty receive callback (not needed - see above) and a send callback that
sets a flag in the context object. It then waits for this flag to be
cleared. When the application next calls ecrt_master_send, the master
module handling the IOCTL checks the flag and if set, it calls
ecrt_master_send_ext first then clears the flag (it can't call the internal
callback as in the non-RTDM case because it uses a standard kernel
semaphore). This causes any EoE datagrams to be added to the queue before
sending the application datagrams. I just need to work through any possible
race conditions and make sure the EoE thread can be stopped without waiting
forever for ecrt_master_send to be called.
I would be grateful for any comments/guidance on the above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20130224/8db3e33d/attachment-0001.htm>
More information about the Etherlab-dev
mailing list