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

Conclusion

Rust proved to be a reliable choice for industrial microcontroller firmware. In a ten‑week parallel development of the same vanilla data‑logger (VDL) feature, the Rust implementation used 45 % less total RAM than the C implementation while achieving comparable execution speed, despite the Rust team having less prior experience.

Experiment Design

Hardware Platform

Development board: SensorTile.box Pro (STEVAL‑MKBOXPRO)

MCU: STM32U585AI, ARM Cortex‑M33

Flash: 2 MB

Sensor: LSM6DSV16X six‑axis IMU

Interfaces: I2C (sensor) + UART (PC upload)

Experiment Flow

First stage (6 weeks) : two teams independently develop the same VDL firmware – one in C, one in Rust.

Second stage (4 weeks) : the teams cross‑compare and optimise each other's code.

Technology Stacks

VDL‑C (C team)

Toolchain: STM32CubeMX + STM32CubeIDE

Architecture: event‑driven FSM with manual interrupt control

JSON handling: Parson library (dynamic heap allocation)

Memory model: newlib standard library + heap allocation

Data structures: dynamic allocation

VDL‑Rust (Rust team)

Toolchain: Ariel OS + Embassy async framework

Architecture: async/await task model

JSON handling: serde + serde‑json‑core (zero‑heap deserialization)

Memory model: no_std + no_alloc, pure static allocation

Data structures: heapless crate (fixed‑capacity, static allocation)

Memory (RAM) Comparison

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

Static data : C = 14,960 B, Rust = 14,400 B (‑560 B for Rust)

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

Total RAM : C = 44,656 B, Rust = 24,640 B (‑20,016 B, ‑45 % for Rust)

The C version uses the Parson JSON library, allocating 25.6 KB on the heap. The Rust version uses the heapless crate, allocating zero bytes on the heap. Although Rust’s stack usage is five times larger, the heap savings outweigh the stack overhead, yielding a net 45 % RAM reduction.

Flash (ROM) Comparison

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

Total ROM : C = 76,744 B, Rust = 84,100 B (+7,356 B, ≈+10 %)

The ROM increase stems from two sources identified by the authors:

Monomorphisation – generic code expands into multiple concrete types.

Async state‑machine expansion – each async function compiles to a state machine.

On a 2 MB flash device the 7 KB difference is negligible, but it becomes relevant on much smaller MCUs.

Performance (Execution Speed)

Final output data rate (ODR): 7,468 Hz (identical for both implementations).

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

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

During the initial phase the Rust implementation was roughly twice as fast as the C version; after iterative optimisation the two converged to the same throughput.

Portability

Target board change : Rust – modify configuration and run a single compile command; C – recreate a new CubeIDE project and copy files manually.

Project structure : Rust – single code base with #[cfg] feature switches; C – separate CubeIDE project per board.

Driver reuse : Rust – crates pulled from crates.io, reusable across platforms; C – manual integration per project.

Cross‑platform testing : Rust – the same crate can compile for embedded, desktop, and WASM; C – no comparable capability.

This portability means a product team can switch MCUs without rewriting the whole firmware.

Safety and Compliance

Zero‑heap memory model : guarantees predictable memory behaviour, eliminates fragmentation and runtime OOM, which is critical for 24/7 industrial devices.

EU Cyber Resilience Act (CRA) : encourages the use of memory‑safe languages; Rust complies out of the box.

The C version’s Parson library introduces a risk of heap fragmentation, although the paper did not perform adversarial testing.

Limitations of the Study

Low‑end MCUs (Cortex‑M0/M0+, 32–64 KB Flash, 8–16 KB RAM) were not evaluated.

Non‑ARM platforms (e.g., RISC‑V) were not tested.

Network stacks (BLE, Wi‑Fi, LoRaWAN) and their memory impact were not measured.

No power‑consumption measurements were provided.

Long‑term stability (24–72 h endurance) was not assessed.

No comparison with RTOSes such as FreeRTOS or Zephyr.

Only average ISR period was measured; worst‑case jitter was not reported.

If the C implementation used a zero‑heap JSON library (e.g., jsmn), the RAM gap would shrink.

What Is Ariel OS?

Positioning : lightweight Rust library operating system for IoT microcontrollers.

Supported architectures : ARM Cortex‑M, RISC‑V, ESP32 Xtensa.

Scheduling : single‑core and multi‑core pre‑emptive scheduling (first of its kind for Rust embedded OS).

Async support : built on the Embassy async framework.

Build model : uses Embassy HAL and OS abstractions.

Open source : source code available on GitHub.

Key Takeaways

RAM reduction of 45 % is tangible; on MCUs RAM is far more valuable than Flash.

ROM increase of ~10 % is negligible on modern 2 MB devices but may matter on very small MCUs.

Portability benefits of Rust’s crate ecosystem and conditional compilation are often underestimated; they simplify board migration compared with traditional CubeMX workflows.

Overall, for mid‑range to high‑end Cortex‑M projects Rust is now a serious candidate; for ultra‑low‑end MCUs further data is needed.