The Illusion of Flexibility [Part-2]: Configurable Embedded Systems Lead to Chaos

Murat Cakmak
Dec 10, 2025
3 min read

The modern trend in embedded development, championed by projects like Zephyr, has adopted the complex recipe model of desktop Linux. While superficially appealing, this pursuit of universal flexibility fundamentally misaligns with the demands of safe and secure, high-quality, high-performance, and resource-constrained embedded design.

We must pull back the curtain on the hidden costs and inevitable complexity this approach forces onto the end developer.

-------------------------------------------------------------------------------------------------

This is a series of blogs before talking about the solutions

[🔗 See here ] Part 1: The Untestable Universe: Where Quality Control Breaks Down
[This Blog] Part 2: The Hidden Cost of "Hello World" Apps
[Incoming] Part 3: Security Risk & Deskilling
[Incoming] Part 4: Solutions?

Part 2. The Hidden Cost of "Hello World": Why Configurable SDKs Fight Optimisation

The first step with any modern embedded Software Development Kit (SDK) is deceptively simple. You select a target board, tick a few boxes in a configuration menu, hit "compile," and—voilà—your "Hello World" or "Blinky" demo is running. The entry barrier is low, and the immediate gratification is high.

However, this initial simplicity is not a feature; it's a trap. The high-level configuration is a curtain hiding an overwhelming amount of complexity, bloat, and chaos that actively works against the goals of any serious, performance-critical embedded product.

I. The Lure of the Black Box Development

For a novice developer, the Kconfig/Devicetree approach is a blessing. For a seasoned engineer aiming for maximum performance, minimum footprint, and robust stability, it is a curse.

The configurable SDK forces developers into a Black Box model: you interact with the system via configuration files, trusting that the tools (like CMake and Kconfig) will correctly and efficiently generate the optimised binary you need.

But when you need to shave off precious kilobytes of flash, reduce startup latency by a few microseconds, or resolve a complex hard-fault, you are forced to lift the lid on this black box. What you find is not clean, purpose-built code, but a multi-layered mess:

Generic Startup Chaos: The startup routines and initial hardware initialisation sequences are written to handle every potential configuration on every supported piece of silicon. This generality means they are inherently inefficient, loaded with conditional logic, and far less optimal than a hand-tuned, single-purpose startup sequence.
Overly Complex Linker Scripts: Linker scripts, the roadmap that tells the compiler where and how to place code in memory, are massive, tangled structures designed to accommodate every possible feature and memory layout. Debugging a memory overflow or a specific data placement issue can be a nightmare, involving tracing through hundreds of lines of conditional and generalised linker directives.
Unnecessary Bloat and Shadow Code: Even after Kconfig "prunes" features, the core system often compiles and links massive, generic library files and driver stubs that remain structurally present, wasting valuable Flash memory. The developer spends days tracing the compiled image to identify and surgically remove this "shadow code" that the build system was too generic to eliminate efficiently.

II. The Cost of Abstraction: Generality over Efficiency

The goal of these SDKs is to be universally applicable, to abstract the hardware so developers can easily port their code across different CPU vendors. The tool that pays for this portability is performance.

Code designed to be configured to handle everything is not optimised to handle one specific thing well.

Runtime Overhead: The system must always maintain a generalised structure to support its configurability. Kernel objects are often heavier, context switching may involve more checks, and the driver's design must account for multiple potential usage scenarios. This introduces subtle but measurable runtime overhead that doesn't exist in a tailored, purpose-built operating system or a bare-metal environment.
Wasted Cycles: The final compiled code is riddled with conditional logic (e.g., if (FEATURE_X_ENABLED)). Even if the feature is disabled at compile time, the code path must remain manageable and often involves more complex branches than would exist in a targeted implementation. For hard real-time systems, this introduces unpredictable latency and violates the core engineering goal of deterministic behaviour.

The illusion of a simple, quick start eventually gives way to the painful reality that the system is fundamentally fighting your optimisation efforts. For projects where every cycle and every kilobyte matters, the configurable approach is an anchor, not a sail.