jlaitine commented on code in PR #12059:
URL: https://github.com/apache/nuttx/pull/12059#discussion_r1554229290
##########
arch/arm64/src/imx9/imx9_flexio_pwm.c:
##########
@@ -444,7 +444,7 @@ static int pwm_update_frequency(struct imx9_pwmtimer_s
*priv, int freq)
static int pwm_update_duty(struct imx9_pwmtimer_s *priv, int pwm_ch,
ub16_t duty16)
{
- uint64_t duty = ub16toi(duty16);
+ uint32_t duty = duty16 & 0xffffffff;
Review Comment:
Actually the interesting part here is that the PWM interface doesn't really
define what is exactly the range of the input - it is between 0x0000.0000 and
0x0000.ffff for sure, but what are the expected pulses at the limits?
Many of the PWM HW blocks actually output one-clock pulses if duty is set to
0, and valid range is from 0x0 - 0x0000.ffff. And again, they produce one clock
inactive cycle if the duty is set to maximum. That is, there is no real
possibility to turn off the PWM by setting duty to 0 or to max, which would be
intuitive.
And is there any REAL reason for the + 0.5 rounding ( + 0x0000.8000 or
b16HALF), which is there in every PWM driver. +/-1 doesn't really make any
difference in the 16-bit output (lack of rounding would produce an error which
is just theoretical...)
Anyhow, this implementation follows the same math as (most of the) other pwm
drivers, and works in practice for us (running drone pwm ESCs / motors).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
