Rust ESP32 Community Meeting 2024-09-12

[MabezDev]

The meeting is scheduled for 12th of September 2024 - 5 pm CET/GMT+2.

Join the meeting here

New format

Last meeting we discussed changing the way we run these meetings, we want to be more inclusive of ideas and discussion with the community within the meeting itself, instead of just informing progress. Therefore we have implemented the following changes:

• Cadence increased to 1 meeting per month
• We've decided to try using matrix to host the video calls: https://app.element.io/#/room/#esp-rs-community-meetins:matrix.org
• We will ping https://app.element.io/#/room/#esp-rs-community-meetins:matrix.org and https://app.element.io/#/room/#esp-rs:matrix.org a week in advance as a call for topics to discuss in this meeting

Open questions

• We also wish to allow folks in other time zones to attend, we hope to do this by alternating the times. We'd like to ask for time suggestions that preferably fit within a central European work day (+- a couple of hours should be fine).
• Anything else? This is not a concrete format, we're open to changes if you think it would improve the process.

Please drop any topics you wish to discuss in the next meeting below.

[frederictobiasc]

• ESP32-C3: examples/esp_wifi_access_point: Stations disconnect every few seconds due to beacon loss. esp-hal#1766

[Dominaezzz]

• Introduce traits for the DMA buffer objects esp-hal#1976
• RGB Interface Support for esp32-s3 esp-hal#2081
• Support XiP from PSRAM esp-hal#2083
• Static linking in psram. Is there support or what is needed for it? esp-hal#1083

[bjoernQ]

Regarding PSRAM

For some reason I thought the 2nd stage bootloader could do the heavy lifting for us (by setting up PSRAM, copying data and instructions) - but seems it doesn't

So, we would need to

• zero PSRAM .bss
• copy data to PSRAM .data
• copy instructions to PSRAM .text

For XIP we would also need to do the MMU mapping for ibus (like we currently do for dbus)

[Dominaezzz]

Thank you so much for looking into it.

I'm guessing so if that is stuff that can go into the Esp32Reset function?

I guess we can copy these from esp-idf and do it in rust?

[AnthonyGrondin]

A discussion was started about the state of extra crates, that aren't core crates.
esp-rs/esp-hal#1984 (comment)

[ivmarkov]

My on-duty topic again:

• Now that summer-time is over, wondering if I might/can get some help on these issues? The LLVM mis-compilation for xtensa is the one where help is most urgent

[liebman]

General DMA-Peripheral interface - there are multiple ways now:

• take Descriptor slice on creation and data buffer on send. No way to specify the DMA "chunk size".
• Takes DescriptorChain on creation and data buffer on send. The DescriptorChain can be constructed with "chunk_size" choices,
• the newer DmaTxBuf and friends - these currently don't have any way to specify the the DMA "chunk size".

I think we need consistency what the interface will be. Some basic requirements are:

• Needs to support varying the chunk size
• If it includes data buffer allocation need to support alignment & "size alignment".

Note the alignment requirements come from DMA busrt mode and DMA to/from PSRAM.

[Dominaezzz]

You've perfectly captured what I want to discuss.

[bjoernQ]

+1 - see esp-rs/esp-hal#1976 (review)

[bjoernQ]

Similar to Anthony's point above: How to deal with additional examples

• Add dynamic output gpio example to demonstrate how to use AnyPin and Flex esp-hal#1903
• Opentherm controller esp32 esp-hal#2135

[ivmarkov]

Status of the atomics-in-psram issue:

• What I know in the meantime is that it is definitely broken for both bare-metal and ESP-IDF
  • The latter, due to the fact that LLVM for multicore MCUs always emits "native" atomics (which do not work for PSRAM) and not really calls to the __atomic_* intrinsics that are then provided by ESP IDF. If it was emitting __atomic_* calls, then the issue would've been non-existent on ESP IDF, as it has a conf setting which - when enabled - "fixes" the atomics in PSRAM by emulating these
  • Unfortunately, it is unlikely that the multicore *-espidf Rust targets would ever be allowed to emit __atomic_* calls, because upstream noticed that some of the __atomic implementations in ESP IDF are lock-ful, and the contract of core::sync::atomic explicitly guarantees, that the atomics provided there might be wait-ful but never lock-ful.

What we (still) need to do (I guess):

• Confirm/deny that as long as the user can guarantee that the access to the PSRAM region is confined to a single core (or maybe even to a single thread, even if that thread is unpinned?), having native atomics there is a non-issue. @MabezDev any news here? I think this is the case, because I noticed in ESP IDF there is no "special casing" when PSRAM is installed on a single-core MCU.
• Confirm/deny that using the lock-ful atomic impl of portable-atomic + the critical-section feature should be OK w.r.t. PSRAM (critical-section-based atomics are really just "disable-all-interrupts" + spinlocks - i.e. it should work, even if lock-ful, but they are not part of core::sync::atomic so who cares that they are lock-ful)