[Xenomai-help] RTDM or native Xenomai API

[Xenomai-help] RTDM or native Xenomai API

[Andrey Nechypurenko]

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

Re: [Xenomai-help] RTDM or native Xenomai API

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] RTDM or native Xenomai API

[Andrey Nechypurenko]

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.

Re: [Xenomai-help] RTDM or native Xenomai API

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] RTDM or native Xenomai API

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] RTDM or native Xenomai API

[Andrey Nechypurenko]

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.chanteperdrix@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.

Re: [Xenomai-help] RTDM or native Xenomai API

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] RTDM or native Xenomai API

[Andrey Nechypurenko]

> - 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.