Driver for hardware PWM in BeagleBone Black (EHRPWM or EPWM)?

[Marius Alksnys]

I  accidentally found 'ehrpwm' mentioned in

machinekit/configs/ARM/BeagleBone/BeBoPr++/cape-bebopr-brdg-R3.dts

I am controlling servo motors with BeagleBone Black using eqep and pru PWM, but hardware PWM would be better.

Is there any progress made in this direction?

[Michael Haberler]

> Am 14.09.2015 um 21:53 schrieb Marius Alksnys <marius....@gmail.com>:
>
> I accidentally found 'ehrpwm' mentioned in
> machinekit/configs/ARM/BeagleBone/BeBoPr++/cape-bebopr-brdg-R3.dts
>
> I am controlling servo motors with BeagleBone Black using eqep and pru PWM, but hardware PWM would be better.

for which value of 'better' - which issue did you find? if there are any, please post an issue to the tracker so it is not forgotten

note the PRU PWM runs at a _much_ higher rate than the legacy soft pwmgen

that said: anytime you use a builtin device like eHRPWM, you need to consider:

- how many of those do I get (http://www.ti.com/lit/ds/sprs717h/sprs717h.pdf says: 3 - not that much)
- are the relevant pins actually available on the BB
- if you use them, are there any other pins you have to trade them off against and what is the impact of that

you typically do not face those tradeoffs with a PRU-implemented device, or at least to a lesser degree

(example: the eQEP encoder is great, but you have to trade off HDMI against eQEP, and maximum is 3 instances)

> Is there any progress made in this direction?

not that I'm aware of

I would not put _my_ time into it given the limited upside but optimality considerations vary


>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

[Marius Alksnys]

I want more granularity at higher PWM frequencies like 20 kHz. When using only P term and small P value, I could notice PWM steps by turning the motor by hand.

I have not made a complete investigation why, but with PRU PWM I get glitches sometimes. In standstill sometimes motor receives a spike large enough to move the motor out of position and PIDs trying to compensate it later on. I just noticed that some PRU periods work better than others.

Knowing the limits of PRU PWM would be strong base to decide ehrpwm.

HDMI is not so important when we have QtQuickVCP. I would even add that currently QtQuickVCP does not work in BBB directly AFAIK.

I designed and am testing BBB cape for three encoders and three PWM or analog outputs (complete isolation, digital inputs and outputs and unisolated analog inputs too), which could benefit from high quality PWM signals. I am planning to share more about this cape. I think it might be interesting for others.

2015 m. rugsėjis 15 d., antradienis 12:04:43 UTC+3, Michael Haberler rašė:

...

[Michael Haberler]

> Am 15.09.2015 um 13:39 schrieb Marius Alksnys <marius....@gmail.com>:
>
> I want more granularity at higher PWM frequencies like 20 kHz. When using only P term and small P value, I could notice PWM steps by turning the motor by hand.
> I have not made a complete investigation why, but with PRU PWM I get glitches sometimes.

well that really warrants an issue and a bit of investigation so as to make it reproducible

> In standstill sometimes motor receives a spike large enough to move the motor out of position and PIDs trying to compensate it later on. I just noticed that some PRU periods work better than others.

if you halscope this - is the spike also visible at the PWM input (i.e. comes from the servo PID), or is that 'out of the blue'?

>
> Knowing the limits of PRU PWM would be strong base to decide ehrpwm.
>
> HDMI is not so important when we have QtQuickVCP. I would even add that currently QtQuickVCP does not work in BBB directly AFAIK.
>
> I designed and am testing BBB cape for three encoders and three PWM or analog outputs (complete isolation, digital inputs and outputs and unisolated analog inputs too), which could benefit from high quality PWM signals. I am planning to share more about this cape. I think it might be interesting for others.

sounds interesting - so you plan to use the three eHRPWM's?

well if you are determined to do this, what I would do is:

- read up on eHRPWM in the the Sitara Technical Reference (http://static.mah.priv.at/public/spruh73* ; I guess Charles or Bas know which one of those is the best base)
- read the ehrpwm linux driver source to get the hang of it
- find source for any eHRPWM example codes you can find (for instance, the BBBiolib PWM example https://github.com/mhaberler/BBBIOlib/blob/master/Demo/Demo_PWM/PWM.c)
- try to get this working with a simple C program with direct register manipulation

Then have a look at the machinekit eQEP and gpio drivers, to learn how they do memory mapping and register fiddling, and adapt piecemeal, first setup, then the update function.

Also I suggest to contact Sagar Behere, an very competent fellow, see http://www.xenomai.org/pipermail/xenomai/2013-August/028999.html; maybe he got it to work

Warning: it could be you wil have to choose between eHRPWM1 OR eQEP1 .

>
>
> 2015 m. rugsėjis 15 d., antradienis 12:04:43 UTC+3, Michael Haberler rašė:
> ...
> for which value of 'better' - which issue did you find? if there are any, please post an issue to the tracker so it is not forgotten
>
> note the PRU PWM runs at a _much_ higher rate than the legacy soft pwmgen
>
> that said: anytime you use a builtin device like eHRPWM, you need to consider:
>
> - how many of those do I get (http://www.ti.com/lit/ds/sprs717h/sprs717h.pdf says: 3 - not that much)
> - are the relevant pins actually available on the BB
> - if you use them, are there any other pins you have to trade them off against and what is the impact of that
>
> you typically do not face those tradeoffs with a PRU-implemented device, or at least to a lesser degree
>
> (example: the eQEP encoder is great, but you have to trade off HDMI against eQEP, and maximum is 3 instances)
>
> > Is there any progress made in this direction?
>
> not that I'm aware of
>
> I would not put _my_ time into it given the limited upside but optimality considerations vary
>

[Charles Steinkuehler]

On 9/15/2015 6:39 AM, Marius Alksnys wrote:
> I want more granularity at higher PWM frequencies like 20 kHz. When using
> only P term and small P value, I could notice PWM steps by turning the
> motor by hand.

Yes, the hardware PWM channels would work better than the PRU for
motor control, particularly closed-loop servo control. The PRU PWM
logic was intended primarily for low frequency heater control on a 3D
printer.

AFAIK, no one has yet written a hardware PWM driver for HAL, but the
existing eQEP driver should provide a decent starting point.

> I have not made a complete investigation why, but with PRU PWM I get
> glitches sometimes. In standstill sometimes motor receives a spike large
> enough to move the motor out of position and PIDs trying to compensate it
> later on. I just noticed that some PRU periods work better than others.

Hmm...there might be a corner case in the PRU code causing these
spikes. The question is if it's coming from the HAL system, or from
the PRU code itself. As Michael mentioned, you can use halscope to
monitor the PWM commanded value to see if the spike is being sent to
the PWM sub-system (if so, you've got some other problem with your HAL
setup or PID values). If not, it's probably a corner-case glitch in
the PRU code I never noticed (since it wouldn't affect a heating
element much). My first guess would be the output stays high for one
full PWM period...if you've got a decent 'scope you should be able to
trigger on pulse length and verify if this is actually what's happening.

> Knowing the limits of PRU PWM would be strong base to decide ehrpwm.

What frequency are you wanting to use for PWM. You mention 20 KHz,
above, which means maybe 50-100 steps for a traditional PWM
implementation using the PRU (500-1000 nS PRU period, which should
work if you're _only_ doing PWM with the PRU). A better option might
be to use delta-sigma modulation, but that's likely only viable if
you're converting the PWM to an analog signal prior to the motor drive
H-bridge. The delta-sigma output frequency would be too high (100 KHz
at the default "slow" 10 uS PRU period) to drive most FET bridges
directly without burning a *LOT* of energy in the transition region.

If you want to try delta-sigma modulation, the PRU code has been
written, but I didn't update the HAL side driver for it when I did a
major rewrite a while back. It should be pretty easy to get running
again if you think it will help.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Marius Alksnys]

Transistors are switched directly. Yes, beaglebone and machinekit closes the loop.

[Charles Steinkuehler]

On 9/15/2015 8:46 AM, Marius Alksnys wrote:
> Transistors are switched directly.

You can probably do OK using the PRU, but the hardware PWM will
definitely give you more resolution. If the main problem is the
spikes, it's possible there's a goof in the code that could improve
things a lot if fixed. If you can check that the proper commands are
going to the PWM driver via halscope and see if there's actually an
extra long (or short) PWM pulse generated, it would verify this is
what's happening.

I'd try to reproduce it here, but I don't have the hardware to do a
closed loop handy, and I suspect the bug (if present) is 'tickled' by
the servo hunting that happens when at rest (which is pretty hard to
replicate without real-world hardware).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Michael Haberler]

> Am 15.09.2015 um 13:59 schrieb Michael Haberler <mai...@mah.priv.at>:
>
>
>> Am 15.09.2015 um 13:39 schrieb Marius Alksnys <marius....@gmail.com>:
>>
>> I want more granularity at higher PWM frequencies like 20 kHz. When using only P term and small P value, I could notice PWM steps by turning the motor by hand.
>> I have not made a complete investigation why, but with PRU PWM I get glitches sometimes.
>
> well that really warrants an issue and a bit of investigation so as to make it reproducible
>
>> In standstill sometimes motor receives a spike large enough to move the motor out of position and PIDs trying to compensate it later on. I just noticed that some PRU periods work better than others.
>
> if you halscope this - is the spike also visible at the PWM input (i.e. comes from the servo PID), or is that 'out of the blue'?
>
>
>>
>> Knowing the limits of PRU PWM would be strong base to decide ehrpwm.
>>
>> HDMI is not so important when we have QtQuickVCP. I would even add that currently QtQuickVCP does not work in BBB directly AFAIK.
>>
>> I designed and am testing BBB cape for three encoders and three PWM or analog outputs (complete isolation, digital inputs and outputs and unisolated analog inputs too), which could benefit from high quality PWM signals. I am planning to share more about this cape. I think it might be interesting for others.
>
> sounds interesting - so you plan to use the three eHRPWM's?
>
> well if you are determined to do this, what I would do is:
>
> - read up on eHRPWM in the the Sitara Technical Reference (http://static.mah.priv.at/public/spruh73* ; I guess Charles or Bas know which one of those is the best base)
> - read the ehrpwm linux driver source to get the hang of it
> - find source for any eHRPWM example codes you can find (for instance, the BBBiolib PWM example https://github.com/mhaberler/BBBIOlib/blob/master/Demo/Demo_PWM/PWM.c)

looking over https://github.com/mhaberler/BBBIOlib/blob/master/BBBio_lib/BBBiolib_PWMSS.c I think this library could be used for heavy borrowing for a eHRPWM halcomp - I think it has all you need, just build and run the PWM demo

I worked with the authors to change their license and it is ok to reuse now; you will find them on the element14 blog:

http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/10/10/bbb--beaglebone-black-io-library-for-c?et=blogs.comment.created#comment-54418

[Marius Alksnys]

Quite some time passed, but now I ran across the same issue and caught it on scope. It is quite easy to get one by wiring sine or triangle siggen to pru pwmgen and watch pwm or filtered signal on scope.

Spikes like this occur quite often.

My cape for BeagleBone, named Furaday Cape, and its users would benefit from high quality PWM signal. I am just not up to writing PRU drivers on my own.

[Charles Steinkuehler]

On 12/11/2016 1:18 PM, Marius Alksnys wrote:
> <https://lh3.googleusercontent.com/-1CZT9VDaixc/WE2lvJMxr9I/AAAAAAAAWdM/wWu9VhkzQzUriDJTViM-OCImyc2ej_EPACLcB/s1600/bb_pru_pwm.jpg>

>
> Quite some time passed, but now I ran across the same issue and caught it on
> scope. It is quite easy to get one by wiring sine or triangle siggen to pru
> pwmgen and watch pwm or filtered signal on scope.
> Spikes like this occur quite often.

That looks very much like a bug in the PRU code or ARM side HAL
driver. Do you have an example HAL config you can share (or send me
direct) that causes this behavior?

> My cape for BeagleBone, named Furaday Cape, and its users would benefit from
> high quality PWM signal. I am just not up to writing PRU drivers on my own.

IIRC someone wrote a HAL driver for the hardware PWMs. If not, it
ought to be fairly straight-forward to implement. Anything using PWM
for something more than heater (or maybe spindle speed) control on the
BBB would likely benefit greatly from using hardware PWM.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Marius Alksnys]

This was a complete Furaday cape v1.2 setup template with temporary
POSTGUI_HALFILE = ao_test.hal
It should be started from run_servo.py
display is axis, but it should be flexible..

zip file attached

12/12/2016 11:48 PM, Charles Steinkuehler rašė:
...

[Charles Steinkuehler]

Thanks!

There's a lot to sort through, but it looks like the sine wave test
for the PRU PWM is pretty self-contained. So that I understand correctly:

* You see problems on the physical output pin, but *NOT* on anything
in halscope, correct?

* The behavior shown can happen when two or more devices are trying to
use the same GPIO pin. It looks like your HAL files are OK in this
regard (the PRU is driving P9.21, and the hal_bb_gpio driver is not),
but this can also happen if you try accessing the GPIO banks via
Linux. Is there any chance you're running something other than the
HAL drivers that is talking to the I/O pins? A write to any GPIO in
bank 0 via Linux would cause the behavior you are seeing.

I'll try to setup a test platform here and see if I can reproduce the
problem.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Marius Alksnys]

Charles,

Merry Christmas and happy New Year! :)

I believe a signal is perfect in halscope.

I didn't create any GPIO writers intentionally, but who knows.. How to
check for other writers?
Can't user LED's or some higher level driver like I2C cause this?