Rust ESP32 Community Meeting 2021-07-13

[georgik]

(Migrated from archive espressif/rust)

georgik:
Hi. Let me invite you to a discussion about topics for Rust ESP32 Community Meeting.
Please, suggest the topic that you'd like to discuss.

Topics:

• Fork of Rust under Espressif umbrella - strategy to pick merge changes to Rust and fixing part of ESP-IDF
• Docker image with Rust layer for Xtensa
• GitHub Action to build ESP32 binaries with Rust
• Limitation of RISC Atomics - changes to ESP-IDF

---

ivmarkov:
Great topics!
Here's my list of additional ones:

• Long-term strategy for working with ESP32 peripherals from Rust in a safe way (i.e. implementation of embedded-hal for ESP32). Would it be possible to use (potentially with some customization) the esp32-hal crate together with ESP-IDF+FreeRTOS, or do we need something like esp-idf-hal where the embedded-hal traits are implemented on top of the ESP-IDF drivers?
• Long-term strategy for exposing safe Rust APIs for ESP-IDF functionality which are not exposed via Rust STD. These are usually APIs that sit "in-between" the HAL APIs from above and the standard Rust STD APIs for filesystem, thread and networking access. Examples: Configuration of Wifi, BLE and Eth; NVS key-value dictionary; Rust log::* APIs bridged to ESP-IDF logging service; Flash read/write (for OTA). The list might grow over time, but we probably need at least these initially, as they don't have pure Rust implementations. Current WIP in embedded-svc and esp-idf-svc.
• Long term strategy for "Cargo-first" builds. Current proof of concept here.
• Review of the ESP-IDF-related changes to the Rust STD codebase
  • An Espressif software engineer with deep expertise in ESP-IDF looking at those would be deeply appreciated
  • Objective 1: verify the correctness of the changes
  • Objective 2: minimize the change surface, by moving some of the changes to the ESP-IDF itself. That would increase the chances of these changes being accepted upstream.

---

MabezDev:
I think @ivmarkov has most of the idf/std related topics covered, so I'll mention a few unrelated to those!

• Bare metal applications on Espressif chips
  • SVD's to auto generate register access code for each of the chips
  • How to abstract over differences between the chips for common drivers, like GPIO, some chips have more, some less - some are split across multiple register banks.
  • WiFi/Bluetooth - interfacing with the binary blobs
    • Managing this interface on single core chips? Perhaps a good use case for async/await and or generators (think the classic yield() function in the esp8266 arduino core)
• Upstreaming strategy
  • The status of the llvm xtensa patches
  • Starting the upstreaming process before xtensa support lands in llvm
    • There is no reason why we couldn't push for riscv esp targets to be accepted upstream
    • The earlier we try the earlier we can get feedback/direction from the Rust team
• Thoughts on https://github.com/antoyo/rustc_codegen_gcc

---

jamesmunns:
I think @ivmarkov has most of the idf/std related topics covered, so I'll mention a few unrelated to those!

• Bare metal applications on Espressif chips
  • SVD's to auto generate register access code for each of the chips
  • How to abstract over differences between the chips for common drivers, like GPIO, some chips have more, some less - some are split across multiple register banks.
  • WiFi/Bluetooth - interfacing with the binary blobs
    • Managing this interface on single core chips? Perhaps a good use case for async/await and or generators (think the classic yield() function in the esp8266 arduino core)
• Upstreaming strategy
  • The status of the llvm xtensa patches
  • Starting the upstreaming process before xtensa support lands in llvm
    • There is no reason why we couldn't push for riscv esp targets to be accepted upstream
    • The earlier we try the earlier we can get feedback/direction from the Rust team
• Thoughts on https://github.com/antoyo/rustc_codegen_gcc

---

georgik:
Hi @jamesmunns . Great! I've sent you the email with the link.

---

georgik:

Meeting minutes

• solution layers:

project with Rust
custom Rust toolchain
llvm-project + clang
operating system

Operating system

• Linux - e.g. Ubuntu 18 and 20, Docker with esp-idf base image
• macOS - x64, aarch64
• Windows - x64

llvm-project

• current state: manual build with clang available as ZIP artifact
• CI build and update to version 12 in progress

Custom Rust toolchain

• current state: manual build of ivmarkov repo available as ZIP artifact
• architectures:
  • RISC-V - problem with STD Atomics igrr will provide updates
  • Xtensa - patched Rust toolchain

Project with Rust

• possible approaches:
  • cargo first - POC by ivmarkov
  • idf.py first - POC by igrr
  • pio first

Discussion

Patch with Atomics:

• ZIP in issue Issue compiling for ESP32-C3 (AtomicUsize used in std_detect) espressif/rust-esp32-example#3

Should we support std or no_std?

Std should be supported in the short term, because of WiFi integration.
Hint for prioritizations: Select tasks which help both std and no_std case.

Embedded HAL

Project: https://crates.io/crates/embedded-hal

Suggestion: participate in embedded-hal discussion.

Location of Rust fork

Current solution: https://github.com/espressif/rust

Could be moved to the organization: https://github.com/esp-rs , requires to setup permission

Next meeting

2021-07-20 - 4pm CEST