[Xenomai-help] PWM generation with GPIO
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)]=0x4000;
rt_task_sleep(up_period);
//clear_data_out has offset 0x90
gpio[OFFSET(0x6090)]=0x4000;
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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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)]=0x4000;
> rt_task_sleep(up_period);
> //clear_data_out has offset 0x90
> gpio[OFFSET(0x6090)]=0x4000;
> 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@gna.org
> https://mail.gna.org/listinfo/xenomai-help
>
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
> 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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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
Subject: [Xenomai-help] PWM generation with GPIO
To: Xenomai help
Message-ID:
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)]=0x4000;
rt_task_sleep(up_period);
//clear_data_out has offset 0x90
gpio[OFFSET(0x6090)]=0x4000;
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.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
On 8 September 2011 04:03, Bob Feretich 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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
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. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
