El Dijous, 20 de febrer de 2014, a les 23:22:40, Gilles Chanteperdrix va escriure: > On 02/20/2014 08:57 PM, Orestes Mas wrote: > >> 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? > > In an RTDM driver, every file operation (read, write, ioctl) has an _rt > and an _nrt version. The _rt version requires a thread with a shadow, > the _nrt version does not. > > > 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. > > Why not using the same task to do the initializations, and later on > become periodic and "maintain the data flow" ?
Because at least, I don't know how to do that. Maybe Orestes. This is what I asked yesterday, I can imagine an "object", that has several functions and I can call to do some action. Bit i cannot image the same in terms of tasks. With a task, we create some kind of protocol via xddp to send commands and the the task do some function, but if not, the communication between the primary mode and the secondary it's not obvious if you don't want to have contexts change. Leopold -- -- Linux User 152692 PGP: 0xF944807E Catalonia ------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
