Skip to content

Add ESP-IDF v6.0 support#409

Merged
ivmarkov merged 3 commits intoesp-rs:masterfrom
mh0pe:esp-idf-v6-support
Mar 29, 2026
Merged

Add ESP-IDF v6.0 support#409
ivmarkov merged 3 commits intoesp-rs:masterfrom
mh0pe:esp-idf-v6-support

Conversation

@mh0pe
Copy link
Copy Markdown
Contributor

@mh0pe mh0pe commented Mar 25, 2026 •
edited
Loading

Summary

Additional v6.0 fixes and new driver bindings, rebased on top of @drinkcat's #408 per their suggestion.

Commits from @drinkcat (preserved as-is):

  • MbedTLS crypto header guards, gpio_reg.h, uart_vfs.h, pcnt module guard
  • Picolibc sysroot detection, gcc_sysroot in build output
  • MQTT and Ethernet managed component headers, CI v6.0

Our additions (2 commits on top):

  1. bindings: fix v6.0 header issues and add new driver bindings

    • Fix ESP_IDF_COMP_ESP_PARTITION guard (missing _ENABLED suffix -- pre-existing bug)
    • Guard lwip/lwip_napt.h for v6.0 (removed upstream)
    • Guard esp_vfs_cdcacm.h for v6.0 (moved to esp_usb_cdc_rom_console)
    • Fix esp_lcd_panel_rgb.h to remain available on v6.0 via SOC_LCD_RGB_SUPPORTED
    • New TWAI driver bindings (esp_twai.h, esp_twai_onchip.h)
    • SDM driver bindings (driver/sdm.h)
    • v6.0+ driver bindings: Camera, ISP, JPEG, Analog Comparator, Parallel IO

  2. CI: enable full version matrix with exclusions

    • Uncomment all ESP-IDF versions (v4.4.8 through v6.0) with proper target exclusions
    • 43 CI jobs covering the entire supported version range
    • Deprecation warning suppression for legacy drivers

Test plan

  • CI: 43 jobs (v4.4.8 through v6.0 x 6 targets, with exclusions for unsupported combos)

This was referenced Mar 25, 2026
Closed
Closed
@mh0pe mh0pe force-pushed the esp-idf-v6-support branch 3 times, most recently from 84e465d to df4493f Compare March 26, 2026 03:30
@drinkcat
Copy link
Copy Markdown
Contributor

drinkcat commented Mar 26, 2026

Argh, did you notice #408?

@drinkcat
Copy link
Copy Markdown
Contributor

drinkcat commented Mar 26, 2026

(happy to work on this together, no worries, just a bit concerned about the work overlap ,-P)

@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026

(happy to work on this together, no worries, just a bit concerned about the work overlap ,-P)

@drinkcat I suggest you and @mh0pe collaborate, if possible. Ideally we should merge one set of PRs.
@drinkcat Can you also look what in this PR is done in a different/better way compared to yours and perhaps carry-over?

What I'm a bit against in that concrete PR:

  • Bumping default to 6.0. Too early for that. We should stay on 5.x
  • Bumping the in-GIT versions of the sys/hal/svc crates so early. This we do just prior to a release, even if GIT contains breaking changes
  • The Changelog updates here are as if the new version is released, while they should be for an unreleased version without a date
  • Removing support for 4.4.x unless supporting 4.4.x and 6.0 results in the bindings code becoming really unreadable. And that might be the case? Not sure?

@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026

@drinkcat Also I wonder how this PR managed to do it without the introduction of a "fake" sysroot, as you did in yours?
This is the only relevant snippet I found:

# Use Newlib instead of Picolibc (ESP-IDF v6.0 default).
# Picolibc's -specs=picolibc.specs is incompatible with clang/bindgen.
CONFIG_LIBC_NEWLIB=y

drinkcat
drinkcat reviewed Mar 26, 2026
View reviewed changes
.github/configs/sdkconfig.defaults
# Picolibc's -specs=picolibc.specs is incompatible with clang/bindgen.
CONFIG_LIBC_NEWLIB=y

# Suppress deprecation warnings for legacy drivers still included in bindings
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

I like this, I wonder if we should actually build the bindings with -Werror so that we're aware of those.

Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 29, 2026

Choose a reason for hiding this comment

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

(I quickly tried, maybe not worth it)

@drinkcat
Copy link
Copy Markdown
Contributor

drinkcat commented Mar 26, 2026

(happy to work on this together, no worries, just a bit concerned about the work overlap ,-P)

@drinkcat I suggest you and @mh0pe collaborate, if possible. Ideally we should merge one set of PRs. @drinkcat Can you also look what in this PR is done in a different/better way compared to yours and perhaps carry-over?

I'll take a look. There's a few things that seem worth picking (as part of a 6.0 support MR, or as follow-ups).

@drinkcat Also I wonder how this PR managed to do it without the introduction of a "fake" sysroot, as you did in yours? This is the only relevant snippet I found:

# Use Newlib instead of Picolibc (ESP-IDF v6.0 default).
# Picolibc's -specs=picolibc.specs is incompatible with clang/bindgen.
CONFIG_LIBC_NEWLIB=y

Yep, that's it. I considered forcing to use newlib as well, but I decided to keep the default from esp-idf 6.0 (picolibc), and figure out how to make it work. Apart from the sysroot hack, the rest of support looked easy, I think? (https://github.com/esp-rs/esp-idf-hal/pull/578/changes#diff-2bd60f29989e7f927a4f3f4325d2ec2254df11c50d040d772fbeb67ce3abf008 this should be looked at carefully though, didn't really check how to test)

@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026

Yep, that's it. I considered forcing to use newlib as well, but I decided to keep the default from esp-idf 6.0 (picolibc), and figure out how to make it work. Apart from the sysroot hack, the rest of support looked easy, I think? (https://github.com/esp-rs/esp-idf-hal/pull/578/changes#diff-2bd60f29989e7f927a4f3f4325d2ec2254df11c50d040d772fbeb67ce3abf008 this should be looked at carefully though, didn't really check how to test)

I agree. Let's keep your approach then!

@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026 •
edited
Loading

Yep, that's it. I considered forcing to use newlib as well, but I decided to keep the default from esp-idf 6.0 (picolibc), and figure out how to make it work. Apart from the sysroot hack, the rest of support looked easy, I think? (https://github.com/esp-rs/esp-idf-hal/pull/578/changes#diff-2bd60f29989e7f927a4f3f4325d2ec2254df11c50d040d772fbeb67ce3abf008 this should be looked at carefully though, didn't really check how to test)

I agree. Let's keep your approach then!

Ah, almost forgot. picolibc seems to be a fork of newlib. Yet, I'm not 100% sure all definitions here would match the picolibc ones. In the worst case (and if there is a mismatch), we might have to introduce a picolibc module to the Rust libc bindings' crate.

There's a tool that can do comparison between what Rust's libc "thinks" the sizes of these types should be, and what esp-idf-sys actually reports them to be: https://github.com/SergioGasquez/libc-checks

drinkcat
drinkcat reviewed Mar 26, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat left a comment

Choose a reason for hiding this comment

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

Yeah, had a quick look, may have missed things:

  • I have a way to support Picolibc -- not particularly pretty though
  • I didn't remove 4.x support (this makes the 2 PR a bit difficult to compare -- it'd be nicer to do that as a separate MR IMHO, as it doesn't make 6.0 that much more complicated)
  • pcnt handling is different, the advantage of what I have is that it'll become a LOT simpler one we drop support for 5.x. Eventually.
  • This PR adds header files in bindings for a bunch of new drivers. I guess that's a good thing to do eventually (but not that terribly useful without the new drivers?)

src/include/esp-idf/bindings.h
#endif
#endif
#ifdef ESP_IDF_COMP_ESP_PARTITION
#ifdef ESP_IDF_COMP_ESP_PARTITION_ENABLED
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

Not sure to understand this one

Copy link
Copy Markdown
Collaborator

@ivmarkov ivmarkov Mar 26, 2026

Choose a reason for hiding this comment

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

This is valid. There is likely no ESP_IDF_COMP_ESP_PARTITION. The correct name is ESP_IDF_COMP_ESP_PARTITION_ENABLED

src/include/esp-idf/bindings.h
#if OLD_DRIVER_COMP_TWAI || defined(ESP_IDF_COMP_ESP_DRIVER_TWAI_ENABLED)
#include "driver/twai.h"
#endif
#if ESP_IDF_VERSION_MAJOR > 5 && defined(ESP_IDF_COMP_ESP_DRIVER_TWAI_ENABLED)
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

I guess this is worth it, maybe not terribly useful if we don't have a driver yet -- but doesn't hurt.

Copy link
Copy Markdown
Collaborator

@ivmarkov ivmarkov Mar 26, 2026

Choose a reason for hiding this comment

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

TWAI = CAN. We do have a driver for that? Or do you mean there is a new twai/can driver? I might have forgotten that...

Also, getting as many raw bindings included (even of we don't have type-safe Rust drivers for those) in general IS useful, as then the user could just call the unsafe C bindings to work with the ESP-IDF drivers.

If the drivers are not even included in the bindings, then there is no escape hatch, which is pretty bad.

With that said, I'm not sure I understand this change...

Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

Oh I didn't even know what TWAI is ,-P

More generally talking about adding new header files to the bindings -- I assumed a new header means a new esp-idf driver, so no support on the Rust side (yet). Understood it makes sense to add them.

src/include/esp-idf/bindings.h Outdated
#if ESP_IDF_VERSION_MAJOR < 6
#include "driver/rmt.h"
// Rename to avoid conflict with rmt_channel_t enum in rmt.h
#define rmt_channel_t rmt_drv_channel_t
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

I didn't need this... somehow.

src/include/esp-idf/bindings.h
#endif
#ifdef ESP_IDF_COMP_ESP_DRIVER_SDM_ENABLED
#include "driver/sdm.h"
#endif
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

ditto, probably worth adding

src/include/esp-idf/bindings.h
#endif
#endif

// New drivers (ESP-IDF v6.0+)
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

and ditto

src/pcnt.rs
@@ -1,9 +1,8 @@
#![allow(non_camel_case_types, non_upper_case_globals)]
Copy link
Copy Markdown
Contributor

@drinkcat drinkcat Mar 26, 2026

Choose a reason for hiding this comment

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

That file is simply not needed on 6.0+ (legacy API removed), so I compiled it out.

But I had to add more code to remove pcnt from the blocklist then.

@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026

More background: rust-lang/libc#3920

@mh0pe mh0pe force-pushed the esp-idf-v6-support branch from df4493f to efdd207 Compare March 26, 2026 13:05
@mh0pe mh0pe changed the title Add ESP-IDF v6.0 support, bump default to v6.0, drop v4.x Add ESP-IDF v6.0 support Mar 26, 2026
@mh0pe mh0pe force-pushed the esp-idf-v6-support branch 2 times, most recently from 8f0feef to 13601a5 Compare March 26, 2026 14:20
@drinkcat
Copy link
Copy Markdown
Contributor

drinkcat commented Mar 26, 2026

(happy to work on this together, no worries, just a bit concerned about the work overlap ,-P)

@mh0pe On this topic of working together ,-) I'm not sure if I see the value of squashing most of (all?) my changes into this branch, especially given that I attempted to separate changes in logical units with reasonable commit descriptions.

BUT, maybe a good approach would be to rebase and stack your changes on top of mine? The new header definitions (and misc fixes in bindings.h) are worth picking at least (not sure what else there is) -- and are technically independent of the 6.0 support itself.

Please let me know!

@mh0pe mh0pe force-pushed the esp-idf-v6-support branch 4 times, most recently from 0c962cd to 31b0942 Compare March 26, 2026 17:41
@mh0pe
Copy link
Copy Markdown
Contributor Author

mh0pe commented Mar 26, 2026

@drinkcat Rebased on top of your branch as you suggested. Your 10 commits are preserved as-is, with 2 of ours on top:

  1. bindings fixes + new driver bindings: ESP_PARTITION_ENABLED bugfix, lwip_napt/esp_vfs_cdcacm v6 guards, esp_lcd_panel_rgb v6 fix, and new driver bindings (TWAI, SDM, Camera, ISP, JPEG, Analog Comparator, Parallel IO)

  2. Full CI matrix: Uncommented all ESP-IDF versions (v4.4.8 through v6.0) with proper target exclusions for chips that did not exist in older versions. 43 CI jobs covering the entire supported range.

Also closed the hal (#577) and svc (#647) PRs in favor of your #578 and #650 -- our changes there were entirely cherry-picked from yours.

Let me know if anything needs adjustment!

@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026

Also closed the hal (#577) and svc (#647) PRs in favor of your #578 and #650 -- our changes there were entirely cherry-picked from yours.

@mh0pe

I do not understand - why cherry-pick from PR X and then open a separate PR Y with the cherry-picked changes, given that PR X is 2 days old max?

What am I missing?

@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026

@drinkcat Rebased on top of your branch as you suggested. Your 10 commits are preserved as-is, with 2 of ours on top:

  1. bindings fixes + new driver bindings: ESP_PARTITION_ENABLED bugfix, lwip_napt/esp_vfs_cdcacm v6 guards, esp_lcd_panel_rgb v6 fix, and new driver bindings (TWAI, SDM, Camera, ISP, JPEG, Analog Comparator, Parallel IO)
  2. Full CI matrix: Uncommented all ESP-IDF versions (v4.4.8 through v6.0) with proper target exclusions for chips that did not exist in older versions. 43 CI jobs covering the entire supported range.

Also closed the hal (#577) and svc (#647) PRs in favor of your #578 and #650 -- our changes there were entirely cherry-picked from yours.

Let me know if anything needs adjustment!

@ivmarkov ivmarkov closed this Mar 26, 2026
@ivmarkov ivmarkov reopened this Mar 26, 2026
@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 26, 2026

@drinkcat Rebased on top of your branch as you suggested. Your 10 commits are preserved as-is, with 2 of ours on top:

  1. bindings fixes + new driver bindings: ESP_PARTITION_ENABLED bugfix, lwip_napt/esp_vfs_cdcacm v6 guards, esp_lcd_panel_rgb v6 fix, and new driver bindings (TWAI, SDM, Camera, ISP, JPEG, Analog Comparator, Parallel IO)
  2. Full CI matrix: Uncommented all ESP-IDF versions (v4.4.8 through v6.0) with proper target exclusions for chips that did not exist in older versions. 43 CI jobs covering the entire supported range.

Once #408 is merged (and it might be squashed in the process, so you might have to rebase), we'll know the actual surface change of your remaining changes.

In any case, thanks for working with @drinkcat and figuring out a common path forward!

@mh0pe
Copy link
Copy Markdown
Contributor Author

mh0pe commented Mar 26, 2026

@ivmarkov Fair point -- the hal and svc PRs were a mistake on our part. We initially wrote our own fixes, then incorporated @drinkcat's more complete changes, and should have simply deferred to their PRs from the start instead of cherry-picking into ours. That's why we closed them.

This sys PR (#409) is the only one where we have unique contributions: the bindings fixes (ESP_PARTITION, lwip_napt, esp_vfs_cdcacm, lcd_panel_rgb) and new driver headers (TWAI, SDM, Camera, ISP, JPEG, etc.), plus the full CI matrix with version exclusions. Those are rebased cleanly on top of @drinkcat's branch.

@mh0pe mh0pe force-pushed the esp-idf-v6-support branch from db6ac5d to 2ca888e Compare March 26, 2026 19:02
@ivmarkov
Copy link
Copy Markdown
Collaborator

ivmarkov commented Mar 28, 2026

@mh0pe Would you rebase on top of latest master now that #408 is merged?

mh0pe and others added 3 commits March 28, 2026 11:21
@mh0pe @claude
bindings: fix v6.0 header issues and add new driver bindings
dde1f36 
- Fix ESP_IDF_COMP_ESP_PARTITION guard (missing _ENABLED suffix)
- Guard lwip/lwip_napt.h for v6.0 (removed upstream)
- Guard esp_vfs_cdcacm.h for v6.0 (moved to esp_usb_cdc_rom_console)
- Fix esp_lcd_panel_rgb.h to remain available on v6.0 via SOC_LCD_RGB_SUPPORTED
- Add new TWAI driver bindings (esp_twai.h, esp_twai_onchip.h) for v6.0+
- Add SDM driver bindings (driver/sdm.h) for v5.3+
- Add v6.0+ driver bindings: Camera, ISP, JPEG, Analog Comparator, Parallel IO

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@mh0pe @claude
CI: enable full version matrix with exclusions, add deprecation suppr…
187c8c7 
…ession

Uncomment all ESP-IDF versions (v4.4.8 through v6.0) in the CI matrix
and add proper exclusions for targets not supported in older versions:
- riscv32imac (ESP32-C6/H2): exclude v4.4.8
- riscv32imafc (ESP32-P4): exclude v4.4.8 through v5.2.5

This gives 43 CI jobs covering the entire supported version range.

Also add deprecation warning suppression for legacy i2c/twai/touch
drivers in sdkconfig.defaults (v6.0-only Kconfig options, silently
ignored by v5.x).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@mh0pe @claude
bindings: fix uart_vfs.h and mbedtls guards for v4.4/v5.0 compatibility
f220717 
- uart_vfs.h: tighten guard from >= 5.0 to >= 5.3 (header only exists
  since the driver component split in v5.3)
- mbedtls: replace build_info.h + MBEDTLS_VERSION_MAJOR < 4 guard with
  ESP_IDF_VERSION_MAJOR < 6 (build_info.h does not exist in MbedTLS 2.x
  used by ESP-IDF v4.4)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@mh0pe mh0pe force-pushed the esp-idf-v6-support branch from 2ca888e to f220717 Compare March 28, 2026 18:21
@mh0pe
Copy link
Copy Markdown
Contributor Author

mh0pe commented Mar 28, 2026

@ivmarkov Rebased on latest master (with #408 merged). Now just 3 commits with our unique additions:

  1. bindings fixes + new driver headers: ESP_PARTITION_ENABLED bugfix, lwip_napt/esp_vfs_cdcacm v6 guards, esp_lcd_panel_rgb v6 fix, new TWAI/SDM/Camera/ISP/JPEG/Analog Comparator/Parallel IO bindings
  2. Full CI matrix: v4.4.8 through v6.0 with proper target exclusions (42 jobs)
  3. uart_vfs.h guard tightened to >= 5.3, mbedtls guard fix for v4.4 compat

@drinkcat
Copy link
Copy Markdown
Contributor

drinkcat commented Mar 29, 2026 •
edited
Loading

Not sure about the value of adding back old esp-idf versions to CI, but otherwise LGTM.

@ivmarkov ivmarkov merged commit b099089 into esp-rs:master Mar 29, 2026
42 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ivmarkov ivmarkov ivmarkov left review comments

+1 more reviewer

@drinkcat drinkcat drinkcat left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@mh0pe @drinkcat @ivmarkov