Re: [Xenomai-help] RTDM or native Xenomai API
Thank you very much Gilles for the explanations! I think I understand the overall picture better now. Thank you, Andrey. On 16 April 2012 01:52, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org wrote: On 04/16/2012 01:47 AM, Gilles Chanteperdrix wrote: On 04/16/2012 12:53 AM, Andrey Nechypurenko wrote: Hi Gilles, Thank you very much for such low-latency reply! :-) RTDM is the API of choice for developing drivers for real-time applications using xenomai. Please correct me if I just misunderstand something here, but as I understand, RTDM is an abstraction layer with concrete implementation using xenomai API. As stated in the referenced paper from Jan Kiszka, the original reason for introducing this layer was to achieve portability across different RT solutions for Linux. Since that time, a lot of considered RT solutions becomes irrelevant. In fact, I would say, there are only Xenomai and preempt_rt. If this assumption is true, then I can not see the advantages of the additional layer unless it is more then just an abstraction layer. Does RTDM API makes certain tasks easier/better compared to the similar native xenomai API? Just to give concrete example - what is the advantage of using rtdm_task_init() vs. rt_task_create or xnintr_init() vs. rtdm_irq_request()? The native API is designed to write applications, not drivers. The RTDM API is designed to write drivers. Using the native API in user-space is deprecated, the native API is made for user-space. Using the native API in *kernel-space* is deprecated, the native API is made for user-space. Writing applications in kernel-space is not what we recommend, as much as writing drivers in user-space. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/16/2012 08:55 AM, Andrey Nechypurenko wrote: Thank you very much Gilles for the explanations! I think I understand the overall picture better now. Thank you, Andrey. To summarize again: - the native API and posix API were made available in kernel-space at the beginning of the xenomai project as a mean to help porting applications from rtai and rtlinux to xenomai, they could also be used to write drivers, but it started to no longer make sense as soon as the RTDM API appeared; - they will both be gone in xenomai 3.0, only the RTDM API will be available in kernel-space. native and posix will still be available in user-space of course. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
- they will both be gone in xenomai 3.0, only the RTDM API will be available in kernel-space. I think you convinced me to start with RTDM API with the statement above :-) Thanks, Andrey. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] RTDM or native Xenomai API
Hi Folks, In our hobby robotics project [1] we start using Xenomai for RT tasks. The first application was PWM generation with GPIO to control servo motors [2] (the next would be dealing with interrupts from wheel encoders). We have made it from the user space and result was not as good as we would like it to be so I decide to write kernel module to reduce the jitter. And here comes the question whether to use RTDM or just plain Xenomai API? I was never using RTDM in the past. Based on what I have read, the main intent of the RTDM is to make driver code portable across different RT solutions for Linux. I understand it and it makes sense. However, looking around and asking myself what are these different solutions, I just can name Xenomai and preempt_rt patch. AFAIK, all the rest are either dead (or almost dead) or not relevant for hobby open-source development. So my question is what are the practical advantages of using RTDM instead of Xenomai API? I would be very glad to hear the opinion of experienced Linux RT developers about it. Thank you very much, Andrey. [1] http://veter-project.blogspot.de/2011/11/how-to-build-beagleboard-based-wifi.html [2] http://veter-project.blogspot.de/2011/09/real-time-enough-about-pwms-and-shaky.html ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/15/2012 11:24 PM, Andrey Nechypurenko wrote: Hi Folks, In our hobby robotics project [1] we start using Xenomai for RT tasks. The first application was PWM generation with GPIO to control servo motors [2] (the next would be dealing with interrupts from wheel encoders). We have made it from the user space and result was not as good as we would like it to be so I decide to write kernel module to reduce the jitter. And here comes the question whether to use RTDM or just plain Xenomai API? I was never using RTDM in the past. Based on what I have read, the main intent of the RTDM is to make driver code portable across different RT solutions for Linux. I understand it and it makes sense. However, looking around and asking myself what are these different solutions, I just can name Xenomai and preempt_rt patch. AFAIK, all the rest are either dead (or almost dead) or not relevant for hobby open-source development. So my question is what are the practical advantages of using RTDM instead of Xenomai API? I would be very glad to hear the opinion of experienced Linux RT developers about it. RTDM is the API of choice for developing drivers for real-time applications using xenomai. We aim at the same separation as you have with Linux: driver code in kernel-space (using RTDM in the case of Xenomai), application code resides in user-space, using any other skin, though what probably makes sense to a new project is to use the native or posix skin. Both skins have bindings to access RTDM drivers. So, in particular, it means that writing driver code (meaning code which interacts with hardware) in user-space is not what we would recommend. And handling interrupts in user-space is even less recommended. Also note that in the case of omap3, gptimers may be used to generate PWM without software assistance. And that the gpio kernel functions are safe to be used in real-time context. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
Hi Gilles, Thank you very much for such low-latency reply! :-) RTDM is the API of choice for developing drivers for real-time applications using xenomai. Please correct me if I just misunderstand something here, but as I understand, RTDM is an abstraction layer with concrete implementation using xenomai API. As stated in the referenced paper from Jan Kiszka, the original reason for introducing this layer was to achieve portability across different RT solutions for Linux. Since that time, a lot of considered RT solutions becomes irrelevant. In fact, I would say, there are only Xenomai and preempt_rt. If this assumption is true, then I can not see the advantages of the additional layer unless it is more then just an abstraction layer. Does RTDM API makes certain tasks easier/better compared to the similar native xenomai API? Just to give concrete example - what is the advantage of using rtdm_task_init() vs. rt_task_create or xnintr_init() vs. rtdm_irq_request()? Also note that in the case of omap3, gptimers may be used to generate PWM without software assistance. And that the gpio kernel functions are safe to be used in real-time context. We already using 2 available hardware PWM generators. The experiment with GPIO was mainly to start collecting experience with Xenomai and see how far the one can go in user space. Now, I want to make the next step and write kernel module which is doing the same. That is why the question about RTDM. Thank you very much! Andrey. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/16/2012 12:53 AM, Andrey Nechypurenko wrote: Hi Gilles, Thank you very much for such low-latency reply! :-) RTDM is the API of choice for developing drivers for real-time applications using xenomai. Please correct me if I just misunderstand something here, but as I understand, RTDM is an abstraction layer with concrete implementation using xenomai API. As stated in the referenced paper from Jan Kiszka, the original reason for introducing this layer was to achieve portability across different RT solutions for Linux. Since that time, a lot of considered RT solutions becomes irrelevant. In fact, I would say, there are only Xenomai and preempt_rt. If this assumption is true, then I can not see the advantages of the additional layer unless it is more then just an abstraction layer. Does RTDM API makes certain tasks easier/better compared to the similar native xenomai API? Just to give concrete example - what is the advantage of using rtdm_task_init() vs. rt_task_create or xnintr_init() vs. rtdm_irq_request()? The native API is designed to write applications, not drivers. The RTDM API is designed to write drivers. Using the native API in user-space is deprecated, the native API is made for user-space. RTDM is not an additional layer, RTDM uses the same primitives as the native API, and so does the posix API. So, there is no additional overhead involved. rtdm_task_init is the way to create a kernel-space thread, but what rtdm brings is not really that, this is only a building block, what RTDM brings is the infrastructure which make the dialog possible between the application and the driver. On the driver side, you implement open/read/write/ioctl callbacks, and magically, these functions get called when the application calls open/read/write/ioctl in user-space. Also note that in the case of omap3, gptimers may be used to generate PWM without software assistance. And that the gpio kernel functions are safe to be used in real-time context. We already using 2 available hardware PWM generators. The experiment with GPIO was mainly to start collecting experience with Xenomai and see how far the one can go in user space. Now, I want to make the next step and write kernel module which is doing the same. That is why the question about RTDM. We are going to continue with the PWM example to help you understand what we encourage you to do. You can make an RTDM driver which will allow to control the GPIOs from user-space, as you probably already found out, this will incur a high jitter to the PWM signal. Not only that, but it will also make the application code depend on hardware details (the number of the GPIOS, the duty cycle). What your application really want to control is the motor speed, so, what you should do is an RTDM driver, which generates the PWM using GPIOS, in kernel-space, according to instructions given by the application (via write or ioctl) about the target motor speed. You no longer have any jitter problem, and now the application is completely ignorant of the hardware details, it controls what it wants to control: the motor speed. If you split the code this way (drivers in kernel-space, using RTDM, application in user-space, using the native or posix api), you only have to modify drivers when changing hardware, and you can write several applications using the same hardware without having to rewrite every time the interactions with hardware. That is the way things are done with linux, there is no reason not to do the same with xenomai. The famous example which does not do that in the linux world is the X server, and even this is changing as more and more interactions with graphic driver are moving to kernel-space. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/16/2012 01:47 AM, Gilles Chanteperdrix wrote: On 04/16/2012 12:53 AM, Andrey Nechypurenko wrote: Hi Gilles, Thank you very much for such low-latency reply! :-) RTDM is the API of choice for developing drivers for real-time applications using xenomai. Please correct me if I just misunderstand something here, but as I understand, RTDM is an abstraction layer with concrete implementation using xenomai API. As stated in the referenced paper from Jan Kiszka, the original reason for introducing this layer was to achieve portability across different RT solutions for Linux. Since that time, a lot of considered RT solutions becomes irrelevant. In fact, I would say, there are only Xenomai and preempt_rt. If this assumption is true, then I can not see the advantages of the additional layer unless it is more then just an abstraction layer. Does RTDM API makes certain tasks easier/better compared to the similar native xenomai API? Just to give concrete example - what is the advantage of using rtdm_task_init() vs. rt_task_create or xnintr_init() vs. rtdm_irq_request()? The native API is designed to write applications, not drivers. The RTDM API is designed to write drivers. Using the native API in user-space is deprecated, the native API is made for user-space. Using the native API in *kernel-space* is deprecated, the native API is made for user-space. Writing applications in kernel-space is not what we recommend, as much as writing drivers in user-space. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help