* Re: [Xenomai] Realtime tasks concepts (II)
@ 2014-02-20 19:57 Orestes Mas
2014-02-20 22:22 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Orestes Mas @ 2014-02-20 19:57 UTC (permalink / raw)
To: xenomai
>
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] Realtime tasks concepts (II)
2014-02-20 19:57 [Xenomai] Realtime tasks concepts (II) Orestes Mas
@ 2014-02-20 22:22 ` Gilles Chanteperdrix
2014-02-20 22:48 ` Leopold Palomo-Avellaneda
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-20 22:22 UTC (permalink / raw)
To: Orestes Mas; +Cc: xenomai
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" ?
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] Realtime tasks concepts (II)
2014-02-20 22:22 ` Gilles Chanteperdrix
@ 2014-02-20 22:48 ` Leopold Palomo-Avellaneda
2014-02-20 22:49 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Leopold Palomo-Avellaneda @ 2014-02-20 22:48 UTC (permalink / raw)
To: xenomai
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] Realtime tasks concepts (II)
2014-02-20 22:48 ` Leopold Palomo-Avellaneda
@ 2014-02-20 22:49 ` Gilles Chanteperdrix
2014-02-20 23:11 ` Leopold Palomo-Avellaneda
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-20 22:49 UTC (permalink / raw)
To: Leopold Palomo-Avellaneda; +Cc: xenomai
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] Realtime tasks concepts (II)
2014-02-20 22:49 ` Gilles Chanteperdrix
@ 2014-02-20 23:11 ` Leopold Palomo-Avellaneda
2014-02-20 23:12 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Leopold Palomo-Avellaneda @ 2014-02-20 23:11 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
El Dijous, 20 de febrer de 2014, a les 23:49:40, Gilles Chanteperdrix va
escriure:
> 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.
We can do more tests, but we still have a contexts change in the data flow, and
I don't know why.
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140221/a736b7f8/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] Realtime tasks concepts (II)
2014-02-20 23:11 ` Leopold Palomo-Avellaneda
@ 2014-02-20 23:12 ` Gilles Chanteperdrix
0 siblings, 0 replies; 6+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-20 23:12 UTC (permalink / raw)
To: Leopold Palomo-Avellaneda; +Cc: xenomai
On 02/21/2014 12:11 AM, Leopold Palomo-Avellaneda wrote:
> El Dijous, 20 de febrer de 2014, a les 23:49:40, Gilles
> Chanteperdrix va escriure:
>> The contexts changes should not be a problem if they happen
>> during the configuration phase.
>
> We can do more tests, but we still have a contexts change in the
> data flow, and I don't know why.
That is another issue, right?
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-02-20 23:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-20 19:57 [Xenomai] Realtime tasks concepts (II) Orestes Mas
2014-02-20 22:22 ` Gilles Chanteperdrix
2014-02-20 22:48 ` Leopold Palomo-Avellaneda
2014-02-20 22:49 ` Gilles Chanteperdrix
2014-02-20 23:11 ` Leopold Palomo-Avellaneda
2014-02-20 23:12 ` Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.