Well, please, correct me if I'm wrong in some of this sentences. I will try to rewrite my email in a more clear terminology.
Following [1] I understand that a realtime task is scheduled by the Xenomai scheduler and a non-realtime by the Linux scheduler. I can use the terms "thread" and "task" in the same meaning. When I create a program, and I use the command rt_task_create, linked against xenomai and native, and not used the POSIX skin, this task has a shadow and it's scheduled by Xenomai. If I call a function in the Linux API, this task is scheduled by the Linux scheduler. There's a change in the context. If I have a program (with main, etc) like the examples, if I call the rt_task_shadow, the main thread of main program (or from where I call it) turns the current Linux task into a native Xenomai task. If I have a normal Linux program, that use a native functions (not posix, not pthreads), if I have a rt_task, when I run the program my main program runs controlled by the Linux scheduler and my rt_task runs controlled by the xenomai kernel. In our case, the SOEM rt version has NO threads. Just a mutex that is changed in the RT version by a rt_mutex. The devices are opened and used by rt_*** functions. No posix functions. >From my point of view, I should be able to have a Linux (NRT) program that open the RTNet device (raw mode, rtdm), configure my slaves and then a rt_task that send and receive in a deterministic way the devices, while the rest of the program (the main thread, or others threads) live happy in the Linux world. And no context change. I understand that if a rt_task call, or uses any Linux function then there's a context change, but if not, just xddp communications, my rt_task should be in the RT world. 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. Another question that I don't have clear is about the memory. If I have some global var, (for instance, char * and a malloc) in a Linux program and I call the rt_task, I can access to this memory, but I have a context switch no? Well, I hope I have been clear. Thanks for all, Leopold [1] http://www.cs.ru.nl/lab/xenomai/exercises/ex01/Exercise-1.html 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: > > 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? > > -- -- Linux User 152692 Catalonia _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
