esp-wifi lockup on esp32c3 when using the embassy InterruptExecutor about esp-wifi HOT 3 CLOSED

Seems the scheduler doesn't get a chance to run. On ESP32-C3 interrupts don't get pre-empted and even if they would, the scheduler is priority 1.

I don't know much about RIOT but I guess it has its own scheduler and synchronization primitives?

In esp-wifi we emulate enough of an RTOS to make things work but I guess it would be better to use esp-wifi-sys and use the RIOT functionality. But again, I really don't know much about RIOT - just guessing

from esp-wifi.

Seems the scheduler doesn't get a chance to run. On ESP32-C3 interrupts don't get pre-empted and even if they would, the scheduler is priority 1.

That sounds like a very likely explanation.

I don't know much about RIOT but I guess it has its own scheduler and synchronization primitives?

So RIOT-rs does have its own preemptive scheduler, but no RISC-V support for that (yet). Preemptive scheduling is optional in RIOT-rs, we're using embassy for mostly everything at this stage.

In esp-wifi we emulate enough of an RTOS to make things work but I guess it would be better to use esp-wifi-sys and use the RIOT functionality. But again, I really don't know much about RIOT - just guessing

Well, there's >12k lines of very nice wrapping & integration code in esp-wifi that we don't want to miss out on. 😉
I think for now we'll just go with the esp-hal default (thread mode) executor. Down the line we'll add risc-v support to the RIOT-rs preemptive scheduler, then maybe try to make esp-wifi use that instead of its own emulation...

Anyhow, thanks for looking at this!

from esp-wifi.

Preemptive scheduling is optional in RIOT-rs, we're using embassy for mostly everything at this stage.

Interesting! Thanks for the insights

from esp-wifi.