PWM Duty Cycle update best practices

RE: PWM Duty Cycle update best practices

aaronxu — Mon, 24 Nov 2014 08:29:45 GMT

Anyone have example code with softdevice or without softdevice? please post one, thanks :)

RE: PWM Duty Cycle update best practices

mst — Wed, 24 Sep 2014 06:46:58 GMT

Thanks for taking the effort to solve this! I cannot oversee all issues/race conditions, but a first sight using the timeslot API seems to be a bit overkill... For my application it would not be an issue if the changing of the PWM is delayed for a very short time by some high prio interrupts, the main issue now is that the PWM timer is stopped and restarted. In between, there is no PWM output on the desired pin (for an amount of time influenced by high prio interrupts) causing the flickering. The noglitch version currently in the repository seems to make a nice step towards keeping the PWM timer running and updating compare registers. Wouldn't it be possible to further build on this approach and solve the currently existing errors??

RE: PWM Duty Cycle update best practices

ovrebekk — Tue, 23 Sep 2014 15:34:06 GMT

I wrote the original driver, but not the noglitch one. It seems there are some issues in the noglitch version that remain to be solved.

I am considering rewriting the entire thing so that we only need a single driver that solves both problems. Unless anyone else have any good ideas I believe I need to ensure that the PWM interrupt can run without danger of higher priority interrupts superseding it, otherwise I can't think of a way to take care of all possible race conditions.

I believe this solution will require the PWM driver to use interrupt priority 0 when the SoftDevice is not present, and it will have to use the timeslot API in S110 v7 or later when the SoftDevice is running, to make sure that the PWM's can be updates safely without incurring glitches in the output.

I can't make any promises on the timing yet, a new driver will be released when you least expect it :P

RE: PWM Duty Cycle update best practices

mst — Wed, 17 Sep 2014 11:09:36 GMT

Anyone any progress on this?

RE: PWM Duty Cycle update best practices

Magnier — Mon, 08 Sep 2014 12:18:56 GMT

No HardFault for me, I could get a PWM waveform under certain conditions (never set value to 0 or max, and it worked only when increasing duty cycle).

Too bad there's no working example in the repo nor author contact...

RE: PWM Duty Cycle update best practices

Jakub Luzny — Mon, 08 Sep 2014 09:36:37 GMT

I'm getting HardFault's in my code when setting PWM value using noglitch version of library. Has anyone got in working?

RE: PWM Duty Cycle update best practices

mst — Mon, 08 Sep 2014 09:03:38 GMT

Still several bugs in the code (e.g. setting the pwm to the same value not properly handled). Hope it is solved soon. Will take a closer look as well.

RE: PWM Duty Cycle update best practices

mst — Mon, 08 Sep 2014 08:21:58 GMT

So far, I'm also not able to get it working...

RE: PWM Duty Cycle update best practices

Magnier — Thu, 04 Sep 2014 20:00:27 GMT

The PWM library on Nordic GitHub page has been updated a few days ago with a no glitch version using PPI, Timer compare and capture tasks.

Unfortunately I couldn't get it to work (using the sin. example), has someone succeeded to use it ?

RE: PWM Duty Cycle update best practices

mst — Thu, 28 Aug 2014 16:40:50 GMT

Any news on this? I have some issues with changing the PWM value as well, similar to the question asked here: nrf_pwm signal glitches ("flickering") on nrf_pwm_set_value()

Especially during a BLE connection, frequently changing the PWM value, in order to "fade-in" an attached LED, results in an unstable PWM and flickering LED.

Hope anyone has some info on this...