Re: [Xenomai] Realtime tasks concepts (II)

[Leopold Palomo-Avellaneda <leo@alaxarxa.net>]

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>