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)
Very good article!
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.
I think you can run a single task on core 1 without interference if you give it the right priority (and disable some things).
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)