Nine Rules for Running Rust on Embedded Systems

Do you want your Rust code to run everywhere — from large servers to web pages, robots, and even watches? In this final article of a three-part series [1, 2, 3], we’ll see how to use Rust to run on embedded devices using no_std.

Porting your Rust project to a no_std environment allows you to target microcontrollers and deeply embedded systems, creating highly efficient software for constrained environments. For example, I used the upcoming version of range-set-blaze to create an LED animation sequencer and compositor that runs on a Raspberry Pi Pico:

Running Rust without the standard library presents unique challenges. Without operating system support, features like file I/O, networking, and sometimes even dynamic memory allocation are unavailable. In this article, we’ll look at practical strategies to overcome these limitations.

Porting Rust to no_std requires careful steps and choices, and missing any step can lead to failure. We’ll simplify the process by following these nine rules, which we will examine in detail:Confirm that your project works with WASM WASI and WASM in the Browser.
Use target thumbv7m-none-eabi and cargo tree to identify and fix dependencies incompatible with no_std.
Mark main (non-test) code no_std and alloc. Replace std:: with core:: and alloc::.
Use Cargo features to let your main code use std optionally for file-related (etc.) functions.
Understand why test code always uses the standard library.
Create a simple embedded test project. Run it with QEMU.
In Cargo.toml, add keywords and categories for WASM and no_std.
[Optional] Use preallocated data types to avoid alloc.
Add thumbv7m-none-eabi and QEMU to your CI (continuous integration) tests.


Aside: These articles are based on a three-hour workshop that I presented at RustConf24 in Montreal. Thanks to the participants of that workshop. A special thanks, also, to the volunteers from the Seattle Rust Meetup who helped test this material. These articles replace an article I wrote last year with updated information.

As with the first and second articles in this series, before we look at the rules one by one, let’s define our terms.Native: Your home OS (Linux, Windows, macOS)
Standard library (std): Provides Rust’s core functionality — Vec, String, file input/output, networking, time.
WASM: WebAssembly (WASM) is a binary instruction format that runs in most browsers (and beyond).
WASI: WebAssembly System Interface (WASI) allows outside-the-browser WASM to access file I/O, networking (not yet), and time handling.
no_std: Instructs a Rust program not to use the full standard library, making it suitable for small, embedded devices or highly resource-constrained environments.
alloc: Provides heap memory allocation capabilities (Vec, String, etc.) in no_std environments, essential for dynamically managing memory.


Based on my experience with range-set-blaze, a data structure project, here are the decisions I recommend, described one at a time. To avoid wishy-washiness, I’ll express them as rules.

#EmbeddedRust#RustProgramming#EmbeddedSystems#RustLang#IoTDevelopment#SystemProgramming#LowLevelProgramming#RustEmbedded#RustForIoT

International Young Scientist Awards
Website link: youngscientistawards.com
Nomination Link: https://youngscientistawards.com/award-nomination/?ecategory=Awards&rcategory=Awardee
Contact Us: support@youngscientistawards.com _________________________________________________________________________________________________________

Social Media:

Twitter : https://twitter.com/youngsc06963908
Linkedin- : https://www.linkedin.com/in/shravya-r...
Pinterest : https://in.pinterest.com/youngscienti...
Blog : https://youngscientistaward.blogspot....
Tumblr : https://www.tumblr.com/blog/shravya9