Rust ESP32 Community Meeting 2023-01-05

[georgik]

Please add topics and links to this discussion.

The meeting is scheduled for 5th 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.

[jessebraham]

ESP-PACS

• Fix the CI badge in the README, other small updates
  • Fix the CI badge in the README, other small updates esp-pacs#65
• Change CAN to TWAI where applicable in the SYSTEM peripheral
  • Change CAN to TWAI where applicable in the SYSTEM peripheral esp-pacs#66
• Update xtask dependencies and regenerate PACs using latest svd2rust
  • Update xtask dependencies and regenerate PACs using latest svd2rust esp-pacs#68
• New releases for esp32, esp32c3, esp32s2, and esp32s3
  • New releases for esp32, esp32c3, esp32s2, and esp32s3 esp-pacs#69 ^(nice)
  • https://crates.io/crates/esp32/0.18.0
  • https://crates.io/crates/esp32c3/0.9.0
  • https://crates.io/crates/esp32s2/0.8.0
  • https://crates.io/crates/esp32s3/0.12.0

ESP-HAL

• Reviewed/merged TWAI support for ESP32-S3
  • enable TWAI on ESP32-S3 esp-hal#325
• Use the latest PACs
  • Use the latest PACs esp-hal#331

ESPFLASH

• Make the flasher return a struct of device information instead of printing directly
  • Make the flasher return a struct of device information instead of printing directly espflash#328

TT21100

• Created a no_std driver for the TT21100 multi-touch touchscreen controller found in the ESP32-S3-BOX
  • https://crates.io/crates/tt21100/0.1.0
  • https://github.com/jessebraham/tt21100
  • A couple "issues" still need sorting:
    • The display is installed in an inverted orientation, but the touch controller is not aware of this
    • I seem to get multiple events for the same touch, maybe need to configure some sort of debouncing?
    • I have requested a datasheet from Parade Technologies, since I can't seem to find one online anywhere 🤷🏻‍♂️

UPCOMING/IN-PROGRESS PROJECTS

• Major overhaul of The Rust on ESP Book is required
  • Tracking the overhaul and re-organization of the book book#59
• New releases of esp-hal
  • We should wait for this until TWAI is completed for all chips, and also probably for the PCNT PR to get merged
    • I have made the required changes to add TWAI support for ESP32 and ESP32-S2 locally, however they're not working so I have some troubleshooting to do before I can PR the changes
  • @mabez still needs to do a bit of cleanup with regards to the PeripheralRef changes IIRC as well
  • Anything else we want to squeeze in to these releases?
• Finish adding ESP32-C6 support to esp-hal
  • I've got a reasonable start on this, almost at the point where we can start adding actual examples
  • I think @JurajSadel will be helping me with this!
• Add async support to esp-hal
  • This will likely be a group effort, so hopefully this can be completed in Q1
  • I would like to schedule a meeting to discuss this at some point in the coming weeks
• Begin investigating (and implementing) support for low power/deep sleep modes
  • I know very little about this so there will need to be a brief research period before I even know what's involved
  • Will likely begin with the ESP32-S3 to take advantage of the RISC-V ULP
• Get a 2.0.0 release of espflash published
  • Still a couple non-trivial changes to make, but I think we're reasonably close to "done"
  • Burnt myself out on the project so I took ~1 month off, time to get back at it 🙃

[georgik]

Experiments

Multiple targets in one project

• Template for boostrapping development for multiple targets - https://github.com/georgik/esp32-rust-multi-target-template
• cargo generate https://github.com/georgik/esp32-rust-multi-target-template.git

ESP-IDF project with a Rust Bare Metal (no_std) component

• https://github.com/georgik/esp32-project-with-rust-component
• binding generated via cbindgen
• linked with .rlib

[SergioGasquez]

Rust installer

espup

• add: CLI option to specify config path espup#127
• Fix logs espup#126
• Add unit tests espup#124
• Fix install help documentation espup#122 - Improve description of arguments and errors when using them incorrectly espup#121
• Update uninstall command espup#120
• Install GCC toolchain for ULP coprocessors espup#115 - Install RISC-V GCC toolchain for ESP32S2 and ESP32S3 espup#109
• Improve LLVM uninstall espup#114 - Improve LLVM uninstall espup#112
• Fix Windows exports espup#111 - Windows - export-esp.ps1 contains path with mixed / and \ espup#97
• Add possibles values to default_host arguments espup#110
• Feature/async espup#108
• Fix RiscV installation/uninstallation espup#107 - uninstall command fails when using multiple RiscV targets espup#106
  I will publish a new release as soon as we solve the GitHub CI error (Details bellow)

Xtensa Toolchain Action

• Improve ci xtensa-toolchain#18
• Minify espup installation xtensa-toolchain#19

Book

• Add instructions for using QEMU book#58
• Major update planned with @jessebraham. See Tracking the overhaul and re-organization of the book book#59
  • Feedback/suggestions are more than welcome!

CI error

• We are still encountering random failures on the CI (Increased rate of transient failures in recent weeks xtensa-toolchain#15). For some reason, querying GitHub API sometimes fails when querying from the GitHub CI.
  • We see the same behaviour in xtensa-toolchain action and in espup.
  • We can't reproduce this behaviour in our host machines
  • We tried different headers with no luck so far

[SergioGasquez]

From docs:

For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the person making requests.

When using GITHUB_TOKEN, the rate limit is 1,000 requests per hour per repository. For requests to resources that belong to an enterprise account on GitHub.com, GitHub Enterprise Cloud's rate limit applies, and the limit is 15,000 requests per hour per repository.

[jessebraham]

This still seems fishy to me. I was able to run >100 queries in rapid succession locally, without using the token, and I didn't experience a single error. I've also had the CI fail when no other jobs had been run that day.

[SergioGasquez]

I was able to reproduce it locally: Ran the test 100 times and I was able to hit the limit and get the same JSON returned.

I still agree with @jessebraham, sometimes we saw the error when we were not querying the GitHub API that often, and in theory, the limit should be 1000 as we are using the GITHUB_TOKEN

[bjoernQ]

That thing about the local case is strange ... however, on GH runners there could be other jobs (from other repos) doing API request from the same IP before I guess - just a guess. When the request is authenticated, I think they don't limit it on the IP but on the account 🤷‍♂️

[SergioGasquez]

Did a quick test and increased the number of times the curl call was executed in the CI to 1500, somehow the action still succeeded

[bjoernQ]

esp-wifi

• basic power safe mode (ps_min_modem)

  • Use WIFI_PS_MIN_MODEM as power safe type esp-wifi-sys#77

• BTLE for ESP32-S3

  • BTLE for ESP32-S3 esp-wifi-sys#105
  • also seems to fix lld_pdu.c assertions running BLE example on esp32 chip esp-wifi-sys#78
  • coex implemented but only works in opt-level 1 (i.e. we still experience mis-optimizations)

• update drivers

  • Update Drivers esp-wifi-sys#106
  • seems we got even more mis-optimizations now for ESP32-S3 👀

esp-flash

• fixed small issue with ESP32-C2
  • Fix monitor after flash for ESP32-C2 espflash#330

esp-hal

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

Other

• looked into that SPI DMA problem Jesse reported

  • only occurs with framebuf crate
  • just works for me
  • generally as long as the display drivers work as they do, DMA will be slower
    • e.g. in that test code SPI transfers are sometimes 1 or 2 bytes only
    • setting up the DMA transfer takes 8.5us while setting up a FIFO transfer only takes 6.5us

• briefly tried to run the blocking/std example in embedded-tls w/o success but didn't really try hard

• made my "Matter on bare-metal" experiments public on github, code is terrible and it doesn't work great and a lot is missing, but it gets through commissioning and can toggle an LED

  • https://github.com/bjoernQ/bare-matter
  • https://github.com/bjoernQ/esp-bare-matter

[MabezDev]

Happy new year folks :)

compiler

• Looking into f32::min etc cause linker errors on bare-metal #155
• First 10 LLVM patches have been committed upstream! - https://github.com/search?q=repo%3Allvm%2Fllvm-project+Xtensa&type=commits

esp-hal

• Nearly have the async GPIO driver ready for all chips, but currently blocked on GPIO incorrect interrupt status for pins > 32 esp-hal#332
• Failed experiment with GPIO hide implementation details esp-hal#322, the way we control pin types makes this very difficult to do, if/when we move away from the pins.gpio4.into_X() methods on GPIO types and instead use mode-based structs, i.e Input::new(pins.gpio4) it should be easier.

xtensa-lx-rt

• Allow disabling of asm sections per target-features xtensa-lx-rt#51

[JurajSadel]

esp-flasher-stub

• working on Replace dprint module with esp-println and log crate esp-flasher-stub#8
  • the first idea was we can replace dprint module with esp-println and log crate
  • esp-println works just with UART0, we need UART1 for debugging
  • the second idea is to keep dprint and put it behind a feature: JurajSadel/esp-flasher-stub@5145ac6
  • the final binary is a few KB smaller but the logging is not working correctly (haven't been working correctly for me from the beginning so I guess getting rid of a few KB is progress here 😅 )

[georgik]

Invitation to Rust Brno meeting on-site the next week:

• https://t.me/RustLangCZSK (Telegram)
• https://discord.com/invite/8E2YSECZst

[georgik]

The next meeting: 19th January - 5pm (GMT+1 a.k.a. Brno time )