Defensive Driver Design

In this lesson, you will learn how to design drivers that gracefully handle corrupt or malicious hardware feedback without triggering a system-wide panic.

In embedded systems, hardware behaves unexpectedly: register values can be bit-flipped by cosmic rays, EMI, or even a faulty sensor returning out-of-range data. If your driver code uses unwrap() or expect() on register reads, a single "impossible" hardware state will crash the entire system. In a defensive design, the hardware must be treated as an untrusted external entity.

The Defensive Wrapper Pattern

To achieve this, we avoid direct exposure of raw hardware values. Instead, we implement a validation layer that acts as a gatekeeper. By defining an InternalResult type, we can transform potentially volatile hardware states into robust Rust Result enums before the rest of your application logic ever sees them.

Consider a temperature sensor returning a 16-bit register value:

pub enum SensorError {
    InvalidData(u16),
    HardwareTimeout,
}

pub struct TemperatureDriver {
    reg: *mut u16,
}

impl TemperatureDriver {
    pub fn read_temp(&self) -> Result<f32, SensorError> {
        // Defensive read: Never trust the raw register value
        let raw = unsafe { core::ptr::read_volatile(self.reg) };

        // Validate against physical constraints
        if raw > 0x0FFF {
            return Err(SensorError::InvalidData(raw));
        }

        Ok(raw as f32 * 0.1)
    }
}

By returning a Result, the driver pushes the responsibility of recovery to the caller. The caller can now decide whether to retry the operation, log the fault, or enter a safe state—all without invoking the panic! handler.

Why this is essential

When writing drivers for constrained environments, the "Defensive Driver Design" philosophy dictates that you assume the hardware is constantly lying to you. By validating the bit-depth, ranges, and expected handshakes of your peripheral communication, you create a bulkhead. Even if a specific hardware register enters a "garbage" state, your driver reports an error value rather than allowing a memory safety violation or a kernel panic to propagate through the stack.

Key Takeaway: Treat every hardware register as an untrusted source by validating all inputs against physical invariants and surfacing errors through Result instead of crashing on invalid feedback.