Rust ESP32 Community Meeting 2021-08-17

[georgik]

Please add topics and links to this discussion.

The meeting is scheduled 17th August 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 let me know.

[MabezDev]

• asm! support in the Rust compiler for the Xtensa arch
  • Upstream rust is deprecating llvm_asm!has completely revamped the old global_asm! to use the new asm! syntax which has broken bare metal Xtensa builds.
  • Need to support new asm! syntax in the Rust compiler (PR Xtensa asm! implementation #68)
• rwlock support in idf? - tracking issue
• esp32-hal new release - look into esp32c3 next, now that we have an SVD?
• Fix riscv-rt for esp32c3 - here is a work around MabezDev/riscv-rt@6b55e4a
• Documentation
  • Revamp quick start guide
  • Merge examples
  • Roadmap
• Compiler versioning
  • Timestamp?

[georgik]

CI build of images: https://github.com/georgik/idf-rust-build

• macOS x64 - GitHub Runner
• linux x64 - GitHub Runner
• win x64 - self-hosted GitHub Runner, because workaround of buggy build requires more than 20 GB
• macOS M1 - manual build, because using custom llvm-project requires manual exclusion in submodules, so the Rust is not pulling there version from GitHub, but using patched version of LLVM 12, llvm-root option does not solve the problem

Update on Windows - discovered following build issues:

• build must be executed on shortest path possible, e.g. C:/r
• when assembling custom artifact, make sure that you do not recursively copy rustlib/src which contains symlink to the project folder itself, the result is recursion

Docker images:

• CI image: docker run -it espressif/idf-rust
• GitHub action: https://github.com/marketplace/actions/espressif-iot-development-framework-esp-idf?version=rust-latest
• image with examples: docker run -it espressif/idf-rust-examples

[ivmarkov]

Rust LibStd:

• Now that it is merged upstream, we need CI Actions that are building - ideally each night:

  • The stable, beta and nightly channels of the compiler
  • Only the STD library needs to be build, not the whole compiler (or LLVM) - takes a couple of minutes at most
  • The STD lib needs to be build with the riscvimc-esp-espidf target
  • Necessary, because the target is only Tier 3, i.e. Rust folks will not build and test this target for us (and its libStd support)

• Following work necessary to complete this support (completely on the ESP-IDF side):

  • pthread-rwlock- support, as per @MabezDev above
  • Some __sync primitives are missing (necessary for the s2 chip, not for riscv it seems)
  • Backport of esp32c3 atomics to 4.3?
  • Backport of the pthread destructor fix to 4.3?
  • (Low prio) foctl(FD_FUPFD, ...) support. Enables TcpStream::try_clone in Rust

• Targeting esp32-c3/h2 (RiscV) + ESP-IDF with Stock Nightly Rust & Clang stable

  • It is now possible to use standard, upstream compilers to target the ESP RiscV chips with LibStd (no need to fork Rust and/or clang):
    • Recent stock stable clang versions work for me (tried with clang12)
    • Recent Rust nightly (1.56) works for me (rustup default nightly + rustup update)

• Targeting esp32-c3/h2 (RiscV) + ESP-IDF with Stock Stable Rust & Cargo

  • Good news: 2 out of 3 unstable Cargo features we are using in our cargo-first build just got stabilized in 1.56!:
    • configurable-env
    • extra-link-arg
    • The Cargo build-std feature however remains unstable for now. If we want to target ESP RiscV chips with stable Rust, we need to find a "stable" replacement for it. Perhaps if we enhance cargo-xbuild so that it can (a) also build libStd (it only builds Rust core ATM) and (b) make sure it works with cargo stable, we'll have a story with stock Stable Rust too

• cargo-first build with "native" ESP-IDF

  • @N3xed working on that. Some issues with linker command line generated by cmake becoming a bit too long on Windows

• riscv32 esp32s2 ULP support:

  • Can somebody take a look at this startup code? Seems that there is still an invalid instruction there that generates a trap?

[igrr]

@ivmarkov one question about atomics emulation. My understanding was that since rust-lang#87666 was merged with support for riscv32imc-esp-espidf target, we no longer need atomics emulation in IDF since Rust compiler will always emit libcalls instead of atomic instructions.

I have actually closed the internal MR as I thought it is no longer required. If this is incorrect I can reopen it, get it merged to master and then backport to release/v4.3.

[ivmarkov]

@ivmarkov one question about atomics emulation. My understanding was that since rust-lang#87666 was merged with support for riscv32imc-esp-espidf target, we no longer need atomics emulation in IDF since Rust compiler will always emit libcalls instead of atomic instructions.

I have actually closed the internal MR as I thought it is no longer required. If this is incorrect I can reopen it, get it merged to master and then backport to release/v4.3.

@igrr You are completely right - we no longer need the atomic emulation for RiscV. The confusion came because I provided the wrong link above (now corrected). I really meant this one. My point is, the __atomic implementations for RiscV are only in ESP-IDF master. We might want to backport them to 4.3, that is - unless the 4.4 release is imminent? Currently for 4.3 I have my own implementation (in Rust), but ideally, we should retire it.

[igrr]

Ah, check, I'll backport it to release/v4.3. Might be a bit late for 4.3.1, which is in QA already, but it'll eventually get into the next bugfix release.

Is it okay if I commit this patch of yours as well? Or you are welcome to open a PR on Github if you prefer.

[ivmarkov]

No prob - you can commit. Just one caveat - there are no unit tests for that code. :)

[georgik]

Request for recommendations: How to open our meetings, so that attendees can join more easily?
E.g.: Rust Linz is using MeetUp, Youtube and Discord: https://rust-linz.at/

[ivmarkov]

@georgik Sorry for spoiling this topic - if you can take a look at the personal message I've sent you in the esp-rs chat - thanks!

[jessebraham]

Nothing too exciting from me, but some various updates:

• SVD generator has received some further improvements, but further progress is semi-blocked by internal issues. Updated version will be pushed to public repo when issues are resolved.
  • register/field names have been simplified
  • additional information such as access and reset values added
  • would like to collect more registers into arrays still
  • further specification compliance imrovements
• Still have not heard back from the esp32c3 repo owner
  • main issue here is the name being taken on crates.io
  • my fork has been updated with the most recent public SVD
  • I have updated the device.x file to (hopefully) be correct for this chip
• Have started working on compression for espflash

[georgik]

Discussion for the next meeting 30th August 2021 created: #74