Rust ESP32 Community Meeting 2021-09-30

[georgik]

Please add topics and links to this discussion.

The meeting is scheduled 30th 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

[georgik]

Updates

• build of 1.55.0 with Xtensa support - done
• installer scripts in esp-rs/rust-build,
• deployment via espressif/idf-env: idf-env rust install
• ESP-IDF Windows tool installer espressif/idf-installer
• Podman/Docker image updated: espressif/idf-rust
• Rust release schedule review: https://github.com/esp-rs/rust/projects
• roadmap review - end of Q3 2021 - https://github.com/orgs/esp-rs/projects/1
• cryptohgraphy v35 - potential side effects

Issues:

• Error when building on Linux aarch64 esp-idf-sys#14 - ESP-IDF Tools are not available for Linux aarch64 - know limitation - how to resolve it?
• Allow using esp-idf-svc with the CMake build espressif/rust-esp32-example#34 - esp-idf-svc as part of idf.py-first example

[jessebraham]

Unfortunately not a lot of visible progress from me this time around, I've been doing a lot of yak-shaving lately.

SVDs

• Work has begun on generating SVDs for the ESP32 and ESP32-S3
  • Coming soon™️
• Pending some internal MRs, new features coming soon to existing SVDs:
  • Enable proper versioning by allowing a version number to be specified at generation time
  • Add <addressBlock/> and <interrupt/> elements to peripherals
  • Fix hard-coded register widths

Hopefully next week I will be publishing new SVDs for the ESP32-C3 and ESP32-S2 with the new features/corrections included.

Documentation

• I have created a new repository, esp-rs/book
  • This uses mdbook to generate static documentation
• If anybody has any input on how to structure this and/or what material it should include, please let me know!
  • Please also feel free to open a PR 😉
• Where do we want this to live? GitHub sites? Espressif domain/servers?

[N3xed]

Unfortunately, I can't attend today's community meeting but I'll still post my small progress update here for those interested.

Status update for esp-idf-sys' native build strategy

• I tried writing my own crate for downloading and unpacking tools here but I wasn't really satisfied with what I came up with and it also seems overkill right now.
• I've also looked a little bit into idf-env, but it seems difficult to use this instead of directly using idf_tools.py. As it's a binary crate (depending on binary crates is currently unstable) we would need to publish idf-env as a library to crates.io. Additionally, it would mean more research into the code-base and many more dependencies for the end-user.
• In the meantime (until I find a better solution), I will just move my install logic from the esp-idf-sys' native build script to a new espidf module in embuild and abuse idf-tools.py to install custom tools that we need (with a custom tools.json). I'm moving this logic to embuild, so that we have a more or less general solution to detecting installed esp-idf tools and the esp-idf itself. This allows us then create a tool similar to cargo-pio.

[MabezDev]

Probe-rs

• Fixed flash address PR merged, we can now use ROM functions in our flash loader easily
• PR to prefer word reads/writes to system memory
  • Improves flashing speed
  • Allows RTT to work

RTT for esp32c3 (and other non-A riscv silicon)

• atomic polyfill PR to add core::sync::atomic
• PR for rtt target - Not yet accepted.
• Discussion issue on knurling/defmt about added esp32c3 support.

esp-flash loader

• Cleaned up, added docs, and made it easy to add new chip support
• Moved from my repo to esp-rs
• TODO: upstream the yaml to probe-rs

Meta

• Espressif team in esp-rs repo should make issue triaging and project management less painful :D
• New esp-rs logo

[ivmarkov]

Rust-async + ESP-IDF

• Small demo in rust-esp32-std-hello based on smol-rs. smol-rs in the meantime has support for the poll + pipe API, but still needed patching, because ESP-IDF does not support pipe, so I had to rewire it to poll+'eventfd
• Since async-std is internally using smol-rs, we probably have that covered too
• Tokio support is more difficult; to be explained during the meeting; details to follow here
  • UPDATE: Some extra details:
  • smol-rs's "reactor" is implemented in the polling crate. The polling crate semantics is a good fit for implementing with the poll or select syscalls, because:
    • It mandates that the FDs will trigger by level (as opposed to by edge). This is what poll and select are capable of as well.
    • It defines that the triggering will be one-shot (as opposed to multi-shot), even though it maintains a state of registered FDs, like e.g. epoll. (So if you would like to listen on a FD again once it was 'set', you have to re-register it)
  • In comparison, tokio uses mio, whose poller has a different semantics:
    • It mandates that the FDs should use edge-triggering. While this type of triggering is supported natively by epoll, it isn't supported with poll or select. Im unsure how easy it is to emulate edge triggering on top of level triggering, and whether just reporting on level triggering when the framework expects edge triggering would be tolerable (as in having extra noise, but no semantic side effects)
    • It mandates that the registered FDs are "multishot". Meaning, once you register an FD with the poller, it will "fire" etch time it changes its level. While this is possible to emulate with poll / select, there is this non-trivial case where a registered file descriptor is closed while still being registered. epoll would handle that just fine, but poll and select won't. So unless the mio framework itself has hooks to de-register a FD from the poller when its Rust wrapper is drop-ed (to be checked), we can't really workaround the closing behavior.

TLS

• No progress yet, plan is to try to map rust-native-tls to ESP-IDF via the OpenSSL unofficial ESP-IDF APIs and if necessary, enrich those with patches against ESP-IDF

Native build

• Possible to build ESP-IDF master now!
• Still have to apply one atomics patch though. Fixes issues Missing __atomic_load & __atomic_store intrinsics' implementation for esp32c3 (& maybe esp32s2) (IDFGH-5896) espressif/esp-idf#7591 and Missing __sync_lock_test_and_set_ intrinsic for esp32s2 (IDFGH-5897) espressif/esp-idf#7592
  • UPDATE: Since @igrr asked me during the meeting: complete overview regarding what patching is necessary to ESP-IDF master & V4.3 for Rust-STD support
• Next step: we need cargo idf menuconfig tooling, for easier alteration of sdkconfig / sdkconfig.defaults

RwLock

• Any progress on pthread rwlock implementation in ESP-IDF?

Other stuff with no updates (sorry!)

• Ongoing research on generating proper backtraces on Rust errors (not panics)
• (WIP) Rust OTA bindings
• (WIP) Exposing safe Rust bindings for ESP-IDF HTTP client & MQTT client