A Dimarts, 18 de febrer de 2014, Gilles Chanteperdrix va escriure: > On 02/18/2014 01:08 PM, Leopold Palomo-Avellaneda wrote: > > Hi, > > > > following our attempt to make a competitive realtime soem library under RTnet > > and Xenomai we are blocked now by some conceptual problems. Or simple, we > > don't know more :-( > > > > After checking why it changes the context, looking on the code, etc we have > > found that if we open a RTnet device it's problematic to use it in two > > different context (RT and NRT). > > > > Our original idea was to encapsulate all the Ethercat functions in a class > > decoupling all the RT from the NRT part. We don't need (want) that all this > > code works on RT, just an small part. > > > > The permanent part is solved with the xddp communications, but not the > > transitory (the configuration). We need to access to the device to configure > > it, and to wrap all this stuff with xddp it's too complicate. > > > > So, my questions now are about intertask communications. I understand that > > from a NRT program, I can create a rt_task and be RT. But, from the RT world, > > can I create a NRT thread?. I mean, if I make my current program rt_shadow can > > I create a NRT thread? > > > > Can I call a function to be executed in a RT context? I mean to create a bunch > > of functions that could be called from a NRT program but this functions be > > executed in a RT context. I know that I can create a rt_task for each > > function, but if for example that configure a device, I would like some kind > > of persistence, not that when it finish the task, the context would be > > deleted. > > > > Reading more I think that what we would like really it's the xenomm project. > > To have an instance of a class executed in a RT context. > > You look confused, a little terminology to help you:
I don't look confused. I'm confused :-) sorry for the noise, but this stuff it's not easy. It's the problem of have small people that don't let you sleep ... > A task has a shadow, or it does not have a shadow. rt_task_shadow > creates a shadow for the current task. rt_task_create creates a new task > with a shadow. pthread_create when not using the link flags to link with > Xenomai posix skin library creates a task without a shadow. > > A task which has a shadow, can run in either of two modes: in secondary > mode, it is handled by the Linux scheduler, just as a task without a > shadow. In primary mode, it is handled by Xenomai scheduler, which is > not possible without a shadow. > > Now, could you ask your questions again, referring to this terminology? I will try. If not, I hope that Sergi or Orestes help me. After your email, talking with Sergi we think that maybe we are trying to complicate our life too much and we are too much worried of our the RT task. We would like to make sure that the RT sync task of the ethercat worked always in realtime without changes context. But seems that always is this case (we have to be sure about this task, in concrete) I have to rethink all you have said and I will rewrite the email. But, I suppose that my wish (I'm a lot of formatted in C++) is to have an object in RT world, with n functions running concurrently (methods functions) controlled by the Xenomai scheduler where I could call methods from the NRT world. Thanks in advance, Leopold -- -- Linux User 152692 Catalonia -------------- 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/20140218/3b48dfd3/attachment.sig> _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
