Rust ESP32 Community Meeting 2022-06-28

[georgik]

Please add topics and links to this discussion.

The meeting is scheduled 28th June 2022 - 8pm CEST/GMT+2 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 previous meeting at https://github.com/esp-rs/rust/discussions

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

[MabezDev]

• Status of External components discussion esp-idf-sys#72
• Embassy
  • Xtensa Executor merged
  • RISCV Executor merged
  • embassy::time::Driver implementation for c3, s2, s3
• probe-rs
  • RISCV debug improvements - Part 1 probe-rs/probe-rs#1129 - Wayyyy better RISCV debugging
• Compiler: 1.62 compiler already rebased, ready for release

[georgik]

Rust toolchain 1.62.0.0

• pre-release available at https://github.com/esp-rs/rust-build/releases/tag/v1.62.0.0
• issues tracked by PR ci: update version to 1.62.0.0 rust-build#93
• updated Linux/macOS installer - several new features added by @SergioGasquez

Updates from Embedded World

• Interview with Amey Inamdar talks about Rust for ESP chips - https://youtu.be/DlcvM-3Ouq0?t=510
• ESP32-C3-DevKit-RUST-1 added to the list of available Dev Kits- https://espressif.com/en/products/devkits
• Ferrous Systems training - Rust on the new Espressif board - 15th Sept. - registration is open - https://ferrous-systems.com/go/trainings/esp32-c3-devkit-rust-1/

Rust Board

• repo: https://github.com/esp-rs/esp-rust-board
• will become available soon
• Espressif - search for Rust ;-)
• Aliexpress
• Mouser

Discussion: Recommendation for Embedded Web (or other) Server

• static content works well with STD and rust-embed
• retrieving dynamic content from other thread is problematic
• 'static lifetime in web server implementation makes dynamic content hard to retrieve
• possibilities for sharing states from core/main thread to web server thread (e.g. generating screenshot of emulator core using URL /screenshot.png)
  • channels - simplex communication (e.g. RustZX-ESP32 TCP Socket Keyboard feature)
  • cross-beam - duplex communication - suitable for small messages (e.g. RustZX-ESP32 WebServer feature)
  • Arcs and Mutexes - tedious construction for each shared structure, requires Copy for the struct
  • thread join - complex
• any simpler solutions? async?
• performance impact - STD solution seems to introduce additional CPU load

[ivmarkov]

Given that the http server URI handlers are
a) dispatched from another thread than the main one
b) in theory (but not in practice with the actual ESP-IDF implementation) executed by multiple threads simultaneously

... you need all data passed to a handler to be Send (because of point a from above) and Send +Sync (because of point b from above). We can lift point b maybe somehow, but that would still require data sent to a handler to be Send at least. And the moment you share it with another thread (might just be the main thread) Send + Sync. Thats not a peculiarity of our HTTP server code or STD, thats just how Rust works. Including in no_std, where async is not saving you from those issues, as you can still have multiple "threads" in the form of multie local executors that need to share state, for one.

[ivmarkov]

And Send + Sync is a much more basic construct than mutexes and arcs. Even without those, you still have to obey Send + Sync somehow. Mutexes give you one way to share state, and o e possible solution. Btw you can get rid of Arc if you put the Mutex in a 'static context.

[ivmarkov]

Some concrete comments inline.

Discussion: Recommendation for Embedded Web (or other) Server

• static content works well with STD and rust-embed
• retrieving dynamic content from other thread is problematic
• 'static lifetime in web server implementation makes dynamic content hard to retrieve

Can you elaborate on that, not sure what you mean?

• possibilities for sharing states from core/main thread to web server thread (e.g. generating screenshot of emulator core using URL /screenshot.png)

  • channels - simplex communication (e.g. RustZX-ESP32 TCP Socket Keyboard feature)
  • cross-beam - duplex communication - suitable for small messages (e.g. RustZX-ESP32 WebServer feature)

All of these - i hope you realize use mutexes, condvars and possibly arcs.

• Arcs and Mutexes - tedious construction for each shared structure, requires Copy for the struct

That's incorrect. There is no requirement besides 'static on the struct or other type you push into the mutex.

• thread join - complex

Can you elaborate? Not sure how thread joins apply here?

• any simpler solutions? async?

Well async + a completely sifferent approach to the web server, where there are no handlers and the user code is driving the http server explicitly in terms of accepting new connections might help.

• performance impact - STD solution seems to introduce additional CPU load

Would be interestung to see what is the main reason.

[georgik]

Is there other option? Like avoid threads at all? In this case I have just once core and having event loop is sufficient.

[ivmarkov]

Where would you spin this event loop?

If explicitly in your main, then sure - you avoid threads. But you'll likely need to handle new incoming requests simultaneously and await on all of them. You win simplicity in one place and get complexity in another.

I guess getting by without understanding Send and Sync can only get newbies that far. At a point it becomes unavoidable.

Also - arent you overestimating the restrictions imposed by 'static? If you point me to an example, perhaps I can look into what you are struggling with.

[bjoernQ]

esp-alloc

• PR https://github.com/jessebraham/esp-wifi/pull/1
  • first step to use it in esp-wifi

esp-println

• PR merged to optionally provide a logger implementation

esp-hal

• added functionality to read a small selection of efuse data
• fix RMT driver
  • looked like a bug in svd2rust but turned out it is working as intended (but not working as one would expect)
• fix More re-exports in the chip specific HALs needed esp-hal#68
• fix Make it possible to use a PIN configured as open-drain as an input esp-hal#67
• refactoring of the GPIO macros
• first steps regarding clock config (not actually configuring the clocks but having a data structure containing clock rates to be used by drivers)
• bugfix: I2C SCL rate on ESP32-S2, ESP32
  • still on ESP32 the clock might be slightly off which is a known issue: https://www.esp32.com/viewtopic.php?f=14&t=1350 - usually shouldn't cause major problems

Other

• fixed a minor bug in svd2html (a tool we use to verify SVD patches)
• after the esp-hal fixes, the ESP32-C3 PS2 keyboard example now only needs 2 pins
• ported the PS2 keyboard example to ESP32
• experimental / POC implementation of embedded-async-hal traits
  • only GPIO input, only ESP32-C3
  • https://github.com/bjoernQ/esp32c3-async-rs-experiment
  • looks like a viable way to go

[SergioGasquez]

Ferrous System Training

• Fix ESP-IDF environment activation std-training#69 under review
• Working on improving the Dockerfile being used in Wokwi to have all the examples working in Wokwi.com

Rust installer

• Now supports installing wokwi-server and web-flash from the installer and it will use binary packages if possible: Add options to install wokwi-server and web-flash rust-build#87

Improvements for 1.62.0.0:

• Support --build-target all rust-build#92
• Installer improvements rust-build#88
  • Deleted unused code
  • Avoid installing Xtensa GCC as esp-idf installation takes care of it
  • Install only nightly toolchain for Xtensa targets, instead of stable and nightly
  • LLVM Clang is now only installed for Xtensa targets
  • Move the logic where we check if we need to install esp-idf
  • Update test-rust-toolchain CI to allow testing different git repos

Other

• ldproxy PR to generate binary package for aarch64-unknown-linux-gnu: Generate binary for aarch64-unknown-linux-gnu embuild#53
• Update esp-rs README: Add awesome-esp-rust repo and pacs .github#2
• Update MISO and CS pins to be optional esp-hal#89

Discussion

• As we now have support for devcontainers in both template repos: esp-idf-template and esp-template, esp-rs-devcontainer loses much of his value, it only contains useful documentation on how to integrate devcontainer in existing repositories.
  • Maybe we could use this repo for having a template Containerfile to have a reference to an updated Conatinerfile for devcontainers (as it was changing a lot in the past few months)
• Thanks to @JurajSadel for this idea

[jessebraham]

SVDs

• New SVD for the ESP32-S3 which actually includes the SYSTIMER peripheral
• A bunch of cleanup and simplification to our SVD generator, still in progress
  • Nothing visible to the community, but needed to be done. Will make my life less painful moving forward at least

ESP-HAL

• Began implementing the embedded-hal alpha traits in esp-hal
  • Begin implementing the embedded-hal alpha traits esp-hal#82
• Put embedded-hal alpha trait implementations behind a feature
  • Put the embedded-hal alpha trait implementations behind a feature esp-hal#88
• Assorted small refactors, dependency updates, cleanup, etc.

ESPFLASH

• Merged a new subcommand to flash binaries into espflash:
  • Add "write-bin-to-flash" subcommand espflash#194
• Merged a bugfix to ensure full file reads
  • Use read_to_end to eliminate partial reads espflash#199
• Implemented support for ESP32-C2 (locally)
  • Waiting for hardware to test/verify, should be here next week

Questions:

• I have a local branch using log/env_logger rather than just using println!(). Does anybody think this is worth merging?
• I've created a local branch which only updates the the flash mode/size/freq values if a digest has not been appended to the header, or if the `--dont-append-digest' flag is set
  • This eliminates a warning that you sometimes see printed from the second-stage bootloader about the digest not matching the expected value
  • I'm not sure if I want to merge this in its current form, and the digest is appended by default and as such you would always need to set the flag in normal use cases, which is annoying
  • How do we want to handle this?

OTHER

• Updated esp-pacs to use new SVD, automated updating the with_source branch
• Removed the docs/ and scripts/ directories from esp-template if not using dev containers
• Changed the panic handler to esp-backtrace for the esp-rust-board-bsp package
• Fix the icm42670 driver to also support the ICM42607 (mass-production version)
• Published the first release of esp-println
• Merged a community PR into serialport-rs to support USB composite devices
  • Support reporting usb interface serialport/serialport-rs#47

[ivmarkov]

embedded-svc

• All traits are now no-alloc friendly, so they should be possible to implement for bare metal with embassy
  • Hard dependency on heapless as a result, on heapless::String and heapless::Vec specifically; (lifetimed &str and &[slices] still used where this does not result in overwhelming complexity)
• The IO traits of embedded-svc now are just re-exports of the sync and async IO traits from embedded-io
• The HTTP server traits significantly simplified. The old HTTP Handler implementation that returned a Response is no longer available, as it cannot be made no-alloc friendly. Hopefully, the fn(Request, Response) alternative is now friendly enough to serve as a replacement
• Error associated types down-graded to Error: Debug or Error: embedded_io::Error
• In progress: RawMutex and RawCondvar traits, implementations and safe wrappers. Lifts the hard dependency on GAT-based associated types throughout the esp-idf-hal/esp-idf-svc like MutexFamily

[JurajSadel]

esp-hal

• ported LEDC from old esp32-hal with simple example -> except division calculation working on esp32, not full LEDC support: branch

esp-pacs

• patch LEDC registers access from read to read/write WIP: Patch LEDC access registers esp-pacs#27

esp-book

• add chapter regarding VSCode debugging using Cortex-Debug for esp32 and esp32c3 Add esp32 and esp32c3 VSCode debugging section book#30

Other stuff

• created Build failed unresolved import tokio::task::JoinSet, no FirmwareImageBuilder in elf MabezDev/wokwi-server#9 and created PRs with updated install command in Update wokwi-server install command georgik/rustzx-esp32#20 and Update wokwi-server install command  SergioGasquez/esp-rs-devcontainer#4

[playfulFence]

Rust-board working experience

• GPIOs
  My pin connection :
  1. backlight: GPIO 0 (actually not connected, so GPIO 0 is also risky)
  2. dc: GPIO 21
  3. rst: GPIO 3. (3 and 2 are suitable for RST only!)
  4. sclk: GPIO 6
  5. sdo: GPIO 7
  6. cs: GPIO 20
• Behaviour of gyroscope

[georgik]

The next meeting 12th July.
Alternating time each two weeks: 3pm Brno time

Note: we can alter the time of meeting after 12th July to 8pm.