12.2 Resource Management

Resource Management and Efficient Rust

This chapter has brought together everything you already know about Rust, concurrency, embedded systems, and the ESP32 ecosystem. The next step is understanding why Rust’s design is so powerful for resource-constrained devices, and how its foundational principles of ownership, borrowing, zero-cost abstractions, and compile-time guarantees, translate directly into better, safer, and more efficient embedded software. On microcontrollers, where every byte of RAM counts and concurrency bugs can lock up hardware, these features are not abstractions: they are critical strategies.

Advanced Ownership & Borrowing: The Foundation of Safe Hardware Access

We have covered Rust’s ownership and borrowing rules in detail at a high level. But on embedded systems, these rules take on a deeper meaning. In desktop programming, &mut self simply means “I can mutate this object.” In embedded, it means you have exclusive access to a physical piece of hardware at compile time and the compiler prevents two parts of your program from touching the same peripheral.

This is achieved using a classic PAC/HAL split:

Peripheral Access Crate (PAC): Generated from the chip’s SVD file. It exposes every hardware register. The result is a type-safe Rust API where every register and bitfield becomes a Rust structure or method. This ensures correct register access at compile time and gives developers a reliable, manufacturer-accurate representation of the hardware without writing any low-level boilerplate by hand.
Hardware Abstraction Layer (HAL): The HAL takes ownership of specific peripherals. When you write: let serial = Serial::new( peripherals.UART0, pins.tx, pins.rx); the Serial driver owns UART0. No other task can use that UART because the PAC type it required has been moved and is no longer available. The compiler enforces exclusive access to the hardware. This is hardware safety and not just memory safety. Rust prevents race conditions at the peripheral level, something FreeRTOS, C, and C++ cannot do without heavy discipline and fragile locking.

Zero-Cost Abstractions: High-Level Code, No Runtime Penalty

In embedded systems, abstraction is usually the enemy: virtual functions, dynamic allocation, and runtime dispatch all increase latency and code size. Rust avoids this through zero-cost abstractions (ZCAs). The most important mechanism is traits combined with monomorphisation, for example:

fn write_to_display<T: SpiDevice>(dev: &mut T) {
    dev.write(&[0x01, 0x02]);
}

The compiler generates a specialised version of this function for the actual SPI device you’re using. The result:

No vtables
No dynamic dispatch
No runtime overhead
Fully inlined, tight machine code

You get the readability and modularity of high-level code with the efficiency of hand-written C. This is one of embedded-Rust’s key strengths.

Memory Footprint Reduction: Efficient Use of Tiny RAM

Because many ESP32 devices have only tens or hundreds of kilobytes of RAM, Rust provides several tools for controlling allocation and avoiding fragmentation. heapless: predictable, stack-based data structures, which provides types like:

heapless::Vec
heapless::String
heapless::Queue

All of these allocate fixed-capacity buffers at compile time, meaning:

No heap
No malloc/free
No runtime fragmentation
Predictable memory usage

For deeply embedded systems, this is often essential.

Here is a minimal example showing heapless in practice. Notice that the capacity is a const-generic parameter, i.e., it is part of the type and is resolved entirely at compile time, leaving no runtime overhead:

use heapless::Vec;
use heapless::String;

// A Vec that holds at most 8 u8 values - capacity is baked into the type
let mut buf: Vec<u8, 8> = Vec::new();

buf.push(0x01).ok();  // push() returns Result; .ok() discards the error here
buf.push(0x02).ok();

// Attempting to push beyond capacity returns Err - no panic, no heap involved
for i in 3..20u8 {
    if buf.push(i).is_err() {
        // Handle full buffer: log the situation and break
        break;
    }
}

// A fixed-capacity string (max 64 bytes of UTF-8)
let mut msg: String<64> = String::new();
msg.push_str("Sensor OK").ok();

The push-and-check pattern replaces the implicit “panic on out-of-memory” behaviour of std::Vec. This makes buffer overflows visible and handleable at the point they occur rather than causing an unrecoverable crash at runtime.

By default, no_std code uses only core, which excludes dynamic memory allocation. You can optionally add an allocator (via the alloc crate) for async tasks or buffers, but Rust encourages you to avoid dynamic allocation unless necessary. The result is firmware that is compact, predictable, and stable over long runtimes.

Macros for Efficiency and Boilerplate Removal

Boilerplate refers to the repetitive, mechanical code you must write again and again to set up a feature, even though the code itself is not conceptually interesting. In embedded systems this often includes long initialisation blocks, register-setup sequences, interrupt declarations, or repetitive patterns for logging and task management.

Rust’s macro system is far more powerful and type-safe than C’s preprocessor. In embedded development, macros are used extensively to generate efficient code at compile time. For example:

defmt::info! Produces extremely lightweight debug logs optimised for embedded targets.
rtic::app! Generates an entire real-time application structure with compile-time guarantees about resource access, task priority, and interrupt safety.
HAL register-access macros Expand into tightly optimised bit-field manipulations.

These macros reduce boilerplate while generating human-readable, efficient machine code, again, with zero runtime cost.

Testing Strategies for Embedded Rust

Good embedded software must be testable, and Rust’s tooling encourages this using the following:

Unit tests on your PC (cargo test): You can test hardware-independent logic (parsers, algorithms, protocol handlers) directly on your host machine:

fast
safe
easy to integrate in Continuous Integration (CI) systems, so tests run automatically on every commit (as discussed towards the end of the GitLab chapter).

This dramatically increases software reliability before you ever flash the device.

Integration & Hardware-in-the-Loop Testing: With probe-rs you can:

Flash your firmware
Run tests directly on the target
Collect logs using defmt
Have failures reported through Cargo

This means you can have a full hardware test pipeline embedded directly into your Rust workflow, with almost no additional tooling.

Here is a minimal example that demonstrates a simple unit test in Rust: In src/lib.rs or src/main.rs, add a #[cfg(test)] module with your tests:

// For example, in src/lib.rs
// A small function we want to test
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

// Unit tests live in a special test module
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add() {
        assert_eq!(add(2, 3), 5);
    }
}

Running the test: From the project root:

cargo test

Cargo compiles the test runner and executes all tests marked with #[test].

PS C:\EEN1097> cargo test
   Compiling tutorial_11 v0.1.0 (C:\EEN1097\)
warning: function `add` is never used
…
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.36s
     Running unittests src\lib.rs (target\debug\deps\tutorial_11-704225cc3d43d340.exe)

running 1 test
test tests::test_add ... ok

Usefully, Rust under VS Code will provide helpful “Run Test” options.

Figure 2. A snippet of the VS Code interface.

Resource Management and Efficient Rust Conclusion

Rust’s resource-management model directly addresses the biggest challenges in embedded systems:

Safety: Exclusive peripheral access via ownership
Efficiency: Zero-cost abstractions and predictable memory usage
Tiny footprint: heapless data structures, minimal runtime
Robust testing: From unit tests to hardware-in-the-loop

These are not optional features, but are essential for building reliable, concurrent, and long-lived software on microcontrollers. Rust provides them by design, turning what is normally difficult embedded engineering into something structured, testable, and safe.

🧩 Knowledge Check

Code Cloze

Rust

Zero-Cost Abstractions and SVD

derekmolloy.ie

Quiz

Select 0/1

In the context of embedded Rust, what is the primary benefit of the PAC (Peripheral Access Crate) and HAL (Hardware Abstraction Layer) split?

derekmolloy.ie

Quiz

Select 0/1

Why are collections from the `heapless` crate often preferred over standard `std` collections in deeply embedded systems?

derekmolloy.ie