Sign in Subscribe
Firmware

Feature Flags in Firmware: Compile-Time vs Runtime Switches in Embedded Systems

Abhinav Singh

Abhinav Singh

— 5 min read
Feature Flags in Firmware: Compile-Time vs Runtime Switches in Embedded Systems

In modern embedded platforms, the ability to selectively enable or disable features is more than a convenience—it’s an essential tool for safe rollouts, rapid iteration, and predictable behavior across hardware variants. Firmware today powers ecosystems that span sensors, edge compute, wireless stacks, camera modules, and cloud-connected workflows. In this environment, feature flags become a foundational technique for managing complexity.

At Hoomanely, where our pet-care ecosystem includes sensing Trackers, behavior-aware EverBowls, and edge-compute EverHubs—all built on modular SoM-based designs—feature flags allow us to evolve firmware while keeping the ecosystem stable, testable, and predictable.

This article examines compile-time flags and runtime switches, why they matter in embedded systems, how they shape architecture, and where each pattern fits into a scalable IoT pipeline.

Concept: What Are Feature Flags in Firmware?

A feature flag is a conditional control that determines whether a piece of functionality is included, activated, or configured differently.

In firmware, this takes two broad forms:

  1. Compile-time flags
    • Controlled by your build system (CMake, Bazel, Make, Kconfig).
    • Decide what gets compiled into the binary.
    • Optimize size, remove branches, change drivers or behaviors, select hardware variants.
  2. Runtime switches
    • Configurable after deployment (from flash, EEPROM, NVM, or cloud-downloaded configs).
    • Adjust behavior without reflashing firmware.
    • Enable experiments, staged rollouts, A/B tests, or environment-specific tuning.

Both share a purpose: control complexity, reduce risk, and allow fast iteration without destabilizing the device.

Why Feature Flags Matter in Embedded and IoT Systems

Embedded systems live under constraints: limited compute, tight power budgets, deterministic timing, and field deployment realities.

Feature flags help solve key problems:

1. Safe Rollouts Without Full Reflash

Runtime switches give you the ability to toggle behavior in devices already deployed—especially important in a multi-product ecosystem like ours, where Trackers, EverBowls, and EverHubs update independently but work as a unified fleet.

2. Hardware Variants Built on the Same SoM

Compile-time flags allow one shared codebase to support multiple carrier boards, sensors, and connectivity options.

3. Managing Conditional Logic in Drivers and Middleware

Flags prevent scatterings of if (variant) … across the entire codebase, promoting cleaner layering.

4. Progressive Experimentation Without Risk

Runtime toggles allow only a subset of devices to test new motion-processing pipelines, audio classifiers, or telemetry compression strategies.

5. Deterministic Behavior in Safety-Critical Flows

Compile-time flags ensure no unexpected paths are taken in ISR-heavy or safety-sensitive code.

Feature flags are not just a pattern—they're a governance mechanism for complexity.

How It Works: Compile-Time vs Runtime Flags

Let’s break down what each does, their mechanics, and their trade-offs.

1. Compile-Time Feature Flags

These are decided during the build. Classic examples:

#if ENABLE_BAROMETER
    init_barometer();
#endif


Compile-time flags influence:

  • What modules/drivers enter the final binary
  • Which peripherals are initialized
  • Whether a SoM variant uses I2C or SPI for a given sensor
  • What RTOS tasks exist or are omitted
  • Which memory pools get compiled in
  • Which telemetry types are gathered or compressed

Why Embedded Engineers Use Them

  • Zero runtime overhead
    No branching, no checks—code is simply not present.
  • Keeps binary small
    Critical for MCUs or SoMs with tight flash/RAM budgets.
  • Enforces architectural guardrails
    If a path is unsafe to enable in the field, keep it compile-time only.
  • Maintains determinism
    Especially for timing-sensitive loops, ISR paths, DMA, and control logic.

Where It Fits in Hoomanely’s Ecosystem

Our devices share a modular SoM base but differ in peripherals and roles. Compile-time flags help us:

  • Include motion + barometer pipelines for Trackers
  • Include temperature + weight acquisition logic in EverBowls
  • Include edge-compute paths and multi-radio coordination for EverHubs

This keeps binary builds clean and tailored while sharing a common architecture.

2. Runtime Feature Switches

Runtime flags are toggles stored in persistent memory or fetched from cloud configs.

They allow you to shape behavior without reflashing:

if (cfg.enable_motion_filtering) {
    apply_motion_filter();
}

Possible runtime switches:

  • Tuning sensitivity of a classifier
  • Enabling/disabling experimental telemetry
  • Adjusting intervals or thresholds
  • Enabling new behavior models gradually
  • Turning debug logs on/off
  • Selecting compression strategies
  • Changing camera capture behavior
  • Switching between fallback wireless profiles

Why Runtime Flags Matter in IoT

  • Field experimentation
    Test new algorithms on only a portion of deployed Trackers.
  • Adaptive behavior
    A gateway like EverHub may adopt different local-decision policies based on environment.
  • Real-world safety
    You can disable problematic pipelines instantly if an anomaly emerges.
  • Cloud-driven orchestration
    Update hundreds of devices with a config push instead of OTA flash.

Trade-Offs

  • Runtime cost
    Every flag adds branching. In timing-sensitive loops (e.g., high-frequency sensor processing), this matters.
  • Risk of inconsistent states
    Devices can diverge unless flags are part of a synchronized config protocol.
  • More complex validation
    You need tests for every flag combination or restrict mutually exclusive flags.

Comparing the Two: When to Use Which?

You can’t treat compile-time and runtime flags as interchangeable. They serve different architectural purposes.

Use Compile-Time Flags When:

  • The feature affects binary size, memory layout, or ISR paths
  • Behavior must be deterministic
  • The feature is hardware-specific (e.g., presence of a sensor)
  • The impact is safety-critical
  • You want build-time enforcement of strong boundaries

Examples:
Sensor presence, driver selection, RTOS task topology, compression pipeline choices, watchdog configuration style.

Use Runtime Flags When:

  • You want dynamic behavior changes
  • You are orchestrating staged rollouts
  • You want to tune algorithms in the field
  • You need to switch fallback mechanisms during errors
  • You want cloud-configurable behavior without reflashing

Examples:
Motion sensitivity tuning, picture-capture frequency, telemetry interval adjustments, debug toggles.

Architecture: Designing a Clean Feature-Flag System

A robust system includes:

1. Global Feature Registry

A central table:

typedef struct {
    bool enable_motion;
    bool enable_smart_audio;
    bool enable_edge_decisions;
    bool enable_debug_logs;
} features_t;

This prevents scattered flags across modules.

2. Layering Between Flags and Modules

Modules should read flags, not define them.

Keep this flow:

Config Source → Feature Registry → Module Behavior

3. Cloud–Device Synchronization

Runtime flags need:

  • Versioning
  • Validation
  • Rollback strategy
  • Default-safe fallback values
  • Atomic updates in NVM

4. Flag Categorization

Flags typically fall into:

  • Safety-critical (compile-time only)
  • Performance-sensitive (compile-time or runtime depending on impact)
  • Experimental (runtime)
  • Operational (runtime)
  • Diagnostic (runtime)

5. Flag Gatekeeping

A review process ensures no accidental creation of unnecessary flags.

Real-World Usage: Lessons from a Multi-Device IoT Fleet

In the Hoomanely ecosystem, each device runs a different blend of pipelines:

  • Trackers focus on motion and environmental sensing
  • EverBowls process weight, temperature, sound, and image capture
  • EverHubs perform edge decisions, network coordination, and telemetry batching

Across these roles, feature flags help ensure:

1. Uniform Architecture Across Products

Compile-time flags let us maintain a shared firmware base while accommodating device-specific SoM carrier boards.

2. Safe Feature Experiments in the Field

Runtime toggles allow us to try new detection models on Trackers or adjust weight-processing heuristics on EverBowls without a binary update.

3. Consistent Cloud Governance

A central configuration system allows EverHubs to pull new feature toggles for experimental edge compression or new telemetry batching rules.

4. Reduced Firmware Fragmentation

One codebase, many roles—curated through feature gates.

These patterns generalize across any multi-device IoT ecosystem.

Common Pitfalls and How to Avoid Them

Pitfall 1: Too Many Flags

This results in combinatorial behavior explosion.

Fix:
Maintain a “flag budget” and require architectural approval for new flags.

Pitfall 2: Runtime Flags Inside Tight Loops

Branching inside sensor or DSP pipelines can introduce jitter.

Fix:
Snapshot all flags at boot or at each pipeline epoch and use cached static values.

Pitfall 3: Using Runtime Flags for Safety-Critical Behavior

Runtime-configurable watchdog paths, ISR behavior, or radio timing is dangerous.

Fix:
Make such features compile-time or locked behind gated OTA flows.

Pitfall 4: Mismatch Between Cloud Config and Firmware Expectations

Fields change names, types, or structure.

Fix:
Version both sides and use validation schemas.

Takeaways

Feature flags are more than convenience—they are architecture tools that shape how embedded systems scale, evolve, and stay safe.

Here’s what to keep in mind:

  • Compile-time flags control binary composition, determinism, safety, and hardware-specific behavior.
  • Runtime switches enable distributed experimentation, tuning, and cloud-driven orchestration.
  • A central registry, clean layering, and validation rules** make the system maintainable.
  • In complex IoT ecosystems, flags ensure consistency across diverse device roles while minimizing firmware fragmentation.
  • Thoughtful use of flags accelerates iteration without compromising reliability.

Thinking of feature flags not as #ifdef or config toggles—but as a governance framework—is what elevates embedded systems engineering from ad hoc decisions to scalable architecture.

Read more