Can Rust Replace C in Embedded Firmware? Industrial Findings from ST and Academia

Conclusion

Rust is a reliable choice for industrial microcontroller firmware. The study demonstrates a 45% reduction in total RAM usage compared with a C implementation, while achieving comparable execution speed. However, ROM size grows by roughly 10%.

Experiment Design

Two teams—one using C and the other using Rust—developed the same data‑logger firmware (Vanilla Data Logger) in parallel for ten weeks on real hardware. The experiment was split into two phases: six weeks of independent development followed by four weeks of cross‑team optimization.

Hardware Platform

Development board: SensorTile.box Pro (STEVAL‑MKBOXPRO). MCU: STM32U585AI (ARM Cortex‑M33). Flash: 2 MB. Sensors: LSM6DSV16X six‑axis IMU. Communication: I²C for sensors and UART for data upload.

Toolchains and Architecture

C team : STM32CubeMX + STM32CubeIDE, event‑driven FSM with manual interrupt control, Parson JSON library (dynamic heap allocation), newlib standard library with heap.

Rust team : Ariel OS + Embassy async framework, async/await task model, serde + serde‑json‑core for zero‑heap JSON, no_std + no_alloc (pure static allocation), heapless crate for fixed‑capacity data structures.

Memory Usage

Key RAM figures (bytes):

Stack: C 2 048 B vs Rust 10 240 B (+8 192 B for Rust)

Static: C 14 960 B vs Rust 14 400 B (‑560 B for Rust)

Heap: C 25 600 B vs Rust 0 B (‑25 600 B for Rust)

Total RAM : C 44 656 B vs Rust 24 640 B (‑20 016 B, a 45% reduction)

Flash/ROM Usage

.text segment: C 66 240 B vs Rust 69 764 B (+3 524 B)

Total ROM : C 76 744 B vs Rust 84 100 B (+7 356 B, about 10% larger)

The ROM increase is mainly due to monomorphisation (generic expansion) and async state‑machine code size. On a 2 MB flash device, a 7 KB difference is negligible, but it may matter on smaller MCUs.

Performance

Output data rate (ODR): 7 468 Hz for both implementations.

UART streaming task latency (after tuning): ~120 µs for both.

Rust async task switch latency: 1.7–4.0 µs.

During the initial phase, the Rust version was twice as fast as the C version; after iterative tuning, performance converged.

Portability

Rust’s single code base with #[cfg] feature switches allows easy retargeting to a new board by changing configuration and recompiling. In contrast, the C workflow requires creating a separate CubeIDE project and manually copying files. The same Rust crate can be compiled for embedded, desktop, or WebAssembly targets, while the C approach lacks such cross‑platform support.

Safety and Compliance

Zero‑heap allocation guarantees predictable memory behaviour, eliminating fragmentation and runtime OOM risks—critical for 24/7 industrial devices.

The EU Cyber Resilience Act (CRA) encourages the use of memory‑safe languages; Rust naturally aligns with this trend.

The C implementation’s Parson library poses a heap‑fragmentation risk, though the study did not perform stress testing.

Limitations

The study does not cover low‑end MCUs (Cortex‑M0/M0+), non‑ARM architectures (e.g., RISC‑V), network stacks (BLE, Wi‑Fi, LoRaWAN), power consumption, long‑duration stability, or RTOS comparisons. The impact of using a zero‑heap JSON library in C is also untested.

Ariel OS Overview

Lightweight Rust library OS for IoT microcontrollers.

Supports ARM Cortex‑M, RISC‑V, and ESP32 Xtensa.

Provides pre‑emptive scheduling for single‑core and multi‑core systems (first of its kind in Rust embedded OSes).

Built on the Embassy async framework and HAL abstractions.

Open‑source on GitHub.

Key Takeaways

Rust’s zero‑heap model yields a concrete 45% RAM saving, which is significant on resource‑constrained MCUs.

The ~10% ROM increase is modest on modern devices with large flash but may be a concern on very small MCUs.

Portability advantages of Rust’s crate ecosystem and conditional compilation are often underestimated.

Overall, for mid‑to‑high‑end Cortex‑M projects, Rust is now a serious contender for firmware development; for ultra‑low‑end targets, further data is needed.