As a best-selling author, I invite you to explore my books on Amazon. Don't forget to follow me on Medium and show your support. Thank you! Your support means the world!
The embedded systems world has long been dominated by C and assembly language. As someone who has spent years working in this space, I've witnessed firsthand how these low-level languages give developers the control they need while often sacrificing safety and maintainability. Rust changes this equation fundamentally.
When I first encountered Rust for embedded development, I was skeptical. Could a modern language really deliver the performance and resource efficiency needed for constrained devices? After implementing numerous projects across various microcontrollers, I can confidently say that Rust delivers on its promises.
Rust's memory safety guarantees come without runtime overhead, which is crucial for embedded systems. The language's ownership model enables compile-time verification that prevents memory corruption issues without imposing runtime penalties.
The No-Std Approach
For most embedded applications, the full Rust standard library is too heavy. Instead, we use the #![no_std] attribute to develop without the standard library, relying on the minimal core library instead:
#![no_std]
#![no_main]
use core::panic::PanicInfo;
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {}
}
#[no_mangle]
pub extern "C" fn _start() -> ! {
loop {}
}
This bare-bones example shows the minimal structure needed for a Rust program that can run on embedded hardware without an operating system. The no_std approach dramatically reduces binary size and eliminates heap requirements.
Memory Footprint Optimization
On microcontrollers where every byte counts, careful optimization is essential. Rust provides several tools:
The Link-Time Optimization (LTO) flag can significantly reduce binary size by eliminating unused code across module boundaries:
// In Cargo.toml
[profile.release]
lto = true
opt-level = "z" // Optimize for size
codegen-units = 1
For extremely size-constrained environments, the panic="abort" setting prevents the generation of unwinding code:
// In Cargo.toml
[profile.release]
panic = "abort"
I've reduced firmware sizes by up to 40% by applying these techniques in production projects.
Real-Time Hardware Control
Working with hardware peripherals in Rust feels precise and expressive. Using community-developed HAL crates, we can write hardware interaction code that's both safe and readable:
// Controlling an LED on STM32F3 hardware
#[entry]
fn main() -> ! {
let dp = stm32f3xx_hal::pac::Peripherals::take().unwrap();
let mut rcc = dp.RCC.constrain();
let mut gpioe = dp.GPIOE.split(&mut rcc.ahb);
// Configure PE9 as push-pull output
let mut led = gpioe
.pe9
.into_push_pull_output(&mut gpioe.moder, &mut gpioe.otyper);
loop {
led.set_high().unwrap();
delay(500_000);
led.set_low().unwrap();
delay(500_000);
}
}
This code is not just concise but also prevents many common errors at compile time. The type system ensures you can't accidentally misconfigure pins or use them in incorrect states.
Interrupt Handling
Interrupts are essential for responsive embedded systems. Rust's safety principles extend to interrupt handling through the cortex-m-rt crate:
#[interrupt]
fn EXTI0() {
static mut COUNTER: u32 = 0;
*COUNTER += 1;
if *COUNTER % 2 == 0 {
// Safe access to static mutable state within the interrupt
// context, without data races
}
}
The #[interrupt] attribute establishes a safe context for the interrupt handler. Using static mut variables within this context is safe because the compiler guarantees they're only accessed from this specific interrupt.
Hardware Abstraction Layers
The embedded-hal ecosystem provides traits that define standard interfaces for common peripherals:
use embedded_hal::digital::v2::OutputPin;
struct Led<T: OutputPin> {
pin: T,
}
impl<T: OutputPin> Led<T> {
fn new(pin: T) -> Self {
Led { pin }
}
fn on(&mut self) -> Result<(), T::Error> {
self.pin.set_high()
}
fn off(&mut self) -> Result<(), T::Error> {
self.pin.set_low()
}
}
This approach enables writing hardware-agnostic code that works across different microcontroller families. I've reused the same driver code across STM32, nRF52, and SAMD21 platforms with minimal changes.
Direct Register Access
Sometimes HALs add too much abstraction. For performance-critical code, Rust provides safe ways to interact directly with hardware registers:
use core::ptr::{read_volatile, write_volatile};
const GPIO_BASE: usize = 0x40020000;
const GPIO_ODR_OFFSET: usize = 0x14;
fn set_pin_high(pin: u8) {
unsafe {
let gpio_odr = (GPIO_BASE + GPIO_ODR_OFFSET) as *mut u32;
let current = read_volatile(gpio_odr);
write_volatile(gpio_odr, current | (1 << pin));
}
}
The unsafe block clearly marks where we're stepping outside Rust's safety guarantees, but contains the unsafe operations to a minimal scope.
Static Memory Allocation
Embedded systems often avoid dynamic memory allocation. Rust provides excellent tools for static allocation:
use heapless::Vec;
fn process_sensor_data() {
// A fixed-capacity vector allocated on the stack
let mut readings: Vec<u16, 64> = Vec::new();
for _ in 0..10 {
if let Some(reading) = get_sensor_reading() {
if readings.push(reading).is_err() {
// Handle the case where our buffer is full
}
}
}
// Process readings
}
The heapless crate provides collections like Vec, String, and HashMap that allocate their memory either on the stack or in static memory, avoiding heap fragmentation issues.
Concurrency Without Data Races
For devices with multiple cores or complex interrupt systems, Rust's ownership model eliminates data races:
use core::cell::RefCell;
use cortex_m::interrupt::{free, Mutex};
static SHARED_DATA: Mutex<RefCell<u32>> = Mutex::new(RefCell::new(0));
fn update_shared_data(value: u32) {
free(|cs| {
let mut data = SHARED_DATA.borrow(cs).borrow_mut();
*data = value;
});
}
fn read_shared_data() -> u32 {
free(|cs| {
*SHARED_DATA.borrow(cs).borrow()
})
}
This pattern ensures that shared data is accessed in a coordinated manner, preventing race conditions without runtime overhead.
Memory-Mapped Peripherals
The volatile-register crate provides a safe interface for working with memory-mapped hardware registers:
use volatile_register::{RW, RO};
#[repr(C)]
struct GpioRegisters {
moder: RW<u32>, // Mode register
otyper: RW<u32>, // Output type register
ospeedr: RW<u32>, // Output speed register
pupdr: RW<u32>, // Pull-up/pull-down register
idr: RO<u32>, // Input data register
odr: RW<u32>, // Output data register
}
fn configure_gpio(gpio: &mut GpioRegisters) {
// Safe access to hardware registers
gpio.moder.write(0x55555555);
}
This approach balances safety and control, marking registers as read-only or read-write according to hardware capabilities.
Communication Protocols
Implementing communication protocols in Rust is concise and safe. Here's an I2C example using embedded-hal traits:
use embedded_hal::blocking::i2c::{Write, WriteRead};
struct TemperatureSensor<I2C> {
i2c: I2C,
address: u8,
}
impl<I2C, E> TemperatureSensor<I2C>
where
I2C: Write<Error = E> + WriteRead<Error = E>,
{
pub fn new(i2c: I2C, address: u8) -> Self {
TemperatureSensor { i2c, address }
}
pub fn read_temperature(&mut self) -> Result<f32, E> {
let mut buffer = [0u8; 2];
// Write register address 0x01, then read two bytes
self.i2c.write_read(self.address, &[0x01], &mut buffer)?;
// Convert bytes to temperature value
let raw_temp = u16::from(buffer[0]) << 8 | u16::from(buffer[1]);
Ok(raw_temp as f32 * 0.0625)
}
}
RTOS Integration
For more complex applications, Rust works well with real-time operating systems:
use rtic::app;
#[app(device = stm32f4xx_hal::pac, peripherals = true)]
const APP: () = {
struct Resources {
led: GpioPin,
timer: Timer<TIM2>,
}
#[init]
fn init(ctx: init::Context) -> init::LateResources {
let device = ctx.device;
// Configure system clock, GPIO, timer
init::LateResources {
led: led_pin,
timer: configured_timer,
}
}
#[task(binds = TIM2, resources = [led, timer])]
fn timer_tick(ctx: timer_tick::Context) {
static mut LED_STATE: bool = false;
// Toggle LED
if *LED_STATE {
ctx.resources.led.set_low().unwrap();
} else {
ctx.resources.led.set_high().unwrap();
}
*LED_STATE = !*LED_STATE;
// Clear interrupt flag
ctx.resources.timer.clear_interrupt();
}
};
The RTIC (Real-Time Interrupt-driven Concurrency) framework provides a structured way to handle tasks and interrupts while maintaining Rust's safety guarantees.
Debugging and Testing
Rust's testing framework adapts well to embedded development:
#[cfg(test)]
mod tests {
use super::*;
struct MockI2C {
expected_address: u8,
expected_register: u8,
mock_response: [u8; 2],
}
impl WriteRead for MockI2C {
type Error = ();
fn write_read(&mut self, address: u8, bytes: &[u8], buffer: &mut [u8])
-> Result<(), Self::Error>
{
assert_eq!(address, self.expected_address);
assert_eq!(bytes[0], self.expected_register);
buffer[0] = self.mock_response[0];
buffer[1] = self.mock_response[1];
Ok(())
}
}
impl Write for MockI2C {
type Error = ();
fn write(&mut self, _address: u8, _bytes: &[u8]) -> Result<(), Self::Error> {
Ok(())
}
}
#[test]
fn test_temperature_conversion() {
let mock = MockI2C {
expected_address: 0x48,
expected_register: 0x01,
mock_response: [0x01, 0x60],
};
let mut sensor = TemperatureSensor::new(mock, 0x48);
let temp = sensor.read_temperature().unwrap();
assert_eq!(temp, 22.0);
}
}
This unit testing approach verifies hardware interactions without requiring actual hardware, enabling test-driven development for embedded systems.
Power Management
Efficient power management is critical for battery-powered devices. Rust allows precise control over power states:
fn enter_low_power_mode<D>(delay: &mut D)
where
D: embedded_hal::blocking::delay::DelayMs<u32>
{
// Configure peripherals for low power
disable_unused_peripherals();
// Set CPU to low-power mode
cortex_m::asm::wfi();
// Wake up and restore normal operation
delay.delay_ms(10);
restore_peripherals();
}
Optimization Techniques
For performance-critical sections, Rust offers various optimization techniques:
#[inline(always)]
fn critical_timing_function() {
// Time-sensitive operations guaranteed to be inlined
}
#[repr(align(4))]
struct AlignedBuffer {
data: [u8; 64],
}
// Use hardware-specific SIMD instructions
#[cfg(target_arch = "thumbv7em")]
fn fast_data_processing(data: &[u32; 4]) -> u32 {
use core::arch::arm::*;
unsafe {
let data_vec = vld1q_u32(data.as_ptr());
let sum_vec = vaddq_u32(data_vec, data_vec);
vgetq_lane_u32(sum_vec, 0)
}
}
Binary Size Analysis
To monitor code size, the cargo-bloat tool provides detailed information:
$ cargo bloat --release
Analyzing target/thumbv7em-none-eabihf/release/firmware
File .text Size Crate Name
0.8% 1.0% 1.2KiB std core::fmt::float::float_to_decimal_common_shortest
0.7% 0.9% 1.0KiB std core::fmt::float::strategy::dragon::format_exact
0.6% 0.8% 952B std core::fmt::Formatter::pad_integral
0.6% 0.7% 844B std <str as core::fmt::Display>::fmt
0.5% 0.6% 736B std core::str::pattern::matchable::search_indices
I regularly use this tool to identify and eliminate code bloat in firmware projects.
Firmware Updates and Security
For devices that support firmware updates, Rust's type system helps implement robust update mechanisms:
struct FirmwareHeader {
magic: [u8; 4],
version: u32,
size: u32,
checksum: u32,
}
fn validate_firmware(header: &FirmwareHeader, data: &[u8]) -> bool {
if header.magic != [b'R', b'U', b'S', b'T'] {
return false;
}
if header.size as usize != data.len() {
return false;
}
let calculated_checksum = calculate_crc32(data);
calculated_checksum == header.checksum
}
Conclusion
Rust brings unprecedented safety to embedded development without sacrificing performance. The language's zero-cost abstractions and powerful type system catch errors at compile time that would be hard to detect in other languages.
As embedded systems become more complex and connected, the importance of writing secure, reliable code increases. Rust addresses these needs while maintaining the control and efficiency that embedded development demands.
The ecosystem continues to mature, with growing support for microcontrollers, development boards, and embedded-specific tools. For developers willing to invest in learning its concepts, Rust offers a compelling path forward for embedded systems development that balances safety, performance, and expressiveness.
101 Books
101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.
Check out our book Golang Clean Code available on Amazon.
Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!
Our Creations
Be sure to check out our creations:
Investor Central | Investor Central Spanish | Investor Central German | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools
We are on Medium
Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva
Top comments (0)