On 02/20/2014 11:48 PM, Leopold Palomo-Avellaneda wrote:
> 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.
The contexts changes should not be a problem if they happen during the
configuration phase.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
