A Dijous, 20 de febrer de 2014, Gilles Chanteperdrix va escriure: > On 02/20/2014 12:41 AM, Leopold Palomo-Avellaneda wrote: > > 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. > > Again: the terms "real-time" and "non real-time" are ambiguous. Please > stick to the terms "task with a shadow", "task without a shadow" and > "primary mode" or "secondary mode". > :-(
Ok, I agree with you that the nomenclature is important to define correctly but please don't be so strict. I'm in the open source world since long time ago, and I understand perfectly that the main developers of a projects are tired of dummy questions, or not clear mails, etc. But, I think that the relatime world is a complex thing, and not so easy when you are learning, or having troubles. And although that there's a lot documentation, it's difficult to find the document that fits all your doubts. So, again, 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] and [2] I understand that a realtime thread is executed in primary mode and scheduled by the Xenomai scheduler. If this RT thread call a non-RT primitive, then RT-Nucleus move this RT-Thread to the Linux queue and this thread is controlled by the Linux scheduler. A Non-RT thread is executed in secondary mode and controlled by the Linux scheduler. What I don't understand is for example, I create a C/C++ program, and I use the command rt_task_create, linked against xenomai and native, and not use the POSIX skin. This program has its own main thread and another thread: the thread of the rt_task. May I understand that the main thread of the program is controlled by the Linux scheduler and executed in secundary mode and the rt- task is controlled by the Xenomai scheduler and executed in primary domain? It's true? If I have a program (with main, etc) like the examples, if I call the rt_task_shadow, the main thread of the program (or from where I call it) turns the current thread, (executed in secondary, controlled by the Linux scheduler) and move this thread to primary mode and controlled by the Xenomai scheduler? In our case, the SOEM rt version has NO threads. Just a bunch of functions and 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 (executed in secondary mode, Linux scheduler) that open the RTNet device (raw mode, rtdm), configure the slaves and then a rt_task (executed in primary mode, Xenomai scheduler) 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 (secondary mode, Linux scheduler) world. I understand that if a thread that is running in primary mode calls any Linux function (non-rt primitive) then there's a context change. It's moved from primary mode to secondary mode. But if not, in our case just xddp communications, my rt_task should be in the RT world, primary mode. 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. Well, I hope I have been clear. Thanks for all, Leopold [1] http://www.cs.ru.nl/lab/xenomai/exercises/ex01/Exercise-1.html [2] http://retis.sssup.it/~lipari/courses/str07/xenomai-handout.pdf -- -- 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/20140220/a94d2526/attachment.sig> _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
