Rust ESP32 Community Meeting 2023-02-02

[jessebraham]

Please add topics and links to this discussion.

The meeting is scheduled for 2nd February 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]

espflash 2.x

• cargo espflash --release was replaced by cargo espflash flash --release in 2.x
• users of ESP32-C6 must upgrade to 2.x, backporting to 1.x is not plannd

Migration guides discussion

How to effectively handle migration in source code and configuration when breaking changes occurs. Is there any effective solution how to handle upgrades in project from older hal to newer hal? E.g. pac renamed to periprherals
Is there at least semi-automatic method for Rust like one can find in IntelliJ/Android studion when handling upgrades of Gradle?

[jessebraham]

These espflash changes happened in 2.0.0-rc.1 back in November.

[bjoernQ]

I can think of solutions like an VSCode plugin or some other semi-automated tool. However, I think it's a bit too early right now

We expect more breaking changes in APIs and tools, I guess (more in APIs especially until we reach 1.0.0, less in tools probably after 2.x.x) and such a tool would add a lot of effort to create and maintain

For sure we can help users by providing the relevant information in release notes

Maybe there are tools / plugins one can feed with migration rules but still, maintaining such rules add a lot of effort

Last not least I have some experience with the mentioned Android Studio plugins and in the end if the build files contained a lot of customization that tool often just did nothing or broke the build files completely

[georgik]

idf-installer 2.19

• https://github.com/espressif/idf-installer/releases/tag/online-2.19
• added support for deployment of Rust by espup
• deploying also all prerequisites like Windows SDK 11 or MinGW

• glue logic written in Pascal, should shift to espup after further rounds of testing
• binstall has several issues, including opening ports on Windows and reporting it by Defender, decision was to deploy binary crates by our code instead of binstall

[georgik]

CLion/IntelliJIdea integation

• install espflash 2.x
  cargo install cargo-espflash --git https://github.com/esp-rs/espflash.git
• specify esp as channel in rust-toolchain.toml
  • note: plugin does not support esp custom toolchain, the only way to use it is via rust-toolchain.toml file
• configure run action

cargo run gotcha

Situation:
cargo espflash flash - works, but cargo run fails

...     Running `espflash flash -p /dev/ttyACM1 target/xtensa-esp32s3-none-elf/debug/esp32_s3_box_test`
error: could not execute process `espflash flash -p /dev/ttyACM1 target/xtensa-esp32s3-none-elf/debug/esp32_s3_box_test` (never executed)

Solution: cargo install espflash

Reason:

• cargo espflash - requires cargo-espflash
• cargo run - requires espflash

Experiments

Update on experiments:

• Spooky - added M5Stack Core2 - display ok - IMU 6886 missing driver in Rust - https://github.com/georgik/esp32-spooky-maze-game
• Graphical template - minor updates - https://github.com/georgik/esp32-rust-multi-target-template

[bjoernQ]

esp-hal

• fix linker scripts for ESP32-C6 (for esp-idf bootloader mode)

• implement interrupt handling for ESP32-C6

  • quite different than ESP32-C3 / ESP32-C2
  • probably we should do some refactoring when ESP32-C6 support gets merged
  • will be very similar / same for ESP32-H2

• C6 CPU clock setting

  • there is no ROM function "esp_rom_regi2c_write_mask"
    • it's in code here: components\esp_rom\patches\esp_rom_regi2c_esp32c6.c
  • important finding from ESP-IDF "On ESP32C6, MSPI source clock's default HS divider leads to 120MHz, which is unusable before calibration......"

• ESP32-C6 RWDT and SWDT

• looked into Refactor the clock module, provide ROM functions via linker scripts esp-hal#353

  • Refactor the clock module, provide ROM functions via linker scripts esp-hal#353 (comment)

• DMA marker traits should be available for users to write generic code taking a channel etc.

  • Make DMA marker traits available to users esp-hal#356

esp-wifi

• ESP32-C3 BLE

  • ESP32-C2 BLE esp-wifi-sys#110
  • there is still one issue. ESP32-C2: Doesn't receive disconnect event after several connect / disconnect cycles esp-wifi-sys#114

• update esp-wifi to work with latest released HAL

  • Use latest published HALs and Xtensa toolchain esp-wifi-sys#112
  • again funny experience with 1.67 and opt-levels

• update BLE example to show reads/writes larger than MTU and notifications

  • Update BLE example esp-wifi-sys#113

• esp-now support (in progress)

  • maybe also adding async support right from the start

Other

• reviewed Jesse's updates to the IEEE 802.15.4 Rust driver - looks great

• https://github.com/bjoernQ/i2c-dummy-device

  • bit.-banging implementation to make it easy/possible to test edge cases (e.g. clock-stretching)
  • makes it easier to test I2C without needing a special I2C device

[jessebraham]

ESPUP

• Simplify handling of extra crates espup#169

XTENSA-ATOMIC-EMULATION-TRAP

• Use u32 instead of usize where applicable xtensa-atomic-emulation-trap#6

ESP-IDF-PART

• Miscellaneous improvements and cleanup esp-idf-part#14
• Improve validation, add an additional test case esp-idf-part#15
• Add a bit more documentation, including some basic examples esp-idf-part#16
• Published a new version, version 0.3.0
  • https://crates.io/crates/esp-idf-part/0.3.0/

ESP-RISCV-RT

• Since we were overriding much of the assembly in riscv-rt already, we've just made our own version of the crate instead
  • https://github.com/esp-rs/esp-riscv-rt
• Published the first release, version 0.1.0
  • https://crates.io/crates/esp-riscv-rt/0.1.0/

SVD / PAC

• Published new SVDs for ESP32-C2/C3/C6, ESP32-H2, and ESP32-S2/S3
• Use the esp-riscv-rt package instead of riscv-rt, update SVDs esp-pacs#83
• New releases for esp32c2, esp32c3, and esp32s2
  • https://crates.io/crates/esp32c2/0.7.0
  • https://crates.io/crates/esp32c3/0.10.0
  • https://crates.io/crates/esp32s2/0.10.0
• Switch from actions-rs/toolchain action to dtolnay/rust-toolchain esp-pacs#86
• Update xtask and its dependencies esp-pacs#87
• Use latest SVDs for ESP32-C6 and ESP32-H2 esp-pacs#88

ESP-HAL

• Refactor the clock module, provide ROM functions via linker scripts esp-hal#353
• Reviewed and merged support for AES accelerator
  • AES accelerator implementation esp-hal#348
• Published new releases for all HALs:
  • https://crates.io/crates/esp32-hal/0.8.0/
  • https://crates.io/crates/esp32c2-hal/0.3.0/
  • https://crates.io/crates/esp32c3-hal/0.5.0/
  • https://crates.io/crates/esp32s2-hal/0.5.0/
  • https://crates.io/crates/esp32s3-hal/0.5.0/
• Update the name of the INTERRUPT peripheral to INTERRUPT_CORE0 esp-hal#364
• Use the new esp-riscv-rt package for RISC-V HALs esp-hal#365
• Fix the references to the ets_update_cpu_frequency_rom ROM function esp-hal#374

ON-THE-GO / BLOCKED

• Fairly significant refactor of esp-hal-common codebase
• Fairly significant refactor of esp-wifi codebase
• Preliminary ESP32-H2 support in esp-hal

[SergioGasquez]

espup

• Improve rust-src-nightly/install.sh command espup#162
• fix: bash path espup#161
• Statically link openssl for all Unix targets espup#153
• Update toml dependency espup#167
• Add ESP32-C6 support espup#155 once we have a HAL I'll test it and merge it
• Reviewed: Export CLANG_PATH so bindgen works with cross compilation espup#171 - See Unable to depend on any crate using cc or bindgen (std only) espup#163 for more information
• Inject Windows environment variables espup#166 - Needs to be tested

esp-template

• Bump hal versions esp-template#50

Other

• Update installation chapter book#62
• Fixed CI for a couple of repos:
  • Fix CI warnings esp-template#52
  • Fix CI warnings espup#177
  • Fix CI warnings espflash#350
  • Fix CI warnings esp-flasher-stub#16
  • Fix CI warnings esp-hal#379
• Add ignore dependency std-training#128
• IoT Solutions World Congress
  • Found several projects using ESP32 (Zamel, AWS)
  • People were interested in Rust (Cloudfare, hardwario and HiveMQ)

Discussions

• Where should espup install the different toolchains? espup#154
  • I would like to agree on a way to proceed.
  • Shall we keep espup minimal and let idf-env or idf-installerdo the fancy stuff? See this comment
• Jesse and I started using/testing GitHub projects board to track tasks:
  • Example board
  • We could do pretty much the same on esp-rs project and have a per-user and general views.
    • This could be very useful for the community to know what we are doing/will do and for us to know what other team members are working on.
    • This could be optional, maybe not all team members want to use GitHub as "Todo" list and also the granularity of the tasks can be different for everyone.
  • Projects offer some workflows to automate moving things arround

[SergioGasquez]

Just posted a comment to hold the votation: esp-rs/espup#154 feel free to vote your opinion!

[MabezDev]

compiler/toolchain

• 1.67 rebased - mostly a smooth release so far, just some esp-wifi issues
• Xtensa LLD is now shipped with our toolchain
• LLD is not a drop in for gnu ld, see Support lld linker esp-hal#357 for some required changes.
  • Overall LLD support is good, but there are some edge cases (compiling larger applications like esp-wifi results in relocation errors) that need fixing
• PSA LTO can do weird and wonderful things with backend bugs, we're disabling LTO completely (Note: this means lto = 'off') for esp-wifi Disable LTO esp-wifi-sys#116, I recommend this is done for other projects targeting Xtensa until the some of the backend issues are resolved.

esp-hal

• First Async driver landed - Async: GPIO esp-hal#333 🎉
• Added direct boot support for the C6 work @JurajSadel is working on - Add direct boot support for C6 JurajSadel/esp-hal#2
• Remove references to the imac target for C3 & C2, instead default to imc and enable atomics via compiler cfg: Remove references to imac target to avoid confusion. esp-hal#370
• follow up PR for S2: Preemptively add cfg's needed in upcoming releases for s2 esp-hal#371
• follow up PR for esp-template: Remove references to imac target to avoid confusion. Update atomic cfgs esp-template#51
• Allow debug interrupts in Xtensa critical sections: Allow Debug interrupts in Xtensa critical sections esp-hal#360
• Small DMA fix to stop interrupts on every descriptor: Only set the set_suc_eof flag on the last item esp-hal#359

xtensa-lx-rt

• LLD linker fixes xtensa-lx-rt#52

[JurajSadel]

esp-hal

• still working on adding C6 support
• big thanks to @bjoernQ, @jessebraham, @MabezDev for all the help
• added I2C, SPI, I2S, DMA - working fine with our examples
• LEDC, RMT - buildable but not yet 100% working
• RTC - WIP, not buildable, this one is tough
• ADC/DAC, MCPWM, PCNT, TWAI, AES not started yet

[georgik]

Proposal for the next meeting 16nd February 2023 - 5 pm CET/GMT+1