ESP32 pwm.duty(1023) ends up with 65472 when read as duty_u16()

[JohnMTu]

I would expect, that pwm.duty(1023) will be 100%, but it's not.
E.g. for 1000Hz signal it falls to 0V each 1 second for 1micro second... hence duty is only 99.9%.
When read using pwm.duty_u16() i got back 65472.

Tested on ESP WROOM-32 with "MicroPython v1.19.1 on 2022-06-18; ESP32 module with ESP32".

I think correct would be, if duty(arg) impl should delegate to duty_u16 as 65535arg/1023. Similar reading function should read via 1023duty_u16()/65535.

Workaround is to use duty_u16 but that makes code incompatible with esp8266.

[robert-hh]

With duty(1023) you have 977ns pulses (1/1024 of 1 ms), the same as with duty_us16(65472). With duty_u16(65) I get 13ns pulses (~1/65535 of 1 ms). What's wrong with that? 1/1023 is not the same as 1/65536, and so duty(1023) cannot be the same as duty_u16(65535).

[JohnMTu]

my expectation is, that when using duty() then 0 is 0% and 1023 is 100%.
It works like this on ESP8266.
But on ESP32 it's not a case.

Basically i expect two things:

• same behavior accross devices
• being able to set 0% and 100% .. and 1022 steps in between

E.g. documentation here http://docs.micropython.org/en/latest/esp32/quickref.html#pwm-pulse-width-modulation
says
pwm0.duty(256) # set duty cycle from 0 to 1023 as a ratio duty/1023, (now 25%)
hence if i set 1023, i should get ratio 1023/1023 = 1 (100%) ... but that's not a case.

[robert-hh]

The base for duty() is 1024, the base for duty_u16 is 65536, otherwise duty(512) would not result in a 50% duty cycle. 100% duty would be a setting of 1024, which is not allowed on the ESP32. So you cannot get 100%. Maybe the code has to be changed to allow that. Some ports allow a setting of 100%.

[robert-hh]

I just checked it by trial. The ESP32 RTOS does not allow setting the duty_u16 value to more than 65535, hence no 100% duty, which is simply a DC high level..

[JohnMTu]

i just tested with scope, with led.duty_u16(65535) it's also not 100% .. There is few nanos peak always.

if espresif stuff below micropython cannot handle it, then we cannot do much, but at least documentation should be adapted as it's not duty of x/1023, but actually x/1024 where x is in 0-1023 ... and similar for u16 case. Also with note, that 100% cannot be reached as max is either 1023/1024 or 65535/65536.

[robert-hh]

I tested a few ports, and the situation is inconsistent.
For the Pico, duty_u16(65535) results in DC (100%), with the base seeming 65535, and duty_u16(1) is DC 0. At duty_u16(32768), both slopes identical and are shown as 499998.3ns and 499998.8ns (dont't care for the 500ps difference, which means the base is 65536
For the Mimxrt, duty_u16(65535) result in DC, but duty_u16(65534) results in proper 65534/65536, so the base is 65536. But it's differet for teh two types of PWM generators. But at least at duty_us16(32768 ) it's again exactly 50%.
For ESP32 we know the answer already.
I can test further boards, but that may drift away from the initial topic.

[JohnMTu]

for me it's clear now, i would only suggest to update documentation for ESP32 port. Should i close ticket or keep it?

FYI maybe related: #9447

[robert-hh]

That #9447 seems to point a another problem.

PWM is implemented typically by a counter, which counts down a basic clock up to a certain value P and then starts over. The period of the initial clock defines the resolution t0, and the duration of a PWM cycle is t0 * P. When the counter reaches a certain intermediate value M, the output is toggled. M/P defines the duty cycle.

The basic clock for ESP32 is 80Mhz, for Teensy4.0 it's 150Mhz. It has to be divided by a prescaler to get into a proper range of the counter, which is something between 16 and 24 bits. I do not know the counter frequency for the Pico, but it's hardly more than the CPU frequency. So for ESP32 with it's 20 bit counter, we have that 12.5 ns steps, for MIMXRT with the 16 bit counters at 1kHz the counter frequency is 37.5 MHz -> 27 ns steps or roughly duty_u16() in steps of 2.

You may close the ticket. Updating the documentation and maybe harmonizing the ports is another topic. @dpgeorge may also move that to discussions.