Rust ESP32 Community Meeting 2021-10-26

[georgik]

Please add topics and links to this discussion.

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

[ivmarkov]

I won't be able to attend this instance.
Short update from my side:

• Rust typesafe wrappers for ESP32 Ethernet (and corresponding traits in embedded-svc) here. Demo updated as well.

  • The RMII ones still need testing (board is on its way), but the SPI ones and the QEMU one should work fine

• QEMU support (side effect from the Ethernet drivers implementation). Demo updated.

• CI and crates.io Publish GitHub actions for all esp-idf-* crates and for embuild

• The rust-esp32-std-hello crate is now renamed to rust-esp32-std-demo, as it is not really a "Hello, world!" style of crate but more like a full demo of everything available in the Rust STD ESP-IDF world.

  • TODO: Need to implement a CMake-first and PIO-first compilation option as well

• New crate, rust-esp32-std-mini, which is now THE "Hello, world" crate for ESP-IDF + Rust + STD. Should also serve as a "new project" template for a clean start and shows the minimum plumbing necessary for ESP-IDF + Rust + STD + cargo-first to compile.

  • TODO: Need to implement a CMake-first and PIO-first compilation option as well

• WIP items, not ready for preview yet:

  • Some small progress on OTA with typesafe Rust + using GitHub Releases as an OTA service
  • esp32s3 support in esp-idf-hal

• Open topic: Now that ESP-IDF 4.4 is branched off from master, what are the chances of the pthread_rwlock initial implementation hitting this branch? This would allow us to get rid of the esp_idf_sys::link_patches() hack in rust-esp32-std-mini bootstrapping code and in general, we would be closing the final gap in Rust STD support for the ESP-IDF.

[igrr]

pthread_rwlock is close to being merged into esp-idf master, we will backport it to release/v4.4 as well!

[jessebraham]

bare metal

xtensa-lx-rt

• We had hoped that the lx6 feature would suffice for the ESP32-S2/S3, however this does not seem to be the case
  • See this gist: https://gist.github.com/jessebraham/085edc8e45e681a0b84e6ade10ebfe3b

svd

• I still don't have access to hardware descriptions for many peripherals, not sure how to move forward with these
• Current SVDs need some way to verify their contents, so higher-level code is required (see esp-hal below)
• I began work on the ESP32-S3 SVD, but it still has quite a way to go

esp-hal

• I've started on a (very experimental) HAL to support more ESP32 variants
• At present consists of a monorepo with a common crate along with crates for each supported chip
• This HAL uses PACs generated from our SVDs, and as such helps verify and correct them
• Working well so far. Have a basic serial example working for the ESP32 and ESP32-C3 using shared implementations of peripherals.
• Working on adding the ESP32-S2 to the mix
  • Linker scripts are hard
  • xtensa-lx-rt needs updating

espflash

• PR opened to support added for ESP32-S3
• Serial port detection PR still in draft form
  • still need to determine which VID/PID combinations will be accepted
  • waiting for an issue to be resolved before I do any major reworking
    • Consolidate command-line argument parsing between two crates espflash#77
• I will (likely) be working on QEMU support this week
  • QEMU support espflash#79
  • waiting on same issue as above

[georgik]

Updates:

• build of 1.56.0 - https://github.com/esp-rs/rust-build/tree/build/1.56
• many build issues, GitHub runners were not able to build any OS flavor of 1.56.0, all builds were executed locally
• improved installation script .sh
• improved testing in CI - local and GitHub runners

Question:

• how to handle versioning? There is always initial build and at least one additional build
  • 1.56.0-dev should be renamed to 1.56.0.0 and subsequent build 1.56.0.1 or directly go to 1.56.1?

[georgik]

Options: -rc suffix, timestamp/date, version minor 1.56.0.1

[georgik]

Decision from community: 1.57.0.1, 1.57.0.2.... 1.57.0.42

[N3xed]

esp-idf-sys native build

Tracking issue

• esp-idf installation logic moved to embuild (embuild::espidf::Installer)
  • Can now be used for other tools to detect and install the esp-idf source and tools.
  • esp-idf installation support embuild#21
• cmake now installed alongside the esp-idf
  • Previously, the cmake version in stable esp-idf was too old.
  • Solved by using a subset of the tools index json file of the esp-idf master branch which is embedded in embuild.
• Tools installation directory for the esp-idf and platformio build:
  • Defaults to a location in the binary crate.
  • Can be overridden with environment variable, either to a global default location or a user specific one.
  • Decide tools installation directory esp-idf-sys#11 (comment)

[MabezDev]

Compiler

• 1.56 rebase complete, with a few teething issues regarding builds.
• Removal of useless xtensa-none-elf target.
• Added s3 baremetal and espidf targets.

probe-rs

• Debugging issues not yet sorted, leaving this issue with maintainers.
• Hopefully a new release cut soon, with our flashing algo for c3 + fixes.

esp-idf

• missing atomic defintions needed for c3/s2 are now in master & will be in release v4.4.
• backport open for v4.3.
• rwlock impl complete, now in review.

llvm

• New release with fp instrinsics
• Re-occuring LLVM error, latest report here: LLVM ERROR: Error while trying to spill A9 from class AR #87