> > A 2014-02-20 11:41, Gilles Chanteperdrix escrigué: > > On 02/20/2014 11:27 AM, Gilles Chanteperdrix wrote: > > Our aim is to design NRT master and slaves (c++ objects) that communicates >>> with a RT task. The RT task is in charge of establish a continuous >>> communication with EtherCAT devices. This task communicates with NRT master >>> by the xddp sockects. The problem appears when the master call the RT SOEM >>> functions for the configuration, because it is necessary that the master >>> becomes a RT task, if not it doesn't work. And it has no sense. >>> >> >> Only a task with a shadow can call RT services, because it needs to be >> able to switch to primary mode, and only a task with a shadow can switch to >> primary mode. >> > > By RT services, I mean rt_mutex services and RTDM callbacks for which > you implemented the _rt version. If you mean anything else (like Xenomai > services), then you are to imprecise again, and the answer to your > question is "it depends", because on a service by service basis, some > need a task with a shadow, some do not. But usually, if a service needs > a task with a shadow, that is because its implementation requires it > (for instance because the task needs to be suspended in Xenomai > scheduler, which can not happen if the task does not have a shadow). >
Sorry if I start a new thread with the same subject: I've just joined the mailing list and I don't have the past messages in my e-mail client. Thanks for your explanations, Gilles. So, let's try to re-state the problem in "shadow" terms, to see if we finally understand it. 1) We've a linux installation with xenomai patches and rt_net driver (RTDM) that manage rteth0 interface. From our experience and your explanations we assume that rt_net services, being RTDM, must be called _always_ from a task with a shadow. Is this correct? The problem that started this list thread was that the SOEM library we use to communicate with some devices through the rteth0 interface has some initialization functions (init, config, and so on) and then a function to be executed periodically to maintain a data flow between the host PC and the devices. Initially we put _only_ this periodic part into a task with a shadow, but tried to call init and config functions from the main program --without a shadow--, and that didn't work. For it to work we had to shadow also the main task, a thing that becomes obvious after your explanations. 2) We didn't like to have the main task shadowed because we assumed (perhaps erroneously) that it's better to keep the number of shadowed tasks to a minimum. If it's not possible, from your explanations I think that perhaps the best compromise is to have tha main task shadowed, but with priority 0 and scheduled by SCHED_OTHER. If I do that, will my shadowed task running in primary mode commute to secondary mode when called by the main task? Probably I'll have more questions, but let's go step by step and clarify these before asking more. Thanks. Orestes. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
