Memory Mapped I/O Access

In this lesson, you will learn how to interact with hardware peripherals by treating memory addresses as direct gateways to device registers using volatile operations.

The Nature of Memory Mapped I/O (MMIO)

In low-level systems, hardware registers are mapped directly into the CPU's physical address space. Writing to a specific memory address doesn't update RAM; instead, it sends an electrical signal to a peripheral like a UART controller, a timer, or a GPIO pin.

Because the hardware—not the CPU—controls these memory locations, the compiler’s optimizer can behave unpredictably. If you write to a status register twice in a row, a standard Rust compiler might decide the first write is "useless" and delete it, or cache the register value in a CPU register instead of reading the hardware state. To prevent this, we use volatile read and write operations.

Implementing Volatile Access

In Rust, the standard library provides core::ptr::read_volatile and core::ptr::write_volatile to ensure every single memory access is respected by the compiler. We combine these with raw pointers to interact with specific device addresses.

// Assume a UART status register at address 0x4000_1000
const UART_STATUS_REG: *mut u32 = 0x4000_1000 as *mut u32;

/// Safely write a value to the MMIO register
pub fn write_register(value: u32) {
    unsafe {
        // We use volatile to prevent the compiler from eliding this write
        core::ptr::write_volatile(UART_STATUS_REG, value);
    }
}

/// Safely read the current status from the MMIO register
pub fn read_register() -> u32 {
    unsafe {
        // We use volatile to ensure the hardware is actually queried
        core::ptr::read_volatile(UART_STATUS_REG)
    }
}

Why This is "Safe" (Enough)

While the unsafe block is required due to raw pointer dereferencing, the abstraction itself is safe if you maintain the correct mapping. By wrapping raw pointer logic inside functions, you prevent the rest of your application from needing to know the implementation details of the hardware bus, ensuring that every interaction remains atomic and strictly observed by the compiler. Always remember: in MMIO, the memory is effectively "alive," and volatile is the mechanism that keeps the compiler from assuming it is just static storage.

Key Takeaway: Use core::ptr::read_volatile and core::ptr::write_volatile to bypass compiler optimizations and ensure hardware registers are accessed exactly as intended by your code.