[Xenomai] Using hardware PWM generators with Xenomai

[Xenomai] Using hardware PWM generators with Xenomai

[Sagar Behere]

Hello,

I wish to generate PWM signals from Xenomai, using the beaglebone black, 
kernel 3.8.13 patched with xenomai.

There already exist linux kernel modules for the hardware PWM generator 
(eHRPWM) on the am335x chip in the beaglebone. The PWM generator can be 
configured and controlled via the /sysfs interface and the whole thing 
works very well.

I understand that the /sysfs interface cannot be used by xenomai tasks 
without triggering a transition away from the primary xenomai (hard 
realtime) domain. So my question is: What is the least effort way to 
change the duty cycle of the hardware PWM generator, from a xenomai task?

Does the following approach sound feasible?

1. Configure the PWM generator (freq, polarity etc.) from the /sysfs 
interface at application startup. This need not be realtime
2. Assuming that the duty-cycle is controlled by the value of some 
memory-mapped register, use mmap()/ioremap() to map that register's 
address into the xenomai task's address space.
3. Write the duty-cycle values to the mapped memory, from within the 
xenomai task

So this is like a hybrid approach that uses the existing linux kernel 
module for initializing/configuring the hardware PWM and the xenomai 
task only changes the value of one register that affects the duty cycle 
of the output waveform.

Thanks in advance,
Sagar

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Lennart Sorensen]

On Thu, Aug 08, 2013 at 03:36:03PM +0200, Sagar Behere wrote:
> I wish to generate PWM signals from Xenomai, using the beaglebone
> black, kernel 3.8.13 patched with xenomai.
> 
> There already exist linux kernel modules for the hardware PWM
> generator (eHRPWM) on the am335x chip in the beaglebone. The PWM
> generator can be configured and controlled via the /sysfs interface
> and the whole thing works very well.
> 
> I understand that the /sysfs interface cannot be used by xenomai
> tasks without triggering a transition away from the primary xenomai
> (hard realtime) domain. So my question is: What is the least effort
> way to change the duty cycle of the hardware PWM generator, from a
> xenomai task?
> 
> Does the following approach sound feasible?
> 
> 1. Configure the PWM generator (freq, polarity etc.) from the /sysfs
> interface at application startup. This need not be realtime
> 2. Assuming that the duty-cycle is controlled by the value of some
> memory-mapped register, use mmap()/ioremap() to map that register's
> address into the xenomai task's address space.
> 3. Write the duty-cycle values to the mapped memory, from within the
> xenomai task
> 
> So this is like a hybrid approach that uses the existing linux
> kernel module for initializing/configuring the hardware PWM and the
> xenomai task only changes the value of one register that affects the
> duty cycle of the output waveform.

I know it isn't what you asked for, but would using one of the PRUs
be simpler?  Maybe that wouldn't work.

-- 
Len Sorensen

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Michael Haberler]

Sagar,

you might want to study the LinuxCNC code, which does PWM - among other functions like a stepper generator - via the PRU

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=src/hal/drivers/hal_pru_generic;h=5e7dc56c1891408833362fd7f480a9da20dcc31d;hb=refs/heads/unified-build-candidate-1

- Michael
Am 08.08.2013 um 15:36 schrieb Sagar Behere <sagar.behere@gmail.com>:

> Hello,
> 
> I wish to generate PWM signals from Xenomai, using the beaglebone black, kernel 3.8.13 patched with xenomai.
> 
> There already exist linux kernel modules for the hardware PWM generator (eHRPWM) on the am335x chip in the beaglebone. The PWM generator can be configured and controlled via the /sysfs interface and the whole thing works very well.
> 
> I understand that the /sysfs interface cannot be used by xenomai tasks without triggering a transition away from the primary xenomai (hard realtime) domain. So my question is: What is the least effort way to change the duty cycle of the hardware PWM generator, from a xenomai task?
> 
> Does the following approach sound feasible?
> 
> 1. Configure the PWM generator (freq, polarity etc.) from the /sysfs interface at application startup. This need not be realtime
> 2. Assuming that the duty-cycle is controlled by the value of some memory-mapped register, use mmap()/ioremap() to map that register's address into the xenomai task's address space.
> 3. Write the duty-cycle values to the mapped memory, from within the xenomai task
> 
> So this is like a hybrid approach that uses the existing linux kernel module for initializing/configuring the hardware PWM and the xenomai task only changes the value of one register that affects the duty cycle of the output waveform.
> 
> Thanks in advance,
> Sagar
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Robert]

I wrote this driver recently, and it generates stable pwm signal. Probably you will have to adapt it to beaglebone black.
It is written for Pandaboard and its hardware general purpose timer.
There are some ioctl interfaces for user space.

https://github.com/rkmiec/pandaboard-pwm-rtdm/tree/dc_engine

Do NOT use master branch now.

Dnia 8 sierpnia 2013 16:26 Michael Haberler <mail17@mah.priv.at> napisał(a):

> Sagar,
> 
> you might want to study the LinuxCNC code, which does PWM - among other functions like a stepper generator - via the PRU
> 
> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=src/hal/drivers/hal_pru_generic;h=5e7dc56c1891408833362fd7f480a9da20dcc31d;hb=refs/heads/unified-build-candidate-1
> 
> - Michael
> Am 08.08.2013 um 15:36 schrieb Sagar Behere <sagar.behere@gmail.com>:
> 
> > Hello,
> > 
> > I wish to generate PWM signals from Xenomai, using the beaglebone black, kernel 3.8.13 patched with xenomai.
> > 
> > There already exist linux kernel modules for the hardware PWM generator (eHRPWM) on the am335x chip in the beaglebone. The PWM generator can be configured and controlled via the /sysfs interface and the whole thing works very well.
> > 
> > I understand that the /sysfs interface cannot be used by xenomai tasks without triggering a transition away from the primary xenomai (hard realtime) domain. So my question is: What is the least effort way to change the duty cycle of the hardware PWM generator, from a xenomai task?
> > 
> > Does the following approach sound feasible?
> > 
> > 1. Configure the PWM generator (freq, polarity etc.) from the /sysfs interface at application startup. This need not be realtime
> > 2. Assuming that the duty-cycle is controlled by the value of some memory-mapped register, use mmap()/ioremap() to map that register's address into the xenomai task's address space.
> > 3. Write the duty-cycle values to the mapped memory, from within the xenomai task
> > 
> > So this is like a hybrid approach that uses the existing linux kernel module for initializing/configuring the hardware PWM and the xenomai task only changes the value of one register that affects the duty cycle of the output waveform.
> > 
> > Thanks in advance,
> > Sagar
> > 
> > _______________________________________________
> > Xenomai mailing list
> > Xenomai@xenomai.org
> > http://www.xenomai.org/mailman/listinfo/xenomai
> 
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
> 

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Sagar Behere]

(top posting, because confused how to bottom post in response to two top 
posts)

Thanks for your suggestions, people. I'll go through your code and learn 
from it.

One thing though: All the suggestions in the responses (and others I've 
seen on mailing list history) toggle the GPIO pins to generate the PWM 
signal. Why do this if there is a perfectly good PWM generation hardware 
on the chip? (like the am33xx has the eHRPWM generator). Me, I'd go for 
the gpio route only if the onboard PWM generation hardware does not 
provide sufficient number of PWMs. Or, is there some problem with the 
onboard PWM hardware that I am not aware of?

For my application, I only need 2 pwms, and the onboard eHRPWM module 
provides 3, so I prefer to use this module.

Thanks and regards,
Sagar

On 08/09/2013 07:28 PM, Robert wrote:
> I wrote this driver recently, and it generates stable pwm signal. Probably you will have to adapt it to beaglebone black.
> It is written for Pandaboard and its hardware general purpose timer.
> There are some ioctl interfaces for user space.
>
> https://github.com/rkmiec/pandaboard-pwm-rtdm/tree/dc_engine
>
> Do NOT use master branch now.
>
> Dnia 8 sierpnia 2013 16:26 Michael Haberler <mail17@mah.priv.at> napisał(a):
>
>> Sagar,
>>
>> you might want to study the LinuxCNC code, which does PWM - among other functions like a stepper generator - via the PRU
>>
>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=src/hal/drivers/hal_pru_generic;h=5e7dc56c1891408833362fd7f480a9da20dcc31d;hb=refs/heads/unified-build-candidate-1
>>
>> - Michael
>> Am 08.08.2013 um 15:36 schrieb Sagar Behere <sagar.behere@gmail.com>:
>>
>>> Hello,
>>>
>>> I wish to generate PWM signals from Xenomai, using the beaglebone black, kernel 3.8.13 patched with xenomai.
>>>
>>> There already exist linux kernel modules for the hardware PWM generator (eHRPWM) on the am335x chip in the beaglebone. The PWM generator can be configured and controlled via the /sysfs interface and the whole thing works very well.
>>>
>>> I understand that the /sysfs interface cannot be used by xenomai tasks without triggering a transition away from the primary xenomai (hard realtime) domain. So my question is: What is the least effort way to change the duty cycle of the hardware PWM generator, from a xenomai task?
>>>
>>> Does the following approach sound feasible?
>>>
>>> 1. Configure the PWM generator (freq, polarity etc.) from the /sysfs interface at application startup. This need not be realtime
>>> 2. Assuming that the duty-cycle is controlled by the value of some memory-mapped register, use mmap()/ioremap() to map that register's address into the xenomai task's address space.
>>> 3. Write the duty-cycle values to the mapped memory, from within the xenomai task
>>>
>>> So this is like a hybrid approach that uses the existing linux kernel module for initializing/configuring the hardware PWM and the xenomai task only changes the value of one register that affects the duty cycle of the output waveform.
>>>
>>> Thanks in advance,
>>> Sagar
>>>
>>> _______________________________________________
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Andrey Nechypurenko]

> Me, I'd go for the gpio route only if the onboard PWM
> generation hardware does not provide sufficient number of PWMs.

This is the typical reason for it. At least it was the case in our
project - 3 was not enough.

Regards,
Andrey.

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Robert]

I have decided to push it here, since it was private message:

Dnia 10 sierpnia 2013 11:44 Sagar Behere <sagar.behere@gmail.com> napisał(a):

> On 08/09/2013 07:28 PM, Robert wrote:
> > I wrote this driver recently, and it generates stable pwm signal. Probably you will have to adapt it to beaglebone black.
> > It is written for Pandaboard and its hardware general purpose timer.
> > There are some ioctl interfaces for user space.
> >
> > https://github.com/rkmiec/pandaboard-pwm-rtdm/tree/dc_engine
> >
> > Do NOT use master branch now.
> 
> Hello Robert,
> 
> Quick question about your pandaboard-pwm-rtdm.
> 
> I see in pwm.c (dc_engine branch), lines 125 and 127, that you use 
> gpio_set_value() to set the level of the gpio pin. This function comes 
> from #include <linux/gpio.h>, which is a standard linux driver, I guess. 
> So every time you call this function, you are making a linux kernel 
> call.. won't that trigger a transition away from xenomai's primary 
> domain? i.e., you task won't be hard realtime anymore..
> 
> I haven't understood xenomai completely, so it is possible that my 
> reasoning is wrong. Could you clarify?
> 
> Thanks and regards,
> Sagar
> 



I'm learning it too.
gpio_set_value() could be called from any context (comments in
drivers/gpio/gpiolib.c), so it shouldn't sleep.
On osciloscope this signal looks very stable. Also servo connected to this
signal is not shaking.


And why I'm toggling gpio:
On pandaboard, hardware outputs from those timers are connected to HDMI
outuput, camera, display (for backlight) etc.
None of them is available on expansion connector. That is why I'm toggling
gpios.

My program differs a little from Andrey.
I'm using hardware interrupts from timers to change value on gpio pin and
he was using rtdm_sleep*() (as far as I remember).

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Gilles Chanteperdrix]

On 08/10/2013 02:29 PM, Robert wrote:
> I have decided to push it here, since it was private message:
> 
> Dnia 10 sierpnia 2013 11:44 Sagar Behere <sagar.behere@gmail.com> napisał(a):
> 
>> On 08/09/2013 07:28 PM, Robert wrote:
>>> I wrote this driver recently, and it generates stable pwm signal. Probably you will have to adapt it to beaglebone black.
>>> It is written for Pandaboard and its hardware general purpose timer.
>>> There are some ioctl interfaces for user space.
>>>
>>> https://github.com/rkmiec/pandaboard-pwm-rtdm/tree/dc_engine
>>>
>>> Do NOT use master branch now.
>>
>> Hello Robert,
>>
>> Quick question about your pandaboard-pwm-rtdm.
>>
>> I see in pwm.c (dc_engine branch), lines 125 and 127, that you use 
>> gpio_set_value() to set the level of the gpio pin. This function comes 
>> from #include <linux/gpio.h>, which is a standard linux driver, I guess. 
>> So every time you call this function, you are making a linux kernel 
>> call.. won't that trigger a transition away from xenomai's primary 
>> domain? i.e., you task won't be hard realtime anymore..
>>
>> I haven't understood xenomai completely, so it is possible that my 
>> reasoning is wrong. Could you clarify?
>>
>> Thanks and regards,
>> Sagar
>>
> 
> 
> 
> I'm learning it too.
> gpio_set_value() could be called from any context (comments in
> drivers/gpio/gpiolib.c), so it shouldn't sleep.
> On osciloscope this signal looks very stable. Also servo connected to this
> signal is not shaking.
> 
> 
> And why I'm toggling gpio:
> On pandaboard, hardware outputs from those timers are connected to HDMI
> outuput, camera, display (for backlight) etc.
> None of them is available on expansion connector. That is why I'm toggling
> gpios.
> 
> My program differs a little from Andrey.
> I'm using hardware interrupts from timers to change value on gpio pin and
> he was using rtdm_sleep*() (as far as I remember).

gpio_set_value is only safe to be called from Xenomai context if care
has been taken in the I-pipe patch, as described here:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#GPIOs_in_real-time_drivers

Calling a Linux service from real-time context in kernel-space never
results in a switch to secondary mode.

If the service can be called from real-time context, namely if it does
not rely on a Linux kernel coherent state (as is the case for instance
for memcpy), or if special care has been taken to make this service
callable from primary mode (as should be the case of gpio_get/set_value
for supported ARM platforms), it can be called.

Otherwise if you are lucky, it may call BUG_ON/WARN_ON if you enabled
CONFIG_IPIPE_DEBUG_CONTEXT, and if you are unlucky, it will sometime
work, and sometime cause random crashes.

But it never will cause the thread to transition to secondary mode. Only
system calls, called by user-space threads do that.

-- 
                                                                Gilles.

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Gilles Chanteperdrix]

On 08/10/2013 02:42 PM, Gilles Chanteperdrix wrote:
> But it never will cause the thread to transition to secondary mode. Only
> system calls, called by user-space threads do that.

And some exceptional conditions like Linux signals and page faults.

-- 
                                                                Gilles.

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Andrey Nechypurenko]

> My program differs a little from Andrey.
> I'm using hardware interrupts from timers to change value on gpio pin and
> he was using rtdm_sleep*() (as far as I remember).

Right. We started with thread-based approach (task/sleep) but results
were not good enough and we switch to timer-based implementation. If
you are interested, here is the corresponding source code:
https://github.com/andreynech/rtdm-pwm/ . In particular, you can take
a look at this file:
https://github.com/andreynech/rtdm-pwm/blob/master/pwm-task-proc.c

Regards,
Andrey.

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Andrey Nechypurenko]

On 10 August 2013 17:14, Andrey Nechypurenko <andreynech@googlemail.com> wrote:
>> My program differs a little from Andrey.
>> I'm using hardware interrupts from timers to change value on gpio pin and
>> he was using rtdm_sleep*() (as far as I remember).
>
> Right. We started with thread-based approach (task/sleep) but results
> were not good enough and we switch to timer-based implementation. If
> you are interested, here is the corresponding source code:
> https://github.com/andreynech/rtdm-pwm/ . In particular, you can take
> a look at this file:
> https://github.com/andreynech/rtdm-pwm/blob/master/pwm-task-proc.c

Forget to say - this example uses direct memory access to toggle pins.
This one here:
https://github.com/veter-team/tb6612fng/blob/master/pwm-task-proc.c is
rewritten with gpio_set_value & co.

Re: [Xenomai] Using hardware PWM generators with Xenomai

[Gilles Chanteperdrix]

On 08/08/2013 03:36 PM, Sagar Behere wrote:
> Hello,
> 
> I wish to generate PWM signals from Xenomai, using the beaglebone black, 
> kernel 3.8.13 patched with xenomai.
> 
> There already exist linux kernel modules for the hardware PWM generator 
> (eHRPWM) on the am335x chip in the beaglebone. The PWM generator can be 
> configured and controlled via the /sysfs interface and the whole thing 
> works very well.
> 
> I understand that the /sysfs interface cannot be used by xenomai tasks 
> without triggering a transition away from the primary xenomai (hard 
> realtime) domain. So my question is: What is the least effort way to 
> change the duty cycle of the hardware PWM generator, from a xenomai task?
> 
> Does the following approach sound feasible?
> 
> 1. Configure the PWM generator (freq, polarity etc.) from the /sysfs 
> interface at application startup. This need not be realtime
> 2. Assuming that the duty-cycle is controlled by the value of some 
> memory-mapped register, use mmap()/ioremap() to map that register's 
> address into the xenomai task's address space.
> 3. Write the duty-cycle values to the mapped memory, from within the 
> xenomai task
> 
> So this is like a hybrid approach that uses the existing linux kernel 
> module for initializing/configuring the hardware PWM and the xenomai 
> task only changes the value of one register that affects the duty cycle 
> of the output waveform.
> 
> Thanks in advance,

It could probably work, but does not seem like a good idea:
- it is not future proof, as you will need to change the application
code if one day you want to run the application with different hardware,
an RTDM driver with a well defined interface would avoid that;
- it is not really safe as it does not prevent several applications to
access the same hardware at the same time.

Regards.

-- 
                                                                Gilles.