April 26, 2026
Two cores, one flame war
Running Bare-Metal Rust Alongside ESP-IDF on the ESP32-S3's Second Core
Dev gives Wi‑Fi one brain and Rust the other — cue the core wars
TLDR: A developer split the ESP32‑S3’s two brains: Wi‑Fi/Bluetooth and system stuff on one, bare‑metal Rust on the other for glitch‑free audio. Commenters battled over waste vs. wisdom, arguing priorities could suffice or that a whole extra chip is cleaner—determinism versus efficiency in one spicy thread
Internet tinkerers are buzzing over a bold move: a developer split the ESP32‑S3’s two “brains,” letting Wi‑Fi and Bluetooth live on one core under ESP‑IDF (Espressif’s C toolkit) and its tiny scheduler, while waking the second core to run bare‑metal Rust with zero interruptions for crisp audio. In plain English: one core handles the internet stuff, the other is a private stage for Rust to shred solos without anyone yanking the mic. And yes, the comments turned it into a core custody battle.
The hype squad loved the “best of both worlds,” with one fan cheering the author’s pattern of clever hacks, recalling their past cloud‑dodging antics. Another commenter, the__alchemist, upped the ante: they offload Wi‑Fi to a completely separate microchip, basically turning a single gadget into two chips in a trench coat.
But the skeptics brought heat. Fjfaase argued you don’t need to bench a whole brain; just pin the job and crank the priority so the scheduler behaves. Translation: trust the traffic cop, don’t shut down the road. Meanwhile, ufocia called the split wasteful, sparking the age‑old fight: efficiency vs. determinism.
Memes flew: “Rust kidnapped a CPU,” “FreeRTOS is the hall monitor,” and “Wi‑Fi is a resource hog.” Beneath the jokes sits a real dilemma—do you trust a scheduler, or demand no preemption at any cost
Key Points
- •The article proposes running ESP‑IDF/FreeRTOS on Core 0 and bare‑metal Rust on Core 1 of the ESP32‑S3.
- •CONFIG_FREERTOS_UNICORE is used to disable FreeRTOS on Core 1, preventing scheduler preemption.
- •Rust code is compiled as a static library and linked into the ESP‑IDF firmware, with Core 1 manually booted to run it.
- •xTaskCreatePinnedToCore is deemed unsuitable because tasks remain subject to FreeRTOS scheduling and potential preemption.
- •Data exchange occurs via shared memory between cores, requiring some unsafe Rust; manual stack setup is needed on Core 1 without an OS.