Hello David,

Thanks for your reply. I fully understand that. In my case I have the half
bridge schema of four pins and PWM frequency is very low. In case I need to
do immediate stop I need to stop pulse generation and short pin to the
ground. It is more because the overall half bridge solution is controlled
by 2 pins with PWM and other 2 pins are controlled as GPIOs. There where
the sync problems come in place.

Best regards,
Petro

On Sat, Nov 12, 2022, 9:34 AM David Sidrane <david.sidr...@nscdg.com> wrote:

> Hi Petro,
>
> On the STM32 there are shadow registers that buffer the updated data to
> ensure that outputs are updated synchronously with the end of the period.
> There is a bit that can be set to force the update to the shadowed
> registers
> to be immediate, which will change the count of the current period in that
> period. This can be dangerous; in that it could extend a pulse and create
> an
> undesired position or speed. In the case of going to 0, this could create a
> runt pulse and also create an undesired position or a slow speed (not so
> bad), Because the update is asynchronous the pulse with the output, it is
> not deterministic. So synchronous updates are a good thing most times.
>
> David
>
>
> -----Original Message-----
> From: Petro Karashchenko <petro.karashche...@gmail.com>
> Sent: Friday, November 11, 2022 6:50 PM
> To: dev@nuttx.apache.org
> Subject: PWM fast stop operation
>
> Hello team,
>
> Recently I had a project where I had to control a motor using PWM. In
> general things worked pretty well, but I've met an issue when I need to
> stop
> PWM as soon as possible. My custom board is based on SAMv7 and uses the
> standard NuttX PWM driver. The issue with the SAMv7 PWM peripheral is that
> when a PWM stop is issued the PWM generation is not stopped immediately,
> but
> waits at the end of the current cycle. I'm not sure if that is unique to
> SAMv7, so maybe you can give feedback about the other platforms. Initially
> I
> tried to replace stop by keeping PWM running and updating config to have 0%
> duty cycle, but that still waits till the end of the current cycle to
> apply.
> The SAMv7 PWM has a signal override capabilities, so I used that instead of
> stopping the PWM. I've extended the "struct pwm_info_s" structure and
> included an override field there, but feel that it might not be the best
> approach.
>
> I would appreciate your advices on what is the best way to integrate output
> override feature into existing PWM driver.
>
> Best regards,
> Petro
>

Reply via email to