3 ms·

Running Bare-Metal Rust Alongside ESP-IDF on the ESP32-S3's Second Core

96 points by MrBuddyCasino 6mo ago

fjfaase 6mo ago
I think you can run a single task on core 1 without interference if you give it the right priority (and disable some things).
- barbegal 6mo ago
  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)
the__alchemist 6mo ago
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.
- sottol 6mo ago
  Interestingly, Espressif nowadays does something similar on the ESP32-P4 which is RiscV but doesn't have builtin Wifi/BT. So they tend to pair it with an ESP32-C6 which runs the WiFi stack and firmware that communicates with the P4 using SDIO. Not bare metal though, but similar dual-mcu setup for wifi/bt.
- embeng4096 6mo ago
  I didn’t know about hosted-MCU! I just started using the ESP-AT firmware for an ESP acting as a radio co-processor on a project at work - do you know how hosted-MCU differs? I did glance at the readme and get the impression that hosted-MCU works for all compatible ESPs and seems more flexible and powerful, where ESP-AT is for select ESP chips and is more limited.
  - the__alchemist 6mo ago
    I don't, and haven't used ESP-AT. It sounds like AT may use a text-based protocol (Something that was big a while back?). Esp-Hosted uses Protobuf/RPC to access IDF commands, and HCI direct.
- bschwindHN 6mo ago
  > 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. Kinda funny because the ESP8266 basically started off as a WiFi "co-processor" with AT commands sent over UART. People quickly discovered it had a good amount of power and you could run your entire application on the ESP8266 instead of using it as a co-processor. That led to an explosion in popularity for "makers" because the chip was so cheap and capable for projects at the time, and I think that led to the ESP32 becoming so widely known.
ufocia 6mo ago
Interesting, but giving up an entire core to Wi-Fi and Bluetooth seems wasteful.
- the__alchemist 6mo ago
  This is reasonably common - Nordic and ST do this as well on the nrf-53 and STm32WB/L respectively. It's convenient for concurrency, and separation of concerns.
  - teraflop 6mo ago
    Also, running the network stack on a separate core allows it to be encrypted and signed, so that end users can't (easily) reverse engineer it. Which sucks for those of us who would like to run fully open-source code without binary blobs. For instance, compare the reference manuals for the STM32WL3R and the STM32WB microcontrollers. The former has a single CPU, and it has almost 250 pages of detailed documentation about exactly how the hardware is controlled at a register level. The latter runs the network stack on an auxiliary CPU, and the manual just has a block diagram and a sentence that says "use our drivers" (which are only available in encrypted format).
  - topspin 6mo ago
    Espressif themselves do this for their own prerogatives. The ESP32-S3 MCU from this story actually has a small, low power RISC-V core that deals with several things, including "deep sleep" tasks. Many ESP32-S3 users are unaware that their dual core Xtensa device also includes a RISC-V core; it's just there, transparently doing Expressif stuff on a dedicated core, immune to whatever is going on with the fast cores.
- nerdsniper 6mo ago
  On basic microcontrollers, mixing message/command I/O with application threads on the same core often lead to missing incoming commands. So it's relatively normal to separate them to their own core free of application logic.
- topspin 6mo ago
dakolli 6mo ago
This is a great blog, I love the I Built a WebAssembly Runtime in 5 Days Because I Was Tired of Paying for Cloud Run [1], . You do a great job at showcasing your creativity for solving problems. I can tell that you genuinely got a lot of satisfaction from escaping big cloud FaaS, for literally fun and profit. I need more blogs like this. [1]: https://tingouw.com/blog/cloud_notes/badwater_intro#day-5-8month-live-domain https://tingouw.com/blog/cloud_notes/badwater_intro#day-5-8m...
Keyb0ardWarri0r 6mo ago
ESP32-S3 may be the worse model to run Rust on due to the XTensa cores that makes the toolchain unnecessarily complicated. The newer model, C3, C6, C5 all have RSIC-V cores which make it a dream to run Rust (basically: rustup target add riscv32imac-unknown-none-elf). Here is a good introduction: https://kerkour.com/introduction-to-embedded-development-with-rust https://kerkour.com/introduction-to-embedded-development-wit...
- topspin 6mo ago
  > ESP32-S3 may be the worse model to run Rust on due to the XTensa cores that makes the toolchain unnecessarily complicated. Indeed. ESP32-S31 appears to target exactly this concern in the popular "S3" segment. It's basically a updated S3, with faster and newer wireless and memory, and it adopts a pair of RISC-V cores in place of the Xtensa cores.
  - sowbug 6mo ago
    My brain broke a little when I read this. Today I learned the C stands for Core, and the S stands for Speed, or Strength, or maybe Superior. My working assumption that C meant RISC-V and S meant Xtensa was incorrect.
    - topspin 6mo ago
      That's a widely shared misunderstanding. The letters are market segments. The "S" segment is really popular. Despite the introduction of many Espressif RISC-V devices, one still sees lots of Xtensa S3 stuff. An excellent example is Unexpected Maker's line of ESP32-S3 boards. ESP32-S31 is going to be a big hit, and RISC-V is only part of that. More GPIO are very welcome. The CLIC (core local interrupt control) is another subtle win that is lost in mainstream headlines: it provides Cortex NVIC level of interrupt management, enabling awesome things like RTIC work without compromise. I imagine using one of these with core 0 running plain old FreeRTOS handing Wi-Fi/OTA/etc., and core 1 exclusively running a Rust RTIC/SRP application, nailing real time peripheral activity. The only miss is the lack of 5GHz. Nothing is perfect, and that's not a deal killer in most cases.

96 points by MrBuddyCasino 6mo ago

I think you can run a single task on core 1 without interference if you give it the right priority (and disable some things).

barbegal 6mo ago
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)

the__alchemist 6mo ago

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.

sottol 6mo ago
Interestingly, Espressif nowadays does something similar on the ESP32-P4 which is RiscV but doesn't have builtin Wifi/BT. So they tend to pair it with an ESP32-C6 which runs the WiFi stack and firmware that communicates with the P4 using SDIO. Not bare metal though, but similar dual-mcu setup for wifi/bt.
embeng4096 6mo ago
I didn’t know about hosted-MCU! I just started using the ESP-AT firmware for an ESP acting as a radio co-processor on a project at work - do you know how hosted-MCU differs? I did glance at the readme and get the impression that hosted-MCU works for all compatible ESPs and seems more flexible and powerful, where ESP-AT is for select ESP chips and is more limited.
- the__alchemist 6mo ago
  I don't, and haven't used ESP-AT. It sounds like AT may use a text-based protocol (Something that was big a while back?). Esp-Hosted uses Protobuf/RPC to access IDF commands, and HCI direct.
bschwindHN 6mo ago
> 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. Kinda funny because the ESP8266 basically started off as a WiFi "co-processor" with AT commands sent over UART. People quickly discovered it had a good amount of power and you could run your entire application on the ESP8266 instead of using it as a co-processor. That led to an explosion in popularity for "makers" because the chip was so cheap and capable for projects at the time, and I think that led to the ESP32 becoming so widely known.

ufocia 6mo ago

Interesting, but giving up an entire core to Wi-Fi and Bluetooth seems wasteful.

the__alchemist 6mo ago
This is reasonably common - Nordic and ST do this as well on the nrf-53 and STm32WB/L respectively. It's convenient for concurrency, and separation of concerns.
- teraflop 6mo ago
  Also, running the network stack on a separate core allows it to be encrypted and signed, so that end users can't (easily) reverse engineer it. Which sucks for those of us who would like to run fully open-source code without binary blobs. For instance, compare the reference manuals for the STM32WL3R and the STM32WB microcontrollers. The former has a single CPU, and it has almost 250 pages of detailed documentation about exactly how the hardware is controlled at a register level. The latter runs the network stack on an auxiliary CPU, and the manual just has a block diagram and a sentence that says "use our drivers" (which are only available in encrypted format).
- topspin 6mo ago
  Espressif themselves do this for their own prerogatives. The ESP32-S3 MCU from this story actually has a small, low power RISC-V core that deals with several things, including "deep sleep" tasks. Many ESP32-S3 users are unaware that their dual core Xtensa device also includes a RISC-V core; it's just there, transparently doing Expressif stuff on a dedicated core, immune to whatever is going on with the fast cores.
nerdsniper 6mo ago
On basic microcontrollers, mixing message/command I/O with application threads on the same core often lead to missing incoming commands. So it's relatively normal to separate them to their own core free of application logic.
topspin 6mo ago

dakolli 6mo ago

This is a great blog, I love the I Built a WebAssembly Runtime in 5 Days Because I Was Tired of Paying for Cloud Run [1], . You do a great job at showcasing your creativity for solving problems. I can tell that you genuinely got a lot of satisfaction from escaping big cloud FaaS, for literally fun and profit. I need more blogs like this. [1]: https://tingouw.com/blog/cloud_notes/badwater_intro#day-5-8month-live-domain https://tingouw.com/blog/cloud_notes/badwater_intro#day-5-8m...

Keyb0ardWarri0r 6mo ago

ESP32-S3 may be the worse model to run Rust on due to the XTensa cores that makes the toolchain unnecessarily complicated. The newer model, C3, C6, C5 all have RSIC-V cores which make it a dream to run Rust (basically: rustup target add riscv32imac-unknown-none-elf). Here is a good introduction: https://kerkour.com/introduction-to-embedded-development-with-rust https://kerkour.com/introduction-to-embedded-development-wit...

topspin 6mo ago
> ESP32-S3 may be the worse model to run Rust on due to the XTensa cores that makes the toolchain unnecessarily complicated. Indeed. ESP32-S31 appears to target exactly this concern in the popular "S3" segment. It's basically a updated S3, with faster and newer wireless and memory, and it adopts a pair of RISC-V cores in place of the Xtensa cores.
- sowbug 6mo ago
  My brain broke a little when I read this. Today I learned the C stands for Core, and the S stands for Speed, or Strength, or maybe Superior. My working assumption that C meant RISC-V and S meant Xtensa was incorrect.
  - topspin 6mo ago
    That's a widely shared misunderstanding. The letters are market segments. The "S" segment is really popular. Despite the introduction of many Espressif RISC-V devices, one still sees lots of Xtensa S3 stuff. An excellent example is Unexpected Maker's line of ESP32-S3 boards. ESP32-S31 is going to be a big hit, and RISC-V is only part of that. More GPIO are very welcome. The CLIC (core local interrupt control) is another subtle win that is lost in mainstream headlines: it provides Cortex NVIC level of interrupt management, enabling awesome things like RTIC work without compromise. I imagine using one of these with core 0 running plain old FreeRTOS handing Wi-Fi/OTA/etc., and core 1 exclusively running a Rust RTIC/SRP application, nailing real time peripheral activity. The only miss is the lack of 5GHz. Nothing is perfect, and that's not a deal killer in most cases.