PWM get_max_duty() off by one about rp-hal HOT 4 CLOSED

Duty is an associated type so would the use of a newtype (and/or an enum) to wrap an integer with range checks be simple enough ? (I'd rather avoid over engineering).

I don't think this can be fixed by modifying set_duty or it's parameter of type Duty alone: When TOP is set to 0xffff, there's just no register value of CC that would lead to true 100% duty cycle.

from rp-hal.

The most sensible solution out of this conflict could be to just limit the TOP value to 0xfffe in set_top()

Makes sense to me

from rp-hal.

Duty is an associated type so would the use of a newtype (and/or an enum) to wrap an integer with range checks be simple enough ? (I'd rather avoid over engineering).

from rp-hal.

Really fixing set_duty in a way that would prevent the caller from setting it to 0xffff would imply adding some error handling: Either the function would have to panic, or return some error value, in case the caller specified 0xffff. (Using some wrapper type with limited range would only shift the same issue to the instantiation of that type.)

As this is not a soundness issue, it should be sufficient to document that 0xffff would prevent the hardware from generating a true 100% duty cycle. However, the default value should be changed to 0xfffe. That's what I implemented in #744.

from rp-hal.