Anecdote about this summary at the bottom:
> This setup gives you the best of both worlds: ESP-IDF and FreeRTOS manage Wi-Fi, BLE, and system tasks on Core 0, while Core 1 runs your bare-metal Rust code at full speed with zero scheduler interference.
I am doing something somewhat like this, but with separate MCUs instead of separate cores. I flashed Esp-Hosted-MCU onto an ESP-32 (C3, but any including S3 will work). This is official firmware which turns the ESP into a "radio co-processor", so you can treat it like a SPI or UART Wi-Fi/BLE chip.
On another MCU (STM32), I run bare-metal firmware in rust which talks to the radio over SPI. Wi-Fi uses the ESP IDF, and BLE uses standard HCI commands.
Yes you can pin it to core 1 whilst pinning all other tasks to core 0. Then will never be interrupted or preempted (except by interrupts created on core 1)
Anecdote about this summary at the bottom: > This setup gives you the best of both worlds: ESP-IDF and FreeRTOS manage Wi-Fi, BLE, and system tasks on Core 0, while Core 1 runs your bare-metal Rust code at full speed with zero scheduler interference.
I am doing something somewhat like this, but with separate MCUs instead of separate cores. I flashed Esp-Hosted-MCU onto an ESP-32 (C3, but any including S3 will work). This is official firmware which turns the ESP into a "radio co-processor", so you can treat it like a SPI or UART Wi-Fi/BLE chip.
On another MCU (STM32), I run bare-metal firmware in rust which talks to the radio over SPI. Wi-Fi uses the ESP IDF, and BLE uses standard HCI commands.