Skip to content

esp32: Fix machine.PWM on IDF <5.2. #16127

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 5, 2024

Conversation

projectgus
Copy link
Contributor

@projectgus projectgus commented Nov 1, 2024

Summary

Restore PWM support for ESP-IDF v5.0.x and v5.1.x. The cleanup in #16090 relies on some functions not available in older ESP-IDF. Temporarily restore support for a possible V1.24.1 bugfix release, before we actually drop support for ESP-IDF <5.2.

(Edit: Dropped the other commit which was in this PR as it wasn't necessary.)

Testing

  • Tried briefly to make a unit test with machine.time_pulse_us() as suggested by @dpgeorge here. Unfortunately it looks like readback of the same pin that's outputting PWM doesn't currently work - need to either fix that or require a jumper between two pins to run the test.
  • Instead, wired up the logic analyser and measured frequencies between 50Hz and 16.667Mhz with some different duty cycles on ESP32, ESP32-C3 and ESP32-S3 and ESP-IDF versions 5.2.2, 5.1 and 5.0.4.

Trade-offs and Alternatives

  • We could drop support for ESP-IDF <5.2 immediately instead of reinstating support here, but that's not very reasonable if there's going to be a V1.24.1 bugfix release.

@projectgus projectgus force-pushed the bugfix/esp32_pwm_pre_idf52 branch from 4b85c6a to 6e00c52 Compare November 1, 2024 05:19
@projectgus projectgus changed the title esp32: Fix PWM on IDF <5.2, add real frequency readback. esp32: Fix machine.PWM on IDF <5.2. Nov 1, 2024
@IhorNehrutsa
Copy link
Contributor

Features from this PR are implemented in #10854

static void set_freq(machine_pwm_obj_t *self, unsigned int freq, ledc_timer_config_t *timer) {
esp_err_t err;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this was moved here, instead of just keeping it as it was, defined at the place of use below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the first place of use is now inside an #ifdef block.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see, I missed that it's also used for ledc_timer_config().

I would have put this within the if (freq != timer->freq_hz) block to keep its scope limited, but here is also fine considering it's a generic error return variable.

@dpgeorge
Copy link
Member

dpgeorge commented Nov 4, 2024

tried briefly to make a unit test with machine.time_pulse_us() as suggested by @dpgeorge here. Unfortunately it looks like readback of the same pin that's outputting PWM doesn't currently work

Oh, that's a shame! It would have been great to be able to test PWM on all ports without any hardware connections. But I guess it's too much to ask of all ports to support reading a pin in PWM mode.

In that case we could do it with a single jumper wire, and still use time_pulse_us(). Would be good to use the same two pins with a jumper that the UART tests use.

Anyway, that can be done separately to this PR.

@dpgeorge
Copy link
Member

dpgeorge commented Nov 4, 2024

We could drop support for ESP-IDF <5.2 immediately instead of reinstating support here, but that's not very reasonable if there's going to be a V1.24.1 bugfix release.

I think we should fix this for a bugfix release.

@dpgeorge
Copy link
Member

dpgeorge commented Nov 4, 2024

See #16147 for a test for PWM.

@projectgus
Copy link
Contributor Author

projectgus commented Nov 4, 2024

Features from this PR are implemented in #10854

I appreciate you've been working steadily at that PR for a while without a lot of feedback, however I don't quite understand what you mean. AFAIK this PR doesn't add any features, all the new code here is copy-paste of code that was removed in #16090 (but now with #ifdefs around it for older IDF).

What features do you mean?

@IhorNehrutsa
Copy link
Contributor

What features do you mean?

I mean that ledc_find_suitable_duty_resolution is used like in this PR.

@projectgus
Copy link
Contributor Author

projectgus commented Nov 4, 2024

What features do you mean?

I mean that ledc_find_suitable_duty_resolution is used like in this PR.

Oh, I see. This function was already added in #16090 actually, but I see that if we'd merged #10854 earlier then we wouldn't have needed that one.

ledc_find_suitable_duty_resolution function is not present in IDF<5.1 which is why this PR adds back the old logic temporarily. However after this PR (which is for v1.24.1) we can merge #16128 (for v1.25) and only support IDF>=5.2 which will make things simpler.

The cleanup in 548babf relies on some functions not available in older
ESP-IDF. Temporarily restore them, until we drop support for ESP-IDF <5.2.

PWM functionality should end up the same regardless of ESP-IDF version, and
also no different from MicroPython V1.23.

Signed-off-by: Angus Gratton <angus@redyak.com.au>
@dpgeorge dpgeorge force-pushed the bugfix/esp32_pwm_pre_idf52 branch from 6e00c52 to 594670e Compare November 5, 2024 06:20
@dpgeorge
Copy link
Member

dpgeorge commented Nov 5, 2024

I tested this with the test from #16147 using IDF 5.0.4 and IDF 5.2.2, on both ESP32_GENERIC and ESP32_GENERIC_S2. The test passes (tests between 50Hz and 10kHz PWM frequency) except for some glitches for 100% duty cycle, which were already present on master.

@dpgeorge dpgeorge merged commit 594670e into micropython:master Nov 5, 2024
8 checks passed
@IhorNehrutsa
Copy link
Contributor

IhorNehrutsa commented Nov 6, 2024

timer->duty_resolution must be in 0 <= timer->duty_resolution <= HIGHEST_PWM_RES

@dpgeorge dpgeorge added this to the release-1.24.1 milestone Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants