You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support for the ESP-IDF framework (Xtensa and RiscV arch)
Dear all,
This PR is implementing support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework, which is the open source SDK provided by Espressif for their MCU family (esp32, esp32s2, esp32c3 and all other forthcoming ones).
Note that this is the second PR on that topic. Approx. an year ago, `@reitermarkus` contributed an [initial set of changes](0dec549#diff-6c07c29bb7b11b27a308055cca03f299266fd8f05af5a65208b64ff715359c89) which are merged already.
Note also that this PR has a [sibling PR against Rust's libStd](rust-lang/rust#87666) which enables **full STD support for the Espressif chipsets** (that is, modulo process support as we are obviously talking about non-kernel bare metal platform here).
A short overview of the changes:
* The original contribution of `@reitermarkus` is renamed from `xtensa.rs` to `espidf.rs` and all branching through this patch is no longer done based on `target_arch = "xtensa"`, but based on `target_os = "espidf"` (this `target_os` value is to be used by the upcoming Rust targets for the ESP-IDF framework). The primary reason for this change is that branching for ESP-IDF based only on the architecture is no longer valid: the newer Espressif chips (esp32c3 and other upcoming ones) are based on the RISCV32IM(A)C architecture, so this patch now supports both Xtensa and RiscV32. Moreover, I would expect that - given the popularity of the riscv ISA - there will be *other* ports of newlib to riscv which will surely have the layout and sizes of the structures etc. different from the ESP-IDF framework.
* The `pthread` structures had sizes which did not match what is used in the ESP-IDF. Ditto for the various `*_INITIALIZER` constants, which do not use 0x00, but 0xff sequences there
* The BSD socket API on ESP-IDF is prefixed with `lwip_`. Rather than doing heavyweight proxying in Rust libStd, it is best to just address this here with a custom `link_name`, just like it had been done for MacOS and other systems.
* Similar to the `l4re` case, the libc crate should NOT issue a link command to the CRT lib for the ESP-IDF, due to the way the SDK is linked
* Various other small fixes: primarily - declaration of standard APIs that are available in the ESP-IDF SDK
I should also admit that the patch has one little ESP-IDF-specific cheat:
* Since the `pthread` support in ESP-IDF is still lacking RW-locks, I've implemented it as a temporary workaround by simply remapping (with `"link_name"`) the `pthread_rwlock_*` symbols to their equivalent `pthread_mutex_*` symbols. While this implementation is suboptimal, it reduces significantly the PR changeset surface of the other PR which is against Rust libStd.
0 commit comments