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-wit...
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.
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.
[1]: https://tingouw.com/blog/cloud_notes/badwater_intro#day-5-8m...
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.
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.
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.
This depends on what resources you're counting. If you're counting the developer cycles, it is not.
ESP-IDF+FreeRTOS has great value: it solves a host of mundane problems that need solving in real products. Discarding all of that value is foolish; you should preserve it, and look to keep your work aligned with the recent ESP-IDF and FreeRTOS evolution, so future you can adopt updates and supported tooling in a timely manner.
However, you also need at least some of your work to be hard real time, bare metal code. You do this through hardware peripherals, precision memory management, and tight ISRs that do not contend with whatever FreeRTOS or some Expressif driver is up to. Most of all, you want to never have to rework these parts because something in ESP-IDF and/or FreeRTOS, both rapidly moving targets, has changed.
Dedicating cores (0 for FreeRTOS, 1 for you) provides exactly this, and why ESP-IDF supports this model.
There is an ugly truth here. Ideally, one should not need to resort to such things. If the model and runtime behavior of the vendor's stack were extremely mature and could be relied upon with high confidence, it would not be necessary. However, anyone that has ever actually dealt with real time requirements and/or needed to fully exploit hardware peripheral capabilities in the real world of endlessly changing, incomplete, buggy BSPs/RTOSes/etc., knows that they probably won't live to see that.
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).