Rust ESP32 Community Meeting 2021-08-31

[georgik]

Please add topics and links to this discussion.

The meeting is scheduled 31th 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 notify us at https://matrix.to/#/#esp-rs-community-meetins:matrix.org

[georgik]

Updates:
Increasing visibility and preparation of Roadmap using GitHub Projects

• organisational level (quarters): https://github.com/orgs/esp-rs/projects/1
• Rust release related work (minor version of releases): https://github.com/esp-rs/rust/projects
• helper linked repository for backlog/task definition: https://github.com/esp-rs/esp-rs-backlog/issues

Rebasing for 1.55 scheduled after the release of official compiler: 9th Sept. 2021

• @JurajSadel - LLVM 12 from GitHub releases - https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa-installation-x86_64-unknown-linux-gnu.md#installation-commands

Discussion
Simplification of onboarding

• discussion about examples
  • move of espressif/rust-esp32-example to esp-rs? Consolidate features from other repos?
  • cargo first approach
  • CI job in example repo can serve as validation of compiler compatibility - partialy implemented in espressif/rust-esp32-example
• list available components (in IDF sense) in Rust
• getting started guides - @pedrominatel

[ivmarkov]

Updates:

• kconfig support in Rust: esp-idf-sys & crates depending on it can consume and branch on all boolean (a.k.a. tri-state) CONFIG_* settings supported by the ESP-IDF menuconfig system. A sample usage here.

• On-going work by @N3xed on native (non-PlatformIO) build for esp-idf-sys:

  • The cargo-pio crate is now renamed to embuild and is hosting various build utilities, primarily for interfacing with various build tools, like PlatformIO, but not only. The cmake utilities are expected to land here.

• Research on support for Rust backtraces with ESP-IDF

• Various small enhancements to esp-idf-svc: better support for all Wifi modes (AP, STA, Mixed); working NAPT (simple routing) in Rust

[jessebraham]

Bare metal:

• ESP32-C3 SVD has had a number of registers collected into arrays, various other fixes and improvements
  • Changes have been pushed to espressif/svd
• Preliminary ESP32-S2 SVD has been generated, working on verification and will release some time this week
  • xtensa-lx and xtensa-lx-rt crates need to be updated to support LX7 processors
    • xtensa-lx seems fairly trivial (see this PR), however this may not be the best level of abstraction
    • xtensa-lx-rt may be slightly more involved, but should be quite similar to the LX6 as far as I know
      • Upon some further digging, I'm struggling to find any differences between the LX6 and LX7 (see this commit). Is there anything I've missed here?
• Still no word from the owner of the esp32c3 repository/crate :( I will try another contact method now that some time has passed
  • See my fork/branch for the time being: https://github.com/jessebraham/esp32c3/tree/new-svd

Tools:

• Custom toolchain support with Rustup was initially looking promising, however my current opinion is that we will need to modify Rustup to support what we want (though there is always the possibility I'm missing something here...)
  • See: Remote Custom Toolchains rust-lang/rustup#2696
  • While you can specify a custom server and install from there, there's no way to tell Rustup that this toolchain is esp (see the quote below)
  • Rustup has no way of knowing from which source a toolchain was installed, so some form of registry is required
  • This whole process, unfortunately, doesn't seem straight-forward

Standard release channel toolchain names have the following form:

    <channel>[-<date>][-<host>]

    <channel>       = stable|beta|nightly|<major.minor>|<major.minor.patch>
    <date>          = YYYY-MM-DD
    <host>          = <target-triple>

'channel' is a named release channel, a major and minor version
number such as `1.42`, or a fully specified version number, such
as `1.42.0`. Channel names can be optionally appended with an
archive date, as in `nightly-2014-12-18`, in which case the
toolchain is downloaded from the archive for that date.

[MabezDev]

Bare metal

• Update esp32c3 experiments to use direct boot
  • This has identified some more limitations of the riscv-rt linker script around setting load addresses of certain sections. We could take a look at making the upstream linker script more flexible, or we could just maintain our own per device linker script (and still get all the benefits of riscv-rt)
  • I think with these issues ironed out we can start thinking about bare metal hal support.

Tooling

• Fix for attaching to esp32c3's debug module in probe-rs Read idcode bytes until non-zero bytes appear, or 1 second passes. probe-rs/probe-rs#784
• A working flash loader for the esp32c3: https://github.com/MabezDev/esp-flash-loader
  • Currently all probe-rs flash loaders must be compiled with -PIC as they could be loaded anywhere in ram, hence the weird addr2func casting (turns out linking absolute addresses to functions when using -PIC is a bad idea ) .
  • I'm working on a PR to probe-rs to allow a fixed load address (much like openocd's work space), then we don't need the -PIC option and we can link against ROM functions. Unfortunately blocked on Operation Status = Some(RequestInProgress) probe-rs/probe-rs#790 atm.
• Future work: Write a driver, then add probe support for the builtin jtag of some esp chips, reference driver here.