[Xenomai-help] PWM generation with GPIO

[Xenomai-help] PWM generation with GPIO

[Andrey Nechypurenko]

Hi Folks,

Recently I was trying to control standard servo motor with PWMs. The
system is 600MHz BeagleBoard xM (ARM) running Linux kernel version
2.6.35.9 with Xenomai version 2.5.6.

Pulses needs to be generated with 20milliseconds interval (50Hz).
Pulse width defines servo position and is typically in the range of
0.8milliseconds to 2.0milliseconds. To generate PWMs I am using GPIO
pin connected to the servo through TI's TXS0108E voltage-level
translator to translate +1.8V GPIO to required +5V. To trigger GPIO
state I am using direct memory writes (to mmapped area).

The generation loop is running in the Xenomai thread with priority 99
and looks like this:

  for(;;) {
      //set_data_out has offset 0x94
      gpio[OFFSET(0x6094)]=0x40000000;
      rt_task_sleep(up_period);
      //clear_data_out has offset 0x90
      gpio[OFFSET(0x6090)]=0x40000000;
      rt_task_wait_period(NULL); }

where gpio array is a pointer to the memory area responsible for
controlling GPIO state. The complete code could be found here:
https://www.gitorious.org/veter/vehicle/blobs/master/src/xenopwm.c

So now the question/problem I have. If the system load is low, then
everything is fine. However, if the system load goes beyound ~60%,
servos starts shaking which is a sign of not precise PWM timing. I
have written the blog post with more details and relevant videos:
http://veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html
. Just scroll down to the section named "Solution 2 - predictable
timing with Xenomai" since the rest is probably obvious for the folks
hanging around here ;-) .

Running the Xenomai's latency application in parallel with our test
program reveals the latency of around 40 microseconds. Based on what I
read in Internet, 40 microseconds is considered "normal/OK" latency
for Linux/Xenomai running on ARM at 600MHz. Taking in account typical
pulse width of about 1 millisecond, 40 microseconds is about 4%. Could
it be that this 4% is in fact what causes servos to shake? If yes,
does it mean that even with Xenomai it is not possible to control
servos reliably even under moderate system load on the mentioned
hardware?

I am kind of hope that there are some tweeks could be done to make the
timing more precise and would really appreciate any hints.

Thank you,
Andrey.

Re: [Xenomai-help] PWM generation with GPIO

[Gilles Chanteperdrix]

On 09/05/2011 09:53 PM, Andrey Nechypurenko wrote:
> Hi Folks,
> 
> Recently I was trying to control standard servo motor with PWMs. The
> system is 600MHz BeagleBoard xM (ARM) running Linux kernel version
> 2.6.35.9 with Xenomai version 2.5.6.
> 
> Pulses needs to be generated with 20milliseconds interval (50Hz).
> Pulse width defines servo position and is typically in the range of
> 0.8milliseconds to 2.0milliseconds. To generate PWMs I am using GPIO
> pin connected to the servo through TI's TXS0108E voltage-level
> translator to translate +1.8V GPIO to required +5V. To trigger GPIO
> state I am using direct memory writes (to mmapped area).
> 
> The generation loop is running in the Xenomai thread with priority 99
> and looks like this:
> 
>   for(;;) {
>       //set_data_out has offset 0x94
>       gpio[OFFSET(0x6094)]=0x40000000;
>       rt_task_sleep(up_period);
>       //clear_data_out has offset 0x90
>       gpio[OFFSET(0x6090)]=0x40000000;
>       rt_task_wait_period(NULL); }
> 
> where gpio array is a pointer to the memory area responsible for
> controlling GPIO state. The complete code could be found here:
> https://www.gitorious.org/veter/vehicle/blobs/master/src/xenopwm.c
> 
> So now the question/problem I have. If the system load is low, then
> everything is fine. However, if the system load goes beyound ~60%,
> servos starts shaking which is a sign of not precise PWM timing. I
> have written the blog post with more details and relevant videos:
> http://veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html
> . Just scroll down to the section named "Solution 2 - predictable
> timing with Xenomai" since the rest is probably obvious for the folks
> hanging around here ;-) .
> 
> Running the Xenomai's latency application in parallel with our test
> program reveals the latency of around 40 microseconds. Based on what I
> read in Internet, 40 microseconds is considered "normal/OK" latency
> for Linux/Xenomai running on ARM at 600MHz. Taking in account typical
> pulse width of about 1 millisecond, 40 microseconds is about 4%. Could
> it be that this 4% is in fact what causes servos to shake? If yes,
> does it mean that even with Xenomai it is not possible to control
> servos reliably even under moderate system load on the mentioned
> hardware?
> 
> I am kind of hope that there are some tweeks could be done to make the
> timing more precise and would really appreciate any hints.

The best way to know if what you observe is due to the natural jitter or
to some other issue is to measure the jitter at the point where you
think it is. But, anyway, such low level code would be best implemented
in a driver, completely in kernel-space, that would reduce the jitter,
an ioctl allowing to configure the duty cycle.

> 
> Thank you,
> Andrey.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 
                                                                Gilles.

Re: [Xenomai-help] PWM generation with GPIO

[Andrey Nechypurenko]

> The best way to know if what you observe is due to the natural jitter or
> to some other issue is to measure the jitter at the point where you
> think it is.

Since the generation loop is so simple I was assuming (maybe too
naive) that this is exactly where it starts to deviate from the ideal
timing. But you are right - more precise measurements are required and
I will definitely try to do it.

> But, anyway, such low level code would be best implemented
> in a driver, completely in kernel-space, that would reduce the jitter,
> an ioctl allowing to configure the duty cycle.

I was trying to stay in the user space as long as possible :-) .
Please correct me if I am wrong here, but I was thinking that Xenomai
actually runs Linux kernel as one of it's tasks (acting as a kind of
supervisor). As a result, kernel could be preempted whenever Xenomai
finds it necessary so the real-time performance of the Xenomai task
(thread?) might be even better then kernel driver. Am I wrong with
this assumption?

In addition, by any chances, maybe you have some figures to estimate
the jitter values which might be realistic to achieve using
driver-based approach you suggested? Would you expect these figures to
be considerably better then what I was observing with Xenomai-based
implementation?

Thank you very much for such a quick response!
Andrey.

Re: [Xenomai-help] PWM generation with GPIO

[Gilles Chanteperdrix]

On 09/05/2011 10:14 PM, Andrey Nechypurenko wrote:
>> The best way to know if what you observe is due to the natural jitter or
>> to some other issue is to measure the jitter at the point where you
>> think it is.
> 
> Since the generation loop is so simple I was assuming (maybe too
> naive) that this is exactly where it starts to deviate from the ideal
> timing. But you are right - more precise measurements are required and
> I will definitely try to do it.
> 
>> But, anyway, such low level code would be best implemented
>> in a driver, completely in kernel-space, that would reduce the jitter,
>> an ioctl allowing to configure the duty cycle.
> 
> I was trying to stay in the user space as long as possible :-) .
> Please correct me if I am wrong here, but I was thinking that Xenomai
> actually runs Linux kernel as one of it's tasks (acting as a kind of
> supervisor). As a result, kernel could be preempted whenever Xenomai
> finds it necessary so the real-time performance of the Xenomai task
> (thread?) might be even better then kernel driver. Am I wrong with
> this assumption?
> 
> In addition, by any chances, maybe you have some figures to estimate
> the jitter values which might be realistic to achieve using
> driver-based approach you suggested? Would you expect these figures to
> be considerably better then what I was observing with Xenomai-based
> implementation?

Of course, Linux drivers may be preempted by Xenomai. I was talking
about a Xenomai driver, using the RTDM skin using for instance two
timers, a periodic timer which handler would set the gpio to 1 and
launch the second timer, a one shot time which handler would set the
gpio to 0.

To estimate the jitter of code executed in the timer handler, use
latency -t 2. Note that for latency -t 2 to work, you need to enable the
corresponding driver in the kernel configuration (Real-time
sub-system/drivers/testing/timer benchmark driver).

Regards.

-- 
                                                                Gilles.

Re: [Xenomai-help] PWM generation with GPIO

[Bob Feretich]

Is there a reason that your not using the BeagleBoard PWM Timer hardware?
The OMAP3 ARM chip has 4 PWM hardware timers. They can generate rock 
solid PWM pulse trains via the DMTIMER interface. The BeagleBoard 
C2/C3/C4 brings out 3 of these timers to the expansion connector.

Writing a RTDM driver to manipulate these timers is easy.
I needed 4 PWM timer outputs, brought to the expansion connector. So I 
wrote a RTDM driver to use the three that were pinned out,  and used 
real time limit and overflow interrupts to to wiggle a GPIO for the 
fourth PWM output.

The Linux version of this driver made the 4th servomotor growl. There is 
no growl using the RTDM version. I asked a lab technician to probe the 
four servo PWM signals and tell me which was software GPIO generated. He 
could not tell.

The RTDM driver is open source. If you want it contact me off list and 
I'll send you the source.
Before you contact me for questions about the driver though...
1) Know how to build a standard Linux driver.
2) Read the OMAP technical reference manual 
(http://www.ti.com/lit/ug/spruf98t/spruf98t.pdf) sections on the Timers 
(Chapter 16).

Regards,
Bob Feretich

> From: Andrey Nechypurenko<andreynech@domain.hid>
> Subject: [Xenomai-help] PWM generation with GPIO
> To: Xenomai help<xenomai@xenomai.org>
> Message-ID:
> 	<CAOiXNkC=KgmuRFxNiGOqSGChpFQdv+fYRu8OgU0jMQc_dudShA@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Folks,
>
> Recently I was trying to control standard servo motor with PWMs. The
> system is 600MHz BeagleBoard xM (ARM) running Linux kernel version
> 2.6.35.9 with Xenomai version 2.5.6.
>
> Pulses needs to be generated with 20milliseconds interval (50Hz).
> Pulse width defines servo position and is typically in the range of
> 0.8milliseconds to 2.0milliseconds. To generate PWMs I am using GPIO
> pin connected to the servo through TI's TXS0108E voltage-level
> translator to translate +1.8V GPIO to required +5V. To trigger GPIO
> state I am using direct memory writes (to mmapped area).
>
> The generation loop is running in the Xenomai thread with priority 99
> and looks like this:
>
>    for(;;) {
>        //set_data_out has offset 0x94
>        gpio[OFFSET(0x6094)]=0x40000000;
>        rt_task_sleep(up_period);
>        //clear_data_out has offset 0x90
>        gpio[OFFSET(0x6090)]=0x40000000;
>        rt_task_wait_period(NULL); }
>
> where gpio array is a pointer to the memory area responsible for
> controlling GPIO state. The complete code could be found here:
> https://www.gitorious.org/veter/vehicle/blobs/master/src/xenopwm.c
>
> So now the question/problem I have. If the system load is low, then
> everything is fine. However, if the system load goes beyound ~60%,
> servos starts shaking which is a sign of not precise PWM timing. I
> have written the blog post with more details and relevant videos:
> http://veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html
> . Just scroll down to the section named "Solution 2 - predictable
> timing with Xenomai" since the rest is probably obvious for the folks
> hanging around here  .
>
> Running the Xenomai's latency application in parallel with our test
> program reveals the latency of around 40 microseconds. Based on what I
> read in Internet, 40 microseconds is considered "normal/OK" latency
> for Linux/Xenomai running on ARM at 600MHz. Taking in account typical
> pulse width of about 1 millisecond, 40 microseconds is about 4%. Could
> it be that this 4% is in fact what causes servos to shake? If yes,
> does it mean that even with Xenomai it is not possible to control
> servos reliably even under moderate system load on the mentioned
> hardware?
>
> I am kind of hope that there are some tweeks could be done to make the
> timing more precise and would really appreciate any hints.
>
> Thank you,
> Andrey.
>

Re: [Xenomai-help] PWM generation with GPIO

[Andrey Nechypurenko]

On 8 September 2011 04:03, Bob Feretich <bob.feretich@domain.hid> wrote:
> Is there a reason that your not using the BeagleBoard PWM Timer hardware?

I do use two of them. Attempt to generate PWM using GPIO is just for
me to learn about real-time performance I can achieve with Xenomai. My
hope that later, in addition to PWMs, using the same approach I would
be able to handle another real-time tasks required for my hobby
robotics project (veter-project.blogspot.com just in case if you are
curious).

> So I wrote
> a RTDM driver to use the three that were pinned out,  and used real time
> limit and overflow interrupts to to wiggle a GPIO for the fourth PWM output.

It seams to me that you are using different implementation approach
then suggested by Gilles in this thread: "I was talking
about a Xenomai driver, using the RTDM skin using for instance two
timers, a periodic timer which handler would set the gpio to 1 and
launch the second timer, a one shot time which handler would set the
gpio to 0."

Could you please say a few words about the reasons why you chose this
particular way?

> The Linux version of this driver made the 4th servomotor growl. There is no
> growl using the RTDM version. I asked a lab technician to probe the four
> servo PWM signals and tell me which was software GPIO generated. He could
> not tell.

It is not a surprise that Linux version was not perfect. What was
surprising for me is the fact that my user-space Xenomai application
was also not very precise (the relevant source is here:
https://www.gitorious.org/veter/vehicle/blobs/master/src/xenopwm.c and
the periodic function is pwm_func()). Similarly to what Gilles
suggested but in user-space, I run periodic task and toggle the pin
with direct memory writes. My understanding was that periodic task
(despite being launched in user-space) is controlled by Xenomai which
in turns works with system timers and should deliver much more precise
timing. So there might be fundamental difference between periodic task
launched in user-space with rt_task_start/rt_task_set_periodic and
similar periodic task running as RTDM driver which I do not
understand. If this assumption is true, I would really appreciate any
pointers to the documentation which explains what are the differences
and why RTDM driver can deliver better rt performance then Xenomai
thread from user-space.

> The RTDM driver is open source. If you want it contact me off list and I'll
> send you the source.

Will definitely contact you. I just start to write my own RTDM driver
for it and still want to do it myself to learn. But it would a big
help for me to have working "reference" implementation.

> Before you contact me for questions about the driver though...
> 1) Know how to build a standard Linux driver.
> 2) Read the OMAP technical reference manual
> (http://www.ti.com/lit/ug/spruf98t/spruf98t.pdf) sections on the Timers
> (Chapter 16).

Ok. ;-)

Regards,
Andrey.

Re: [Xenomai-help] PWM generation with GPIO

[Gilles Chanteperdrix]

On 09/08/2011 10:21 AM, Andrey Nechypurenko wrote:
>> So I wrote
>> a RTDM driver to use the three that were pinned out,  and used real time
>> limit and overflow interrupts to to wiggle a GPIO for the fourth PWM output.
> 
> It seams to me that you are using different implementation approach
> then suggested by Gilles in this thread: "I was talking
> about a Xenomai driver, using the RTDM skin using for instance two
> timers, a periodic timer which handler would set the gpio to 1 and
> launch the second timer, a one shot time which handler would set the
> gpio to 0."

If I understand correctly, the difference is that Bob proposes you to
dedicate a hardware timer to the PWM, whereas I propose you to use the
software timers, which ultimately, also depend on a dmtimer. I would not
expect big differences between the two approaches, neither in terms of
jitter, nor in terms of code.

> 
> Could you please say a few words about the reasons why you chose this
> particular way?
> 
>> The Linux version of this driver made the 4th servomotor growl. There is no
>> growl using the RTDM version. I asked a lab technician to probe the four
>> servo PWM signals and tell me which was software GPIO generated. He could
>> not tell.
> 
> timing. So there might be fundamental difference between periodic task
> launched in user-space with rt_task_start/rt_task_set_periodic and
> similar periodic task running as RTDM driver which I do not
> understand. If this assumption is true, I would really appreciate any
> pointers to the documentation which explains what are the differences
> and why RTDM driver can deliver better rt performance then Xenomai
> thread from user-space.

As suggested in the previous mail I sent you, compare the differences in
latencies with latency -t 2 between user-space task and kernel-space
timer. You will see that a timer handler has much less jitter. Switch to
user-space, and context switch time explain the difference.

-- 
					    Gilles.

Re: [Xenomai-help] PWM generation with GPIO

[Gilles Chanteperdrix]

On 09/08/2011 11:30 AM, Andrey Nechypurenko wrote:
>> If I understand correctly, the difference is that Bob proposes you to
>> dedicate a hardware timer to the PWM, whereas I propose you to use the
>> software timers, which ultimately, also depend on a dmtimer. I would not
>> expect big differences between the two approaches, neither in terms of
>> jitter, nor in terms of code.
> 
> I see. Thanks for the explanations.
> 
>> As suggested in the previous mail I sent you, compare the differences in
>> latencies with latency -t 2 between user-space task and kernel-space
>> timer. You will see that a timer handler has much less jitter.
> 
> It is clear for me that there is a difference. I am trying to
> understand what is the reason for the difference. I thought that as
> soon as Xenomai task is created (does not matter from user or kernel
> space) it is managed by Xenomai in the similar way and correspondingly
> the results should be also similar (which is obviously no the case).

xenomai provides user-space threads and kernel-space threads, which work
much like linux user-space and kernel-space threads.

> 
>> Switch to user-space, and context switch time explain the difference.
> 
> So is it the only reason for the differences or there are some other
> factors influencing the results?

It is the only reason.

With latency -t 2. As soon as the timer interrupt happens, the timer
handler, which runs in irq context, measures the jitter.

With latency -t 0. When the timer interrupt happens, we need to switch
to the kernel-space task associated with the user-space sampling task,
in the worst case, the currently running task was not in the same memory
space, so, a switch of the mmu context is needed. Then we need to return
to user-space, as a return to the "rt_task_wait_period" syscall at which
point the jitter is measured.

All this involves longer code paths and greater opportunities for cache
effects.

This difference between kernel-space and user-space explains why we
advise people to split their application between application and driver,
the really critical part using the RTDM skin, in kernel-space, much like
you would do with linux.

-- 
					    Gilles.

Re: [Xenomai-help] PWM generation with GPIO

[Philippe Gerum]

On Thu, 2011-09-08 at 12:06 +0200, Gilles Chanteperdrix wrote:
> On 09/08/2011 11:30 AM, Andrey Nechypurenko wrote:
> >> If I understand correctly, the difference is that Bob proposes you to
> >> dedicate a hardware timer to the PWM, whereas I propose you to use the
> >> software timers, which ultimately, also depend on a dmtimer. I would not
> >> expect big differences between the two approaches, neither in terms of
> >> jitter, nor in terms of code.
> > 
> > I see. Thanks for the explanations.
> > 
> >> As suggested in the previous mail I sent you, compare the differences in
> >> latencies with latency -t 2 between user-space task and kernel-space
> >> timer. You will see that a timer handler has much less jitter.
> > 
> > It is clear for me that there is a difference. I am trying to
> > understand what is the reason for the difference. I thought that as
> > soon as Xenomai task is created (does not matter from user or kernel
> > space) it is managed by Xenomai in the similar way and correspondingly
> > the results should be also similar (which is obviously no the case).
> 
> xenomai provides user-space threads and kernel-space threads, which work
> much like linux user-space and kernel-space threads.
> 
> > 
> >> Switch to user-space, and context switch time explain the difference.
> > 
> > So is it the only reason for the differences or there are some other
> > factors influencing the results?
> 
> It is the only reason.
> 
> With latency -t 2. As soon as the timer interrupt happens, the timer
> handler, which runs in irq context, measures the jitter.
> 
> With latency -t 0. When the timer interrupt happens, we need to switch
> to the kernel-space task associated with the user-space sampling task,
                      ^^^
You meant stack, I guess.

> in the worst case, the currently running task was not in the same memory
> space, so, a switch of the mmu context is needed. Then we need to return
> to user-space, as a return to the "rt_task_wait_period" syscall at which
> point the jitter is measured.

Add to this the opportunity for a real-time IRQ to preempt the task on
its way back to userland, delaying the measurement from the time spent
to run the ISR (at the very least).

> 
> All this involves longer code paths and greater opportunities for cache
> effects.
> 
> This difference between kernel-space and user-space explains why we
> advise people to split their application between application and driver,
> the really critical part using the RTDM skin, in kernel-space, much like
> you would do with linux.
> 

-- 
Philippe.

Re: [Xenomai-help] PWM generation with GPIO

[Bob Feretich]

The advantage of using a hardware PWM timer (like OMAP3 GPTimer8-11) is 
that there is no interrupt load on the system.
(The PWM signals are completely generated by the hardware.)

PWM outputs controlled by interrupts require one interrupt for each edge 
transition of the output signal.

The disadvantage of using a hardware PWM timer is that there are only 4 
PWM timers on the OMAP3 chip (3 accessible on the BeagleBoard). Once you 
have used all 4, than you must use the method Gilles describes.

Regards,
Bob Feretich

On 9/8/2011 2:13 AM, Gilles Chanteperdrix wrote:
> On 09/08/2011 10:21 AM, Andrey Nechypurenko wrote:
>>> So I wrote
>>> a RTDM driver to use the three that were pinned out,  and used real time
>>> limit and overflow interrupts to to wiggle a GPIO for the fourth PWM output.
>> It seams to me that you are using different implementation approach
>> then suggested by Gilles in this thread: "I was talking
>> about a Xenomai driver, using the RTDM skin using for instance two
>> timers, a periodic timer which handler would set the gpio to 1 and
>> launch the second timer, a one shot time which handler would set the
>> gpio to 0."
> If I understand correctly, the difference is that Bob proposes you to
> dedicate a hardware timer to the PWM, whereas I propose you to use the
> software timers, which ultimately, also depend on a dmtimer. I would not
> expect big differences between the two approaches, neither in terms of
> jitter, nor in terms of code.
>
>> Could you please say a few words about the reasons why you chose this
>> particular way?
>>
>>> The Linux version of this driver made the 4th servomotor growl. There is no
>>> growl using the RTDM version. I asked a lab technician to probe the four
>>> servo PWM signals and tell me which was software GPIO generated. He could
>>> not tell.
>> timing. So there might be fundamental difference between periodic task
>> launched in user-space with rt_task_start/rt_task_set_periodic and
>> similar periodic task running as RTDM driver which I do not
>> understand. If this assumption is true, I would really appreciate any
>> pointers to the documentation which explains what are the differences
>> and why RTDM driver can deliver better rt performance then Xenomai
>> thread from user-space.
> As suggested in the previous mail I sent you, compare the differences in
> latencies with latency -t 2 between user-space task and kernel-space
> timer. You will see that a timer handler has much less jitter. Switch to
> user-space, and context switch time explain the difference.
>

Re: [Xenomai-help] PWM generation with GPIO

[Gilles Chanteperdrix]

On 09/09/2011 05:33 AM, Bob Feretich wrote:
> The advantage of using a hardware PWM timer (like OMAP3 GPTimer8-11) is 
> that there is no interrupt load on the system.
> (The PWM signals are completely generated by the hardware.)

And you get no jitter.

-- 
                                                                Gilles.