pith. machine review for the scientific record. sign in

arxiv: 2604.25679 · v1 · submitted 2026-04-28 · 💻 cs.OS

Recognition: unknown

Embedded Rust or C Firmware? Lessons from an Industrial Microcontroller Use Case with Ariel OS

Bipin Thapa, Daniele Alfonso, Emmanuel Baccelli, Kaspar Schleiser, Licio Mapelli, Lorenzo Bini, Romain Fouquet

Pith reviewed 2026-05-07 13:40 UTC · model grok-4.3

classification 💻 cs.OS
keywords embedded rustmicrocontroller firmwareperformance comparisonmemory footprintiotbare-metalariel osfirmware development
0
0 comments X

The pith

Rust matches C in microcontroller firmware memory use and execution speed.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Two teams built the same industrial IoT microcontroller functionality in parallel, one with C and one with Rust. Hardware measurements across months of development found no strong reason to choose C for smaller size or faster runs. The Ariel OS Rust runtime delivered a smaller system footprint than the conventional bare-metal C stack used in the domain. The results position Rust as a practical option for firmware where reliability is required.

Core claim

Side-by-side C and Rust implementations of identical industrial microcontroller firmware, validated on hardware, show comparable or smaller memory footprints and equivalent execution speeds for Rust. Ariel OS supplies an efficient, portable Rust system layer whose size undercuts the state-of-the-art bare-metal C approach.

What carries the argument

Concurrent development of equivalent C and Rust firmware versions for the same industrial IoT use case, followed by direct hardware measurements of memory and timing.

If this is right

  • Teams can adopt Rust for new microcontroller projects without expecting larger binaries or slower code.
  • Ariel OS offers a smaller, portable runtime alternative to traditional bare-metal C stacks.
  • Safety guarantees from Rust become available in embedded firmware without the usual size or speed penalties.
  • Portability across microcontroller families improves when using a single Rust-based system layer.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Wider use of Rust in this domain could reduce memory-safety bugs that commonly appear in long-lived C firmware.
  • Development velocity and maintainability gains from Rust may compound once the initial performance parity is established.
  • Hybrid C-Rust codebases become more feasible if Rust runtimes reliably stay within C memory budgets.

Load-bearing premise

The two teams produced functionally equivalent code and the chosen industrial IoT microcontroller scenario represents typical firmware work.

What would settle it

A larger or different microcontroller application where the Rust version clearly exceeds the C version in flash or RAM use or runs slower under real load would falsify the no-strong-preference claim.

read the original abstract

As Rust gains traction for developing safer systems software, a reality check for the microcontroller hardware segment becomes necessary. How ready is the Rust ecosystem for this segment? Can Rust compete with C in practice? This paper reports on an IoT industrial case study that contributes to answering these questions. Two teams concurrently developing the same functionality (one in C, one in Rust) are analyzed over a period of several months. A comparative analysis of their approaches, results, and iterative efforts is provided. The analysis and measurements on hardware indicate no strong reason to prefer C over Rust for microcontroller firmware on the basis of memory footprint or execution speed. Furthermore, Ariel OS is shown to provide an efficient and portable system runtime in Rust whose footprint is smaller than that of the state-of-the-art bare-metal C stack traditionally used in this context. It is concluded that Rust is a sound choice today for firmware development in this domain.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 3 minor

Summary. The paper reports on a concurrent industrial case study in which two teams developed identical IoT microcontroller firmware functionality—one in C and one in Rust using Ariel OS—over several months. It compares their approaches, iterative efforts, and hardware measurements of memory footprint and execution speed, concluding that the data show no strong reason to prefer C over Rust on those metrics and that Ariel OS delivers a smaller footprint than the traditional bare-metal C stack.

Significance. If the functional equivalence and measurement details hold, the work supplies rare real-world empirical evidence from an industrial setting on Rust versus C for microcontrollers. The concurrent-team design and focus on a portable Rust runtime (Ariel OS) are strengths that could inform adoption decisions; reproducible hardware numbers and explicit feature parity would make the result a useful reference point for the embedded-systems community.

major comments (3)
  1. [§3] §3 (Implementation and Development Process): The claim that both teams delivered 'the same functionality' is load-bearing for all performance comparisons, yet the section provides no feature checklist, shared test-suite description, or verification that both implementations passed the same industrial requirements. Without this, differences in scope or optimization effort cannot be ruled out as explanations for the observed parity.
  2. [§5] §5 (Hardware Measurements and Results): The abstract and conclusions assert that measurements indicate 'no strong reason to prefer C' and that Ariel OS is smaller than the state-of-the-art bare-metal C stack, but the text supplies no concrete numbers, measurement methodology (e.g., how execution time was timed, what benchmarks were used), error bars, or statistical equivalence checks. This prevents independent verification of the central empirical claim.
  3. [§4.1, Table 1] §4.1 and Table 1: The memory-footprint comparison between Ariel OS and the traditional C stack is presented as a key result, but the table does not enumerate the exact set of OS services or drivers included in each implementation, making it impossible to confirm that the comparison is apples-to-apples.
minor comments (3)
  1. [Figure 2] Figure 2 (development timeline) uses inconsistent y-axis scaling between the C and Rust teams, which obscures direct visual comparison of iteration effort.
  2. [Related Work] The paper cites prior embedded-Rust studies but does not discuss how the present industrial case study differs in scope or methodology from those works.
  3. [§6] A few sentences in §6 contain minor grammatical issues that affect readability but do not change meaning.

Simulated Author's Rebuttal

3 responses · 1 unresolved

We thank the referee for the constructive and detailed comments, which help strengthen the rigor and reproducibility of the paper. We address each major comment below and outline the revisions we will make.

read point-by-point responses

  1. Referee: [§3] §3 (Implementation and Development Process): The claim that both teams delivered 'the same functionality' is load-bearing for all performance comparisons, yet the section provides no feature checklist, shared test-suite description, or verification that both implementations passed the same industrial requirements. Without this, differences in scope or optimization effort cannot be ruled out as explanations for the observed parity.

    Authors: We agree that documenting functional equivalence is essential. Both teams worked from an identical requirements document supplied by the industrial partner and validated their code against a shared test suite. In the revised manuscript we will add a high-level feature checklist to §3, describe the test-suite structure, and state that both implementations passed the same acceptance criteria. Due to confidentiality agreements we cannot release the full proprietary checklist, but the added summary will demonstrate parity on core functionality (sensor I/O, communication stacks, control loops). revision: partial

  2. Referee: [§5] §5 (Hardware Measurements and Results): The abstract and conclusions assert that measurements indicate 'no strong reason to prefer C' and that Ariel OS is smaller than the state-of-the-art bare-metal C stack, but the text supplies no concrete numbers, measurement methodology (e.g., how execution time was timed, what benchmarks were used), error bars, or statistical equivalence checks. This prevents independent verification of the central empirical claim.

    Authors: We acknowledge that the measurement details were insufficiently elaborated. We will expand §5 with concrete memory-footprint figures (RAM and Flash in bytes), execution-time results for representative tasks (measured via on-chip hardware timers), standard deviations from repeated runs, and a brief statistical comparison supporting the equivalence conclusion. These additions will allow independent verification while preserving the paper’s central claim. revision: yes

  3. Referee: [§4.1, Table 1] §4.1 and Table 1: The memory-footprint comparison between Ariel OS and the traditional C stack is presented as a key result, but the table does not enumerate the exact set of OS services or drivers included in each implementation, making it impossible to confirm that the comparison is apples-to-apples.

    Authors: We agree that Table 1 must be made more explicit. In the revision we will expand the table (or add a companion table) to list the precise OS services, drivers, and runtime components present in both the Ariel OS Rust stack and the bare-metal C implementation, confirming that equivalent functionality is being compared. revision: yes

standing simulated objections not resolved
  • Full disclosure of the detailed proprietary feature checklist and complete test-suite specifications, which are subject to non-disclosure agreements with the industrial partner.

Circularity Check

0 steps flagged

No circularity: direct empirical comparison without derivations

full rationale

The paper is an observational case study of two concurrent teams implementing identical functionality in C versus Rust on an industrial microcontroller, followed by hardware measurements of footprint and speed. No equations, fitted parameters, ansatzes, uniqueness theorems, or self-citations appear in the derivation chain. Conclusions rest on direct comparison of the produced artifacts rather than any step that reduces to its own inputs by construction. The analysis is therefore self-contained.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The work is an empirical case study with no mathematical derivations, free parameters, axioms, or invented entities.

pith-pipeline@v0.9.0 · 5474 in / 1154 out tokens · 50260 ms · 2026-05-07T13:40:48.127451+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

4 extracted references

  1. [1]

    ST AIoT Craft-A No-Code/Low-Code Cloud Solution for Edge AI Management in Smart Sensors

    M. Chowdhary et al. "ST AIoT Craft-A No-Code/Low-Code Cloud Solution for Edge AI Management in Smart Sensors." Proceedings of the 23rd ACM Conference on Embedded Networked Sensor Systems. 2025. [2] E. Frank, et al. "Ariel OS: An Embedded Rust Operating System for Networked Sensors & Multi-Core Microcontrollers." Proceedings of the 21st International Confe...

    2025

  2. [2]

    Rust for embedded systems: Current state and open problems

    Embassy Framework: https://github.com/embassy-rs/embassy, 2026. [9] STMicroelectronics MEMS Rust Drivers Repository. Online: https://github.com/STMicroelectronics/st-mems-rust-drivers [10] DTDL: Digital Twins Definition Language. Online: https://github.com/Azure/opendigitaltwins-dtdl [11] Azure IoT Plug and Play (PnP). Online: https://learn.microsoft.com/...

    2026

  3. [3]

    Online: https://crates.io , 2026 [19] XCube MEMS

    Rust Community Crate Registry. Online: https://crates.io , 2026 [19] XCube MEMS. Online: https://www.st.com/en/embedded-software/x-cube-mems1.html, 2026 [20] Serde Framework. Online: https://serde.rs/, 2026 [21] EU Cyber Resilience Act. Online https://www.cyberresilienceact.eu/ [22] Newlib. Online: https://sourceware.org/newlib/ [23] Heapless crate. Onlin...

    2026

  4. [4]

    Online: https://github.com/google/bloaty [26] Cargo-bloat

    Bloaty. Online: https://github.com/google/bloaty [26] Cargo-bloat. Online: https://github.com/RazrFalcon/cargo-bloat [27] StaticCell. Online: https://github.com/embassy-rs/static-cell [28] serde-json-core.https://github.com/rust-embedded-community/serde-json-core