Rust ESP32 Community Meeting 2023-05-25

[jessebraham]

Please add topics and links to this discussion.

The meeting is scheduled for 25th May 2023 - 5 pm CET/GMT+2 (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.

[daggerrz]

bjoernQ mentioned that RMT and LEDC might benefit from a rewrite. Goals / mentors available?

[bjoernQ]

Sorry haven't noticed this before

The general thing about these drivers is that their APIs are inconvenient and sometimes they can be used "in a wrong way" - e.g. esp-rs/esp-hal#116

Sometimes the APIs are also unnecessary limiting (like it would be nice to be able to dynamically change the LEDC timer frequency, however a difficulty in API design here is that multiple channels can share a timer)

For RMT: it's only output but input would be also useful for a few use-cases. It would be good to have an alternative constructor that takes the desired frequency (in addition to the one taking raw dividers). I think the pulse-length in PulseCode doesn't really work (i.e. the time given there isn't what you'll see on the output pin - but that might be already fixed).

As a bonus it would be nice if those drivers would use less macros

Not sure if it's easier to refactor the existing code or rewrite them (based on the existing code).

[daggerrz]

Thank for the info! I have some experience using the RMT APIs (both the C and Rust version), but less so with Rust Embedded API design in general. Any pointers to higher level APIs that can be considered to be great / ergonomic?

[georgik]

Rust Releases

• 1.69.0.0 - current release with LLVM 15 and GCC 8 - https://github.com/esp-rs/rust-build/releases/tag/v1.69.0.0
• 1.69.0.1 - evaluation release with new LLVM 16 and GCC 12 - https://github.com/esp-rs/rust-build/releases/tag/v1.69.0.1
• 1.70.0.0 - scheduled official full release with LLVM 16 and GCC 12 updates - around 3rd June 2023

Embedded Graphics 0.8

• official release of 0.8, embedded-graphics-core 0.4
• requires update of all crates which depends on it
• multiple versions in cargo tree causes type conflicts, make sure to have just one version
• PR to mipidsi + correction of ILI934x initialization (missing 5 ms delay after starting display) Update dependency Embedded Graphics Core to 0.4.0 almindor/mipidsi#58
  • note: board support package with LCD drivers in C is located at esp-bsp repo, good source of information for future Rust drivers: https://github.com/espressif/esp-bsp/tree/master/components/lcd
• PR to embedded-graphics-framebuf - Feature/embedded graphics 0.8 bernii/embedded-graphics-framebuf#18
• PR to embedded-graphics-web-simulator - Update to Embedded Graphics 0.8 rahul-thakoor/embedded-graphics-web-simulator#45
• updated Spooky Maze - Update to Embedded Graphics 0.8 georgik/esp32-spooky-maze-game#47
• update esp32-buddy-rs (ssd1306) - https://github.com/georgik/esp32-buddy-rs

Future Events

• MakerFaire - 10th-11th June - Prague - https://makerfaire.cz/mesto/praha/
• Rust CZ/SK Meetup Brno - 15th June
• Espressif DevCon 2023 - 12th-13th September - Call for papers - https://devcon.espressif.com/

Experiments

• AXP192 driver for M5Stack Core 2 - Add support for AXP192 - for M5Stack devices georgik/esp32-spooky-maze-game#48 - initial version, just turns on the display
  • note: in case of M5Stack Core2 becomes unresponsive to USB (e.g. incorrect configuration of AXP192) - connect GPIO 0 with the ground and start the device - this should turn on boot mode

[jessebraham]

ESP-HAL

• Improve the pre-commit hook esp-hal#532
• Add some miscellaneous examples for the ESP32-H2 esp-hal#548
• Add all SPI examples for the ESP32-H2 esp-hal#549
• Add interrupt-related examples for the ESP32-H2 esp-hal#557
• Correct a number of comments in various examples esp-hal#558
• Reviewed and merged a number of PRs
• Currently fighting with the ESP32-H2's clocks, which are not correct in the HAL right now

ESP-PACS

• New release for the esp32s3 package esp-pacs#116
  • https://crates.io/crates/esp32s3/0.18.1
• [esp32h2] Align TIMG* interrupt names with other devices esp-pacs#117
• Refactor the xtask package and implement a bump-version subcommand esp-pacs#120

EMBASSY

• Allow for an optional user-defined entry macro when targeting RISC-V embassy-rs/embassy#1463

[liebman]

ESP-PACS

Something handy when implementing various no-std HALs:

• Created a PR (WIP) of svd2rust implements Debug for registers during PAC generation.
• here is esp-pacs fork/branch implementing this (uses my svd2rust PR branch)

I've been using this to compare esp32/esp32s3 deep sleep RTC_CNTL registers between esp-idf-hal and esp-hal. Maybe it will be useful for others.

Just add impl-register-debug feature and override the specific esp-hal crate:

[dependencies]
esp32s3 = { version = "0.18.0", optional = true, features = ["impl-register-debug"] }

[patch.crates-io]
esp32s3 = { git = "https://github.com/liebman/esp-pacs.git", branch = "impl-debug-for-registers" }

Then you can

    info!("{:#?}", unsafe { &*RTC_CNTL::ptr() }.options0.read());

It's very much a work in progress.

Sample output:

I (487) esp_peripheral_dump::rtc_cntl: RTC_CNTL::OPTIONS0 {
    sw_stall_appcpu_c0: 0,
    sw_stall_procpu_c0: 0,
    bb_i2c_force_pd: false,
    bb_i2c_force_pu: false,
    bbpll_i2c_force_pd: false,
    bbpll_i2c_force_pu: false,
    bbpll_force_pd: false,
    bbpll_force_pu: false,
    xtl_force_pd: false,
    xtl_force_pu: false,
    xtl_en_wait: 2,
    xtl_force_iso: false,
    pll_force_iso: false,
    analog_force_iso: false,
    xtl_force_noiso: true,
    pll_force_noiso: true,
    analog_force_noiso: true,
    dg_wrap_force_rst: false,
    dg_wrap_force_norst: false,
}

[MabezDev]

compiler

• 1.69.0.1 released with LLVM 16
  • One small regression with LLVM16 + Xtensa + frame-pointers enabled
• C functions arguments wrong alignment #171 is now fixed
• Looking into Problems with C variadics #177

esp-hal

• Closed Level-triggered GPIO interrupts are firing multiple times esp-hal#535 via async gpio fixes esp-hal#537
• Also add support for async GPIO across cores: Support for multicore async GPIO: esp-hal#542
• In testing multi core GPIO, I found the API for running code on another core was a bit awkward - I wrote up some ideas to improve it here: Improve ergonomics of running code on the second core of dual core chips esp-hal#543

esp-wifi

• preempt improvements esp-wifi-sys#185 to fix some scheduler issues and improve performance
  • This PR also uncovered some weirdness around the ESP32 and the WIFI_BB interrupt

espflash

• Awaiting final review/merge: limit default partition size espflash#398

[JurajSadel]

esp-hal

• created a draft with ADC calibration C3: ADC raw values calibration esp-hal#550 (just raw values)
  - ADC raw values calibration esp-hal#555 (conversion to voltage)
• created H2: Add initial LEDC support with example esp-hal#560

esp-pacs

• LEDC alignment: esp32h2: Align LEDC registers  esp-pacs#122

miscellaneous

• started writing a second blog post

[SergioGasquez]

esp-hal

• Initial support for RSA in ESP32-H2 esp-hal#526
• Initial support for SHA in ESP32-H2 esp-hal#527
• Initial support for AES in ESP32-H2 esp-hal#528
• Add blinky_erased_pins example for ESP32-H2 esp-hal#530
• Improve examples documentation esp-hal#533
• Initial support for I2C in ESP32-H2 esp-hal#538
• Initial support for MCPWM in ESP32-H2 esp-hal#544
• Initial support for PCNT in ESP32-H2 esp-hal#551
• Initial support for RMT in ESP32-H2 esp-hal#556
• Testing other ESP32-H2 features
• Tried to debug ESP32-H2 clocks

esp-idf-template

• Fix cargo template esp-idf-template#120

esp-pacs

• esp32h2: Align PCNT names with other devices esp-pacs#118
• esp32h2: Align RMT names with other devices  esp-pacs#121

espressif-trainings

• Update ESP-IDF to v4.4.4 std-training#181

espup

• Update LLVM and GCC espup#256
• Remove unused dependencies espup#258

wokwi-builders

• Fix cargo-generate installation wokwi/wokwi-builders#42

wokwi-ci-action

• Fix typo wokwi/wokwi-ci-action#1
• fix: Use fail_text input wokwi/wokwi-ci-action#2

Other

• Added Wokwi CI to wokwi-projects
  • Not very useful atm as it only checks that it prints Hello World

Discussions

• Update esp-idf-tempalte default ESP-IDF?
  • Shall we update the default ESP-IDF version to 5.0?
  • We need to add support for new chips
    • It requires some logic as not all chips support all ESP-IDF versions
• espup need to install gdb as it no longer comes with GCC: gdb missing since esp-12.2.0_20230208 espup#257
• Updates on LLD?

[Vollbrecht]

I think its not battle tested to set IDF 5 to the default one. Might wait a bit more for more feedback. Though related question should we support 5.0 alongside 5.1 or only support latest mayor version.

[playfulFence]

Wokwi

• Created repo with all my examples with CI action, that checks if they are all buildable (same as @SergioGasquez did)

esp-hal

• Started to work on I2S for ESP32-H2
• Tried to make direct boot work, no significant progress yet.

[bjoernQ]

esp-hal

• make interrupts work on second core

  • Bugfix/set vecbase for core1 esp-hal#536
  • also needed
    • Fix INTERRUPT_CORE1 for ESP32-S3 esp-pacs#115

• reviewed, tested and merged the LEDC fading PR

• S3: move PSRAM related functions to RAM

  • ESP32-S3: Move PSRAM functions to RAM esp-hal#546

• fix half-duplex SPI read in development mode

  • Fix half-duplex SPI read esp-hal#552

• initial support for Ipv6

  • Basic IPv6 Support esp-wifi-sys#181

esp-wifi

• fixed some DHCP related problems

  • Fix DHCP handling esp-wifi-sys#173

• Allow changing wifi mode after interface is created (e.g. STA -> AP, AP -> STA)

  • A way to update iface-config esp-wifi-sys#177

• Miscellaneous Small Things  esp-wifi-sys#186
  - update BLEPS
  - don't panic on full BT queue
  - a way to get individual HCI packets
  - activate embedded-svc feature when wifi feature is activated

Xtensa enabled Rust compiler

• opened Problems with C variadics #177
  • C variadics used in Rust don't work on Xtensa

bleps (aka the BLE stack we use for the examples)

• reviewed and merged PRs in BLEPS

  • Add support for several advertising properties bjoernQ/bleps#12
  • Add support for SCAN_RSP bjoernQ/bleps#13
  • Code refactoring and cleanup bjoernQ/bleps#11

• fix tests, update dependencies, improve error handling

  • Housekeeping bjoernQ/bleps#17

smoltcp

• seems impossible to receive a multicast UDP packet on port 67 with src_addr 0.0.0.0 - that is needed to implement a DHCP server
  • IPv4: Don't discard from unspecified src addresses smoltcp-rs/smoltcp#787

Other

• more experiments with matter-rs on bare-metal (still on Ivan's no-std branch)
  • can commission and control a device with Google Home

• looked into first steps for WiFi provisioning via BLE (still very early)