pith. sign in

arxiv: 2604.25679 · v2 · pith:D7GOROYLnew · submitted 2026-04-28 · 💻 cs.OS

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

Bipin Thapa , Daniele Alfonso , Lorenzo Bini , Licio Mapelli , Kaspar Schleiser , Romain Fouquet , Emmanuel Baccelli This is my paper

Pith reviewed 2026-05-21 01:03 UTC · model grok-4.3

classification 💻 cs.OS
keywords RustC firmwaremicrocontrollerembedded systemsAriel OSindustrial IoTmemory footprintperformance comparison
0
0 comments X

The pith

Rust matches C in memory and speed for industrial microcontroller firmware while using a smaller runtime.

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

Two teams developed equivalent firmware for an industrial IoT microcontroller, one in C and one in Rust. Direct hardware measurements found no meaningful advantage for C in memory footprint or execution speed. The Rust runtime Ariel OS produced a smaller overall system footprint than the conventional bare-metal C stack. This evidence positions Rust as a competitive choice for embedded firmware without efficiency trade-offs. The findings support shifting to Rust for its safety properties in resource-constrained industrial settings.

Core claim

The paper shows that concurrent C and Rust implementations of the same industrial microcontroller functionality yield comparable results on actual hardware for memory use and execution speed. The Ariel OS runtime in Rust further achieves a smaller footprint than the state-of-the-art bare-metal C stack traditionally employed in this domain.

What carries the argument

Side-by-side development of functionally equivalent C and Rust firmware for the same microcontroller task, with direct hardware measurements and comparison against the Ariel OS runtime.

If this is right

  • Rust can serve as a direct replacement for C in microcontroller firmware without expected increases in memory or slowdowns.
  • Ariel OS delivers a portable Rust runtime that is more compact than standard bare-metal C approaches.
  • Industrial teams can adopt Rust for its memory safety while maintaining competitive resource usage.
  • The approach enables portable firmware across microcontroller variants without performance penalties.

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 firmware vulnerabilities over time due to built-in safety checks.
  • The results invite similar head-to-head tests on other embedded platforms or for power consumption metrics.
  • Long-term maintenance costs might favor Rust even if initial development effort is similar.

Load-bearing premise

The two teams produced functionally equivalent implementations and applied comparable levels of optimization effort.

What would settle it

An independent replication study that measures memory and speed on the same hardware after equal optimization time for both languages.

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

2 major / 2 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 of iterative development. Hardware measurements of memory footprint and execution speed are presented, leading to the claims that there is no strong reason to prefer C over Rust on these metrics and that Ariel OS provides a smaller footprint than traditional bare-metal C stacks, making Rust a sound choice for this domain.

Significance. If the comparability of the implementations can be established, the work supplies useful empirical data from a real industrial setting on Rust versus C for resource-constrained firmware. The direct hardware measurements and the demonstration of Ariel OS efficiency constitute concrete, falsifiable contributions that can inform language selection in embedded systems.

major comments (2)
  1. [Abstract] Abstract: the claim that 'the analysis and measurements on hardware indicate no strong reason to prefer C over Rust' is not accompanied by error bars, statistical details, or quantitative evidence that optimization effort was equalized between the teams. This leaves the attribution of performance parity to language choice only partially verifiable.
  2. [Development and results sections] Development and results sections: the paper notes iterative development over months but supplies no quantitative metrics (person-hours, team experience levels, compiler flags, or code-size breakdowns) to demonstrate that the C and Rust implementations are functionally equivalent and were optimized to comparable degrees. Without such evidence the central language-comparison claim rests on an unverified assumption.
minor comments (2)
  1. Add explicit descriptions of the measurement methodology, including the exact hardware platform, compiler versions, and optimization settings used for each implementation.
  2. Ensure all figures reporting footprint and timing results include clear legends, units, and any relevant baseline configurations.

Simulated Author's Rebuttal

2 responses · 1 unresolved

We thank the referee for the detailed and constructive review. We address the major comments point by point below, indicating revisions where appropriate to improve the clarity and verifiability of our claims.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the claim that 'the analysis and measurements on hardware indicate no strong reason to prefer C over Rust' is not accompanied by error bars, statistical details, or quantitative evidence that optimization effort was equalized between the teams. This leaves the attribution of performance parity to language choice only partially verifiable.

    Authors: The measurements reported are single-run hardware measurements on the target microcontroller, which are deterministic for the given firmware and inputs. We did not include error bars because variability across runs is negligible in this context, but we will add a description of the measurement setup and tools used (e.g., specific debug probes and profiling methods) to the results section and reference it in the abstract. Regarding optimization effort, the teams had comparable expertise and worked under similar industrial constraints; however, we agree that explicit metrics would strengthen the claim. We will revise the abstract to state that the results are based on the observed implementations without claiming equal optimization effort was proven, and point to the development process description. revision: partial

  2. Referee: [Development and results sections] Development and results sections: the paper notes iterative development over months but supplies no quantitative metrics (person-hours, team experience levels, compiler flags, or code-size breakdowns) to demonstrate that the C and Rust implementations are functionally equivalent and were optimized to comparable degrees. Without such evidence the central language-comparison claim rests on an unverified assumption.

    Authors: We will expand the development section to include the compiler optimization flags used for both implementations (e.g., -Os for C and equivalent Rust flags). Code-size breakdowns are partially provided in the results; we will add more granular details on RAM and flash usage components where available. Team experience is described as both teams consisting of professional embedded software engineers with several years of experience in their languages. Unfortunately, exact person-hours were not tracked during the project, as the emphasis was on functional delivery rather than time accounting. Functional equivalence was verified through identical requirement specifications, shared test cases, and hardware-in-the-loop testing. We will note these aspects and any limitations explicitly in the revised manuscript. revision: partial

standing simulated objections not resolved
  • Exact person-hour expenditures for each team, as these metrics were not recorded during the industrial development process.

Circularity Check

0 steps flagged

No circularity: empirical case study with direct hardware measurements

full rationale

The paper is an empirical case study comparing concurrent C and Rust implementations of the same microcontroller firmware functionality, supported by hardware measurements of memory footprint and execution speed. No derivation chain, equations, fitted parameters, or predictions appear in the provided abstract or description. Claims rest on observed data from two teams rather than any self-definitional reduction, fitted input renamed as prediction, or load-bearing self-citation. The work is self-contained against external benchmarks (direct hardware runs) and does not invoke uniqueness theorems or ansatzes from prior author work.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the empirical comparability of two independently developed firmware versions and the representativeness of the chosen industrial IoT use case. No free parameters or invented entities are introduced.

axioms (1)
  • domain assumption The two teams produced functionally equivalent implementations with comparable optimization effort.
    Required to attribute performance outcomes to language choice rather than differences in implementation quality.

pith-pipeline@v0.9.0 · 5705 in / 1209 out tokens · 50315 ms · 2026-05-21T01:03:58.018351+00:00 · methodology

Review history (2 revisions) →

discussion (0)

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

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

39 extracted references · 39 canonical work pages · 1 internal anchor

  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 ACM SenSys, 2025

    work page 2025

  2. [2]

    Ariel OS: An Embedded Rust Operating System for Networked Sensors & Multi-Core Microcontrollers

    E. Frank et al. "Ariel OS: An Embedded Rust Operating System for Networked Sensors & Multi-Core Microcontrollers." Proceedings of IEEE DCOSS-IoT, 2025

    work page 2025

  3. [3]

    Rust in Android: Move Fast and Fix Things ,

    J.Van Der Stoep, “ Rust in Android: Move Fast and Fix Things ,” in Google Security Blog, Nov. 2025. Online: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html

    work page 2025

  4. [4]

    Online: https://staiotcraft.st.com

    ST AIoT Craft. Online: https://staiotcraft.st.com

    work page

  5. [5]

    SensorTile.box PRO with multi-sensors and wireless connectivity

    STMicroelectronics, “SensorTile.box PRO with multi-sensors and wireless connectivity”, Online: https://www.st.com/resource/en/data_brief/steval-mkboxpro.pdf

    work page

  6. [6]

    6-axis inertial measurement unit

    STMicroelectronics, LSM6DSV16X Datasheet DS13510, “6-axis inertial measurement unit”, Online: https://www.st.com/resource/en/datasheet/lsm6dsv16x.pdf

    work page

  7. [7]

    Online: https://www.st.com/en/development-tools/stm32cubemx.html

    STM32CubeMX: Stm32 Cube initialization code generator. Online: https://www.st.com/en/development-tools/stm32cubemx.html

    work page

  8. [8]

    Embassy Framework: https://github.com/embassy-rs/embassy

    work page

  9. [9]

    Online: https://github.com/STMicroelectronics/st-mems-rust-drivers

    STMicroelectronics MEMS Rust Drivers Repository. Online: https://github.com/STMicroelectronics/st-mems-rust-drivers

    work page

  10. [10]

    Online: https://github.com/Azure/opendigitaltwins-dtdl

    DTDL: Digital Twins Definition Language. Online: https://github.com/Azure/opendigitaltwins-dtdl

    work page

  11. [11]

    Online: https://learn.microsoft.com/en-us/previous-versions/azure/iot/overview-iot-plug-and-play

    Azure IoT Plug and Play (PnP). Online: https://learn.microsoft.com/en-us/previous-versions/azure/iot/overview-iot-plug-and-play

    work page

  12. [12]

    Online: https://github.com/kgabis/parson/

    Parson library. Online: https://github.com/kgabis/parson/

    work page

  13. [13]

    Rust for embedded systems: Current state and open problems

    A. Sharma et al. "Rust for embedded systems: Current state and open problems." Proceedings of ACM SIGSAC, 2024

    work page 2024

  14. [14]

    Tighten Rust’s belt: shrinking embedded Rust binaries

    H. Ayers et al. "Tighten Rust’s belt: shrinking embedded Rust binaries." Proceedings of ACM SIGPLAN/SIGBED LCTES, 2022

    work page 2022

  15. [15]

    Online: https://doc.rust-lang.org/book/ch17-00-async-await.html, 2026

    Rust Asynchronous Programming. Online: https://doc.rust-lang.org/book/ch17-00-async-await.html, 2026

    work page 2026

  16. [16]

    Online: https://github.com/rtic-rs/rtic, 2026

    RTIC. Online: https://github.com/rtic-rs/rtic, 2026

    work page 2026

  17. [17]

    Ownership is theft: Experiences building an embedded OS in Rust,

    A. Levy et al., “Ownership is theft: Experiences building an embedded OS in Rust,” in ACM PLOS, 2015

    work page 2015

  18. [18]

    Online: https://crates.io, 2026

    Rust Community Crate Registry. Online: https://crates.io, 2026

    work page 2026

  19. [19]

    Online: https://www.st.com/en/embedded-software/x-cube-mems1.html, 2026

    XCube MEMS. Online: https://www.st.com/en/embedded-software/x-cube-mems1.html, 2026

    work page 2026

  20. [20]

    Online: https://serde.rs/, 2026

    Serde Framework. Online: https://serde.rs/, 2026

    work page 2026

  21. [21]

    Online https://www.cyberresilienceact.eu/

    EU Cyber Resilience Act. Online https://www.cyberresilienceact.eu/

    work page

  22. [22]

    Online: https://sourceware.org/newlib/

    Newlib. Online: https://sourceware.org/newlib/

    work page

  23. [23]

    Online: https://github.com/rust-embedded/heapless

    Heapless crate. Online: https://github.com/rust-embedded/heapless

    work page

  24. [24]

    Oonline: https://www.st.com/en/evaluation-tools/x-nucleo-iks4a1.html

    X-NUCLEO-IKS4A1 MEMS expansion board for STM32 Nucleo. Oonline: https://www.st.com/en/evaluation-tools/x-nucleo-iks4a1.html

    work page

  25. [25]

    Online: https://github.com/google/bloaty

    Bloaty. Online: https://github.com/google/bloaty

    work page

  26. [26]

    Online: https://github.com/RazrFalcon/cargo-bloat

    Cargo-bloat. Online: https://github.com/RazrFalcon/cargo-bloat

    work page

  27. [27]

    Online: https://github.com/embassy-rs/static-cell

    StaticCell. Online: https://github.com/embassy-rs/static-cell

    work page

  28. [28]

    Online: https://github.com/rust-embedded-community/serde-json-core

    Serde JSON Core. Online: https://github.com/rust-embedded-community/serde-json-core

    work page

  29. [29]

    Eason, B

    G. Eason, B. Noble, and I. N. Sneddon, ``On certain integrals of Lipschitz-Hankel type involving products of Bessel functions,'' Phil. Trans. Roy. Soc. London, vol. A247, pp. 529--551, April 1955

    work page 1955

  30. [30]

    Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol

    J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68--73

    work page

  31. [31]

    I. S. Jacobs and C. P. Bean, ``Fine particles, thin films and exchange anisotropy,'' in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New York: Academic, 1963, pp. 271--350

    work page 1963

  32. [32]

    Elissa, ``Title of paper if known,'' unpublished

    K. Elissa, ``Title of paper if known,'' unpublished

    work page

  33. [33]

    Nicole, ``Title of paper with only first word capitalized,'' J

    R. Nicole, ``Title of paper with only first word capitalized,'' J. Name Stand. Abbrev., in press

    work page

  34. [34]

    Yorozu, M

    Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, ``Electron spectroscopy studies on magneto-optical media and plastic substrate interface,'' IEEE Transl. J. Magn. Japan, vol. 2, pp. 740--741, August 1987 [Digests 9th Annual Conf. Magnetics Japan, p. 301, 1982]

    work page 1987

  35. [35]

    Young, The Technical Writer's Handbook

    M. Young, The Technical Writer's Handbook. Mill Valley, CA: University Science, 1989

    work page 1989

  36. [36]

    D. P. Kingma and M. Welling, ``Auto-encoding variational Bayes,'' 2013, arXiv:1312.6114. [Online]. Available: https://arxiv.org/abs/1312.6114

    work page internal anchor Pith review Pith/arXiv arXiv 2013

  37. [37]

    Liu, ``Wi-Fi Energy Detection Testbed (12MTC),'' 2023, gitHub repository

    S. Liu, ``Wi-Fi Energy Detection Testbed (12MTC),'' 2023, gitHub repository. [Online]. Available: https://github.com/liustone99/Wi-Fi-Energy-Detection-Testbed-12MTC

    work page 2023

  38. [38]

    Department of Health and Human Services, Substance Abuse and Mental Health Services Administration, Office of Applied Studies, August, 2013, DOI:10.3886/ICPSR30122.v2

    ``Treatment episode data set: discharges (TEDS-D): concatenated, 2006 to 2009.'' U.S. Department of Health and Human Services, Substance Abuse and Mental Health Services Administration, Office of Applied Studies, August, 2013, DOI:10.3886/ICPSR30122.v2

    work page doi:10.3886/icpsr30122.v2 2006

  39. [39]

    Eves and J

    K. Eves and J. Valasek, ``Adaptive control for singularly perturbed systems examples,'' Code Ocean, Aug. 2023. [Online]. Available: https://codeocean.com/capsule/4989235/tree

    work page arXiv 2023