Rust ESP32 Community Meeting 2021-09-14

[georgik]

Please add topics and links to this discussion.

The meeting is scheduled 14th September 2021 - 4pm CEST/GMT+2 via Google Meet. The meeting invite is automatically sent to attendees of previous meetings. If you'd like to join, please notify us at https://matrix.to/#/#esp-rs-community-meetins:matrix.org

You can find information from previous meeting at https://github.com/esp-rs/rust/discussions

[N3xed]

esp-idf-sys native build (using cmake instead of platformio)

• There is now initial native build support.
• A native build uses esp-idf native tooling (i.e. cmake, the right gcc toolchain, ninja) currently installed with idf_tools.py, and the esp-idf cloned directly from github.
• This feature is currently experimental as there are still some things missing or incomplete to make it the default build strategy, these are tracked in Tracking issue to use native build strategy as default esp-idf-sys#10.
• Transformation of cargo-pio to embuild (issue ivmarkov/embuild#8)
  • To implement this feature the original build support library cargo-pio has been renamed to embuild and its platformio code has been refactored to be build system agnostic.
  • The original cargo-pio tool was moved into its own binary crate.
  • cargo-pio-link was renamed to ldproxy and is now also its own binary crate. It is used to dispatch the linker arguments to a specific linker set by the esp-idf-sys build script.
  • embuild is now a collection of general utilities to be used from build scripts (i.e. cloning git repositories, cmake file API, parsing config files generated by kconfig, etc.)

[jessebraham]

espflash

• cargo-espflash has been re-written to use clap instead of pico-args
  • less manual upkeep (no more hand-writing usage)
  • easier (IMO) to add new features
  • much better and more detailed help messages
• Support has been added for flashing the ESP32-C3
• Custom partition tables and/or bootloaders can now be passed as CLI arguments
  • uses the existing CSV partition table format
  • use sane defaults for both if not provided
• Flash compression has been implemented for chips which support it
• Improved error messages by using miette instead of anyhow
• There is presently an open PR adding a serial monitor

Bare Metal

• Updated SVD for the ESP32-C3, new SVD for the ESP32-S2 released!
• We finally have gained control of the esp32c3 PAC!
  • Moved into organization, I have been given permissions on the repo and on crates.io
  • Pushed a new release with the new official SVD
• Preliminary (still no release) PAC for the ESP32-S2 has been created
  • https://github.com/esp-rs/esp32s2
  • Running into some issues with svd2rust on this one, need to investigate still

[georgik]

Build of 1.55

• https://github.com/esp-rs/rust-build
• issues with build: 1.55 requires initialised git submodules

Debugging

• command line and support in IDEs

[ivmarkov]

Nothing complete, lots of WIP items:

• Helping @N3xed a bit with the native build. Working on building ESP-IDF master with it.

  • Small hiccups here and there like the need to expose the esp_idf_version.h #defines as Rust cfg items, because master (4.4) has backward-incompatible changes to the i2c and spi configuration structures.

• Ongoing research on generating proper backtraces on Rust errors (not panics)

  • Rust backtrace algorithm in the backtrace-rs crate uses the libunwind APIs and works out of the box for Xtensa, without any patching! Not checked if all frames are correct though
  • In theory should work for RiscV too as long as C++ exceptions are enabled (?) and/or DWARF eh_frame generation is enabled (?). Research depends on building ESP-IDF master with native

• (WIP) embedded-svc traits for an HTTP client and default implementations based on ureq and ESP-IDF's HTTP client

• Researching on TLS story for Rust + ESP-IDF

  • Difficult problem, no "standard" TLS API in Rust STD

• (WIP) Rust OTA bindings

[N3xed]

• Small hiccups here and there like the need to expose the esp_idf_version.h #defines as Rust cfg items, because master (4.4) has backward-incompatible changes to the i2c and spi configuration structures.

Note: We can also get this using cmake from esp-idf/tools/cmake/version.cmake (supported since v4.1).

[ivmarkov]

For the native build - yes. For the PIO build - possible, but quite difficult. I've actually implemented it in the meantime by grepping into the generated bindings file from bindgen (you'll see shortly once I submit the PR). Not the cleanest approach, but relatively reliable, and would work for both build systems.

[ivmarkov]

On the topic of TLS (as in thread local storage) on the ESP-IDF that @igrr mentioned during the discussion:

• Rust (Rust STD APIs, that is) supports both "slow", pthread_get/setspecific based storage, as well as "fast" ELF TLS based storage a.k.a. C++ __thread var attribute (where some concerns were raised).
• The "fast" storage however is an opt-in feature that each target has to explicitly enable as it is false by default.

For all ESP-IDF targets, the "fast" store is NOT enabled, so Rust STD falls back to the slow pthread based one. And it seems to work fine. No extensive tests yet, but I'll put a simple test in the rust-esp32-std-hello crate.

Now, I don't remember what the concerns were with the ELF TLS storage (not supported?), but if it is possible to enable it on the ESP-IDF, perhaps we can do so. But I guess, future, low prio.

[ivmarkov]

Some extra info: TLS in Rust STD is used via the thread_local! macro, which either falls back to pthread or uses the fast storage if available. Only works for static vars. Now, there is an unstable feature in Rust, which enables basically an identical syntax to C++'s __thread: #[thread_local] which works for non-static vars too and seems to be hard-wired to the fast storage. Which is one of the major reasons why it is not stabilized yet - no uniform support across all platforms.

[MabezDev]

Compiler

• 1.55 branch here: https://github.com/esp-rs/rust/tree/esp-1.55.0
• A STD build broken, missing llvm intrinsics in our fork for Xtensa - riscv still works.
  • I opened this issue upstream to try and gauge what intriniscs we need... theres quite a lot. I guess we should probably try and mimic what riscv intrinsics are implemented?

probe-rs

• Various PR's to fix up probe-rs for our chips
• Latest PR adding support for fixed address loading of flashing algo's (more like openocd work area) so we can use the ROM code of espressif chips easily.
• Using the new esp32c3 pac crate to improve the algo
  • the ROM api handles flashing, but clocks etc need to be setup on a per chip basis

[georgik]

Links mentioned during the meeting:

• TLS: https://github.com/drogue-iot/drogue-tls
• Matrix: room/#drogue-iot:matrix.org
• Thread local: https://doc.rust-lang.org/stable/std/macro.thread_local.html