ports/esp32: pwm: prevent duty glitch on init#12650
Conversation
When a new channel was assigned, configure_channel would seet the duty
to 50% before resetting to the actual user specified duty. This results
in unintentional glitches.
Example code
```
p1 = machine.PWM(self.pin1, self.pwm_freq, duty_u16=0)
```
This would brieflt glitch a pwm motor driver when it's created, instead of
leaving it at duty=0 as intended.
Instead, we calculate the duty into native units first, and apply it
separately in a second step where needed.
Signed-off-by: Karl Palsson <[email protected]>
karlp
force-pushed
the
karl-pwm-init-fix1
branch
from
e321c5a to
26d4ebe
Compare
|
Yes, I discovered this while testing out #10854. This is much less intrusive, doesn't involve other exernal libs, and given the impact of it, seemed worthy of submitting on it's own, rather than the rest of the "consistency" fixes that old PR attempts to address. |
See micropython/micropython#12650 It's not _critical_ but it's nice to not glitch the motor when you are trying to init the pins.
|
This is an automated heads-up that we've just merged a Pull Request See #13763 A search suggests this PR might apply the STATIC macro to some C code. If it Although this is an automated message, feel free to @-reply to me directly if |
|
Since #10854 was (finally!) merged, can this PR be closed? |
|
I believe so yeah, it's certainly out of date now. |
4 participants
When a new channel was assigned, configure_channel would seet the duty to 50% before resetting to the actual user specified duty. This results in unintentional glitches.
Example code
This would brieflt glitch a pwm motor driver when it's created, instead of leaving it at duty=0 as intended.
Instead, we calculate the duty into native units first, and apply it separately in a second step where needed.
I'm not entirely in love with the split setters, but it made for the least intrusive diffs, to clearly show the problem.