LabEmbedded Rust vs C in 2026 · the pragmatic decision

• Greenfield project on a modern MCU (Cortex-M, RISC-V, ESP32, RP2040).
• Memory-safety matters (medical, automotive, finance).
• Async concurrency is non-trivial. Embassy is a genuine productivity win.
• Build reproducibility is important. Cargo plus probe-rs beats the C/Makefile mess.

• MISRA-C certification is required. Rust tooling for cert is still immature.
• Sub-16KB flash targets. Rust binary footprint is catching up but still larger.
• Legacy toolchains (AVR, old PIC, STM8). Rust support is unreliable.
• Hardware vendor ships only a C SDK. Binding-generation bias adds risk.

Embassy (https://embassy.dev) made async embedded practical. Before it, async-on-MCU was a research topic. Today it is the default for any firmware that juggles multiple async IO operations (BLE + Wi-Fi + sensor readout simultaneously).

#[embassy_executor::main]
async fn main(spawner: Spawner) {
    let p = embassy_stm32::init(Default::default());
    let mut led = Output::new(p.PB7, Level::High, Speed::Low);
    loop {
        led.toggle();
        Timer::after_millis(500).await;
    }
}

On a Cortex-M4, a minimal no-std Rust binary lands around 4-6 KB. Equivalent C is closer to 1-2 KB. For a flagship-MCU project (Cortex-M33 or ESP32-S3), this is immaterial. For a ULP BLE-only tag on a 16KB device, it still rules Rust out.

Default: Rust for new projects on M4 / M33 / RISC-V / ESP32. C for legacy, cert-required, and sub-16KB targets. Mixed projects work fine · Rust for app, C for vendor SDK.