Hardware and Resource Constraints

Systems and embedded programs often execute under strict hardware and resource constraints—such as a microcontroller with 256 KiB of Flash ROM and 32 KiB of SRAM, a real-time audio thread where heap allocation jitter is forbidden, or a kernel interrupt handler with a 2 KiB stack. Designing Rust code for constrained environments combines compile-time size optimization, zero-allocation static buffers, and explicit out-of-memory (try_reserve) handling.

Typical Microcontroller Memory Map (e.g., STM32 / Cortex-M4):
  0x0800_0000 +-----------------------------------+
              | Flash ROM (64 KiB - 512 KiB)      |  `.text` (Code) + `.rodata` (`const` tables)
              +-----------------------------------+
  0x2000_0000 +-----------------------------------+
              | SRAM (16 KiB - 128 KiB)           |  `.data` + `.bss` + Stack (grows down)
              +-----------------------------------+

1. Placing Lookup Tables in Flash ROM (const / static) Instead of RAM

On microcontrollers, Flash ROM is typically 4x–16x larger than SRAM. A static (immutable) or const array in Rust is placed in the read-only .rodata section in Flash ROM, consuming zero bytes of precious SRAM at runtime unless copied onto the stack!

2. Fallible Heap Allocation Without OOM Aborts (try_reserve)

In standard Rust, vec.push(x) or Vec::with_capacity(n) aborts the process if the allocator runs out of memory. On memory-constrained servers, kernels, or embedded devices with alloc, use Vec::try_reserve (and String::try_reserve / HashMap::try_reserve) to handle allocation failures gracefully via Result<(), TryReserveError>:

use std::collections::TryReserveError;

pub fn allocate_bounded_packet(size: usize) -> Result<Vec<u8>, TryReserveError> {
    let mut buf = Vec::new();
    // Attempt to allocate `size` bytes on the heap; returns `Err(TryReserveError)`
    // instead of aborting the process if the request is impossibly large or OOM!
    buf.try_reserve(size)?;
    buf.resize(size, 0x00);
    Ok(buf)
}

fn main() {
    // 1. Reasonable 1 KiB allocation succeeds:
    let small = allocate_bounded_packet(1024).unwrap();
    println!("Allocated small packet: {} bytes", small.len());

    // 2. Impossibly large allocation (isize::MAX as usize) returns `Err` cleanly without aborting:
    let huge = allocate_bounded_packet(isize::MAX as usize);
    println!("Huge allocation returned Err cleanly: {}", huge.is_err());
}

Allocated small packet: 1024 bytes
Huge allocation returned Err cleanly: true

3. Minimizing Binary Code Size (Cargo.toml Profile Tuning)

When targeting microcontrollers, WebAssembly (.wasm), or container images where every kilobyte of binary size matters, configure [profile.release] to optimize for size ("z" or "s"), enable Link-Time Optimization (lto = true), and abort on panic (eliminating stack-unwinding tables .eh_frame):

[profile.release]
opt-level = "z"       # Optimize aggressively for minimal code size ("s" or "z")
lto = true            # Whole-program Link-Time Optimization across all crates
codegen-units = 1     # Single codegen unit for maximum dead-code elimination
panic = "abort"       # Strip stack-unwinding machinery and `.eh_frame` tables
strip = "symbols"     # Strip symbol tables from the final binary