Dynamic Runtime Feature Flags

In this lesson, you will learn how to design systems that toggle functionality based on detected hardware capabilities rather than static compile-time constants.

The Limitation of Compile-Time Features

In embedded Rust, we often use cargo features to enable or disable code based on the target hardware. However, this creates a "one binary, one target" constraint. If you are deploying firmware to a fleet of devices where some sensors or accelerators are optional or modular, static compilation forces you to maintain a combinatorial explosion of firmware variants.

Implementing Dynamic Runtime Flags

Dynamic Runtime Feature Flags shift this decision to the application startup phase. Instead of using #[cfg(feature = "...")], you define a capability struct that the system populates by probing the hardware at boot.

Consider a system where a high-performance cryptographic co-processor might or might not be present on the PCB:

struct HardwareCapabilities {
    has_crypto_accel: bool,
    max_clock_freq: u32,
}

impl HardwareCapabilities {
    fn detect() -> Self {
        // Query hardware registers or ID pins at runtime
        let has_crypto = crate::hal::probe_crypto_bus();
        Self {
            has_crypto_accel: has_crypto,
            max_clock_freq: 168_000_000,
        }
    }
}

Branching Logic vs. Trait Dispatch

Once you have initialized your HardwareCapabilities, you avoid cfg gates in your business logic. Instead, use a strategy pattern or simple branching. For performance-critical paths where branching overhead is unacceptable, use function pointers or trait objects initialized during the setup phase:

fn perform_encryption(data: &mut [u8], caps: &HardwareCapabilities) {
    if caps.has_crypto_accel {
        // Use hardware-accelerated path
        crate::crypto::hw_encrypt(data);
    } else {
        // Fallback to software implementation
        crate::crypto::soft_encrypt(data);
    }
}

This approach requires that both implementations are always compiled into the binary. While this increases the binary size slightly compared to pure cfg features, it grants you the immense flexibility of a single unified image that adapts instantly to the specific hardware revision it finds itself running on. This is critical for managing heterogeneous fleets where hardware capabilities evolve over the product lifecycle.

Key Takeaway: Replace static compile-time feature gates with runtime capability probing to enable universal firmware binaries that adapt to hardware variations upon boot.