Rust ESP32 Community Meeting 2024-10-16

[MabezDev]

The meeting is scheduled for 16th of October 2024 - 5 pm CET/GMT+1.

Join the meeting here

[SergioGasquez]

• Where should our std installation instructions live? cc @ivmarkov
  • See Make esp-idf-template The source of Truth w.r.t. Detailed Installation (Was: Cannot compile generated templates:) esp-idf-template#237

[ivmarkov]

Dealing with commercial vendors that are piloting/going to production with esp-idf-* or baremetal

Multiple issues (or rather, challenges / tasks) with that:

• We do not have a clear signal how many vendors are doing this

  • Suggestion: Assemble and keep an up to date list of those. Even if it does not contain concrete vendor names (vendors might not be OK with that) having at least counts/statistics would be beneficial, as it would inform us how many breaking changes we can allow yourself, as that might have consequences now
  • Suggestion: Work with vendors willing to get some publicity with their Rust-on-esp story on a "Hall of Fame" or "Adopters" website, and actively advertise the website in the HAL repos
  • Suggestion: Change the issue/PR template to contain information whether this issue/PR is affecting a commercial project (and optionally - which one and by whom). This would allow us to treat such issues/PRs with priority and will give us an extra signal as to what is the commercial adoption of esp-rs

• esp-idf-* specifics concerning commercialization of firmware relying on these crates

  • Suggestion: Given that Espressif's position on esp-idf-* is that it is a "stop-gap" solution - at a minimum - we need to reflect that in the READMEs of the esp-idf-* crates. We owe this to commercial vendors, because a "stop-gap" solution mean they - from day 0 - have to assess the cost of a potential future migration to baremetal, and therefore organize their codebase in such a way, so as to ease such a future migration. Or take the consequences of not doing this. Where I'm going in that is that IMO we do need to be transparent about the status quo
  • Suggestion: On the topic of transparency - IMO, we also have to reflect - in the esp-idf-* crates READMEs - and possibly in the Book, that esp-idf-* is a purely external effort and is not subsidized by Espressif with paid developer time. Or we should get a paid developer effort (there is a long "grocery list" of stuff that needs to be done that is currently lagging, because there is only so much time external contributors can dedicate to esp-idf-*)
  • Suggestion: The esp-rs Book can become a tad more useful specifically with regards to suggestions how to organize the firmware code-base in such a way, that a potential future migration to baremetal does not equal a complete rewrite in future. (Funnily, achieving easier migration from STD to baremetal esp-rs requires mostly the same effort that would ease migrating from one MCU vendor to another, but... such is life). Namely, topics like:
    • Use no_std where possible (for modules or even whole sub-crates in a workspace)
    • Take advantage of e-hal(-async)
    • Prefer using embassy-time, embassy-futures, embassy-sync over any STD equivalents, like mpmc/spsc channels, timers induced by BSD-sockets Reactors and so on
    • Isolate your TCP/UDP networking code behind abstractions. For example - use something similar to edge-nal in spirit, which hides lwIP behind a fence which is compatible with embassy-net
    • Prefer pure-Rust no_std crates over available ESP IDF C equivalents. This is valid for 2nd-tier drivers for devices, that sit on top of SPI/I2C/I2S/UART, but also for 2nd-tier networking code, that sits on top of the IP/TCP/UDP stack. I.e. prefer picoserve/edge-http or similar over the ESP IDF C HTTP server; prefer reqless/edge-http over the ESP IDF C HTTP client; and so on and so forth

Useful enhancements to the esp-rs Book

(Related to the topic of @SergioGasquez from above.)

My personal opinion is that a Book should be a Book - i.e. it should contain material which is more conceptual, and ages well with time, requiring small to no changes on every release of the crates. For example, the Ferrous STD training is useful, but it is still "Step-by-step" in spirit, requires changes for every release of the crates and in general is not that conceptual. I was looking at the Embassy book lately, and I think we can learn from that. Some examples of topics that age well, and are more conceptual (as opposed to step-by-step installation instructions):

• Layout of a baremetal / ESP-IDF crate, with what file/directory serves what purpose; also specifically for the ESP IDF, how downloading & compiling ESP IDF actually works on a conceptual level; how to do ESP IDF vendoring (pre-installed ESP IDF) and so on (update: started, but does need to be extended; in particular, there is no treatment at all how the esp-idf-sys build actually works, at a high level)
• The migration topics from above, probably extended to the general topic of Portability
• Best practices for organizing your code for testability (unit tests, on-host tests; HIL tests)
• Optimizing for size (panic_immediate_abort; logging story)
• Optimizing memory (especially relevant in the async world with its gigantic futures)
• Identifying stack overflows; how to deal with these
• Using an appropriate monitor that has capabilities of decoding stacktraces
• Using crates from GIT (master branches)
• other??

Where possible of course we should put links in the Book rather than re-creating existing material available on the Internet.

[ivmarkov]

Two more:

@MabezDev @bugadani

• Do we have any updates w.r.t.: Sporadic panic in async-io thread with esp-sys-svc async TLS example smol-rs/async-lock#84 (potential xtensa miscompilation with alignments larger than 8 bytes)
• Can we actually make the internal progress externally visible?

@MabezDev

• Any follow up on the PSRAM issue (Rust ESP32 Community Meeting 2024-09-12 #233 (comment)). specifically, whether it is safe to use atomics in PSRAM, as long as access to PSRAM memory regions containing atomics is confined to a single CPU or a single thread.
• also this might or might not be related to the atomics-in-PSRAM issue