Rust ESP32 Community Meeting 2023-01-19

[jessebraham]

Please add topics and links to this discussion.

The meeting is scheduled for 19th January 2023 - 5 pm CET/GMT+1 (a.k.a. Brno time) 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 the previous meeting at https://github.com/esp-rs/rust/discussions

If you find a topic exciting, click Arrow Icon or Emoji, and your vote will give the preference to the topic.

[georgik]

Wokwi

• https://wokwi.com/rust - now displays number of Rust projects and also last projects
• there are more than 600 Rust projects on Wokwi

LiliGo T5 - PoC

• experimental bare metal implementation - partialy working https://github.com/georgik/esp32-rust-lilygo-t5-epaper
  

[MabezDev]

esp-idf-*

• @ivmarkov could I get your final review on MCPWM 5.0 esp-idf-hal#132
• Plans/Goals for the std approach
  • off the top of my head I have, expanding peripheral support and chip support (c2, c6) but I welcome other ideas

esp-hal/baremetal

• Async GPIO is ready, just waiting on a new compiler release for some missing nightly features on Xtensa - Async: GPIO esp-hal#333
• Explored async DMA and found some possible issues with the way we currently use the DMA in SPI & I2S but shouldn't be too much work to change.
• Traits with private bounds. esp-hal#345 we should analyze what traits are public/private and whether they should be or not.
  • If public, we should be reexporting in the chip hals
  • If we're worried about people trying to implement them, we can always seal them
• Make GPIO pins ZST's again - Remove the signals from the GPIO structs esp-hal#337
• Finish the PeripheralRef approach - Finish PeripheralRef esp-hal#334
• Allow disabling of asm sections per target-features xtensa-lx-rt#51 quick PR to xtensa lx rt which reads rustflags for target CPU features and disables asm in xtensa-lx-rt. This is useful for disabling currently buggy CPU features, like hardware loop optimization.

probe-rs

• https://github.com/esp-rs/esp-flash-loader/tree/feature/esp32c6-flash-algo WIP, just need to be able to test it on a direct-boot application soon :)

[ivmarkov]

esp-idf-*

• Plans/Goals for the std approach

  • off the top of my head I have, expanding peripheral support and chip support (c2, c6) but I welcome other ideas

Honestly speaking, I'm missing a bit on the roadmap topic not just for std, but also for no_std. Basically: what are the top priorities for a wider horizon (say, next 6 months to one year)?

If you have any materials on the roadmap topic that you could share, that would be really great!

Should that be a dedicated session in some of the next weeks btw?

As for concrete ideas / suggestions for a std roadmap (in no priority order):

• As you said - new chips: support for c2 / c6 (hopefully - very easy)
• Slim-down: only pay for what you use: i.e. if I only use e.g. the ESP IDF HAL drivers and don't use STD (posix, LwIP networking, event loop), I should get a much smaller firmware size. Not sure that's the case right now? ESP IDF is kind of going in that direction recently, I think
• (related to ^^^) Mix and match esp-* (the no_std ecosystem) with esp-idf-* (the std ecosystem); possible? hurdles? what is the gap?
• Async story:
  • Upstream the ESP IDF async support for the smol-rs crate ecosystem and for socket2 (networking)
  • Async story for the ESP IDF HAL drivers (spi, i2c, uart, etc.)
  • Make sure embassy works on top of the std stack
• ESP-IDF
  • More support for ESP IDF components that live out-of-tree (outside the ESP IDF repo)
  • Unclear: any outstanding build issues? Stuff that we want to improve in esp-idf-sys

[jessebraham]

XTENSA-TOOLCHAIN

• Various small tweaks/updates to the README xtensa-toolchain#21
• New release, version v1.5
  • https://github.com/esp-rs/xtensa-toolchain/releases/tag/v1.5.0

RISCV-ATOMIC-EMULATION-TRAP

• New release, version 0.3.1
  • https://crates.io/crates/riscv-atomic-emulation-trap/0.3.1

BOOK

• Rewrite the Introduction chapter book#61

ESP-IDF-PART

• Add no_std support esp-idf-part#9
• Indicate which types/functions/etc. require the std feature in the docs esp-idf-part#10
• Fix string formatting which was missed when adding no_std support esp-idf-part#11
• Published a new version, 0.2.0
  • https://crates.io/crates/esp-idf-part/0.2.0
• Fix partition type/subtype when deserializing from CSV esp-idf-part#13

SVD

• A bunch of clean up and improvements for ESP32-C6/H2
• Upstreamed a bunch of patches from esp-pacs
• Published new SVDs for all devices in espressif/svd

ESP-PACS

• Use latest xtensa-toolchain version esp-pacs#73
• Use latest SVDs and remove old patches esp-pacs#74
• Add the USB interrupt for the ESP32-S2/S3 esp-pacs#77
• Bump dependencies for RISC-V chips esp-pacs#78
• New releases for esp32, esp32c2, esp32c3, esp32s2, and esp32s3
  • https://crates.io/crates/esp32/0.19.0
  • https://crates.io/crates/esp32c2/0.6.1
  • https://crates.io/crates/esp32c3/0.9.1
  • https://crates.io/crates/esp32s2/0.9.0
  • https://crates.io/crates/esp32s3/0.13.0

ESP-HAL

• Rework/update the CI workflow
  • Rework the CI workflow esp-hal#343
  • Update xtensa-toolchain esp-hal#344
• Add a simple pre-commit git hook to verify each package's formatting esp-hal#347
• Update a number of dependencies to get RISC-V HALs building again esp-hal#350
• Refactor rtc_cntl module and add get_reset_reason function esp-hal#351

ESPFLASH

• Add an optional callback trait which can be implemented and provided to most flashing functions espflash#333
• CLI improvements and dependency updates espflash#334
• Use the flasher stub by default espflash#337
• Mark public enums as #[non_exhaustive] for semver compatibility espflash#338
• If a bootloader and/or partition table other than the defaults have been provided, indicate such espflash#339
• Published new releases for cargo-espflash and espflash, version 2.0.0-rc.3
  • https://github.com/esp-rs/espflash/releases/tag/v2.0.0-rc.3
  • https://crates.io/crates/cargo-espflash/2.0.0-rc.3
  • https://crates.io/crates/espflash/2.0.0-rc.3
• Organize, simplify, and generally improve the errors espflash#342
• No longer build releases for the Windows GNU target espflash#343
• Implement reset strategies espflash#344
• Remove the USB Serial JTAG watchdog workaround now that we use the stub espflash#345

[bjoernQ]

esp-hal

• GPIO incorrect interrupt status for pins > 32 esp-hal#332

  • Fix GPIO interrupts for pins > 31 esp-hal#335

• check DMA interrupt issues with Scott's POC example (the code used to set EOF bit for every linked-list item)

esp-wifi

• Update all drivers

• ESP32-C2 WiFi Support

  • WiFi for ESP32-C2 esp-wifi-sys#107

• ESP32-C2 BLE (in progress)

  • totally different than all others but apparently how the drivers for the later chips work
  • almost like starting from scratch

xtensa-toolchain-action

• looked into the issue about failing to install the Xtensa Rust toolchain
  • documented results here: Increased rate of transient failures in recent weeks xtensa-toolchain#15 (comment)

Other

• adapt the ESP32 ULP-FSM experiment to the current published HAL

  • https://github.com/bjoernQ/esp32-ulp-rust-macro
  • do we want to have something like that in esp-hal - or maybe keep this a separate crate and add support to control the FSM-ULP to esp-hal?

• bleps (the toy BLE stack used in the examples) learnt some new tricks

  • ReadBlobReq
  • PrepareWriteReq
  • ExecuteWriteReq
  • ATT_HANDLE_VALUE_NTF (notifications)
  • not merged yet, not used yet in esp-wifi since it needs more testing

[SergioGasquez]

espup

A couple of new releases and a new one should be on the way!

• Update dependencies espup#150
• Update MSRV and dependencies espup#149
• Add MSRV check espup#144
• Improve source instructions espup#143
• Add installation retries espup#142
• Avoid spawning commands espup#137
• Format Windows export file espup#135
• Windows: Copy cargo.exe to the esp toolchain espup#145 - Solves Running multiple cargos simultaneously with linked toolchain under windows rust-lang/rustup#2889
• Add note about ESP-IDF instalaltion methods espup#151

ESP Templates

esp-template

• Facilitate including new chips. Improve format and CI esp-template#44

Xtensa toolchain

• Fix transient errors xtensa-toolchain#20 - Finally closed! Thanks @bjoernQ @jessebraham!

Updated the action in a bunch of repos to use the last release:

• Upgrade actions versions esp-backtrace#18
• Update xtensa-toolchain esp-println#34
• Update xtensa-toolchain esp-flasher-stub#13
• Update xtensa-toolchain esp-idf-sys#162
• Update xtensa-toolchain action esp-idf-hal#206

Discussion

Where should espup install the different toolchains?

1. In $RUSTUP_HOME/toolchain/esp

• It would be a breaking change
• It would differ from how things are done in rust-build script

2. Keep it under $HOME/.espressif/

What are we installing at the moment:

• espup install will deploy:
  • Xtensa Rust toolchain
  • LLVM (if using --profile-minimal only libs)
  • GCC for all the targets
• espup install -e/--esp-idf-version <VERSION> will deploy:
  • Xtensa Rust toolchain
  • LLVM (if using --profile-minimal only libs)
  • ESP-IDF (which also install GCC)
  • ldproxy

esp-template restructure (esp-rs/esp-template#45)

• Any opinion/suggestion?

[JurajSadel]

esp-flasher-stub

• Replace dprint module with esp-println and log crate esp-flasher-stub#8
  • the default build is now without dprint module
  • logging works on all chips
  • added explicit clocks for C2, C3 and S3 chips
  • need to investigate why ESP32 and S2 work just with boot_defaults

esp-hal

• continue working on @jessebraham's work on adding support for C6
• already a bunch of peripherals are working: clocks, gpio, uart, timers, ..
• currently working on interrupts but hit some linker issues