IoT PCBA Firmware Design Bare-Metal vs RTOS in 2026

The right choice for iot pcba firmware design depends on application complexity, timing requirements, memory constraints, power budget, and cost. In 2026, both sides of the rtos vs. bare metal debate remain viable, and development teams often mix both approaches within a single product line. This comparison frames firmware architecture as a decision driven by project requirements, not by which approach is inherently better. Each option serves different needs, and embedded firmware teams succeed when they match the architecture to the job.

Key Takeaways

• Choose firmware architecture based on your project's complexity, timing needs, memory, power, and cost.
• Bare-metal firmware offers simplicity and low overhead for single-task devices.
• An RTOS provides structure and scalability for multi-task products with real-time requirements.
• Hybrid designs combine both approaches to balance efficiency and concurrency.
• Plan for future changes: you can migrate between bare-metal and RTOS as your product evolves.

Bare-Metal vs RTOS: The Core Difference

What Bare-Metal Firmware Is

Bare-metal firmware runs directly on the microcontroller without an operating system layer. The developer writes a simple main loop that polls inputs, executes logic, and drives outputs in a fixed sequence. This bare-metal loop gives the team full control over every instruction and every byte of RAM. Interrupt service routines handle urgent events, and the main code resumes when the handler returns. A bare-metal architecture keeps the code path short and predictable, which suits small, focused devices. Many engineers still choose bare metal programming for cost-sensitive sensors and simple actuators.

What an RTOS Provides

A real-time operating system adds a scheduler, inter-task communication, and timing services on top of the hardware. Developers split work into rtos tasks, and the kernel decides which task runs next. Real-time scheduling supports priorities, so a critical task preempts lower-priority work within a bounded time. The rtos also supplies queues, semaphores, and software timers that simplify coordination between concurrent activities. This firmware architecture scales well when a product must handle several jobs at once. Teams that adopt an rtos gain structure and reusable components across projects.

The Hybrid Middle Ground

Many 2026 designs blend both models. A bare-metal programming approach can handle the boot path and low-level drivers, while an rtos manages the application layer. Some teams run a bare metal programming style inside a single high-priority task and reserve the scheduler for background work. This hybrid keeps the footprint small and still delivers concurrency where it matters. The choice between bare-metal and rtos programming therefore becomes a spectrum, not a binary switch.

Technical Performance: RTOS vs. Bare Metal

Performance separates the two architectures in measurable ways. Three dimensions matter most for IoT PCBA firmware design: timing behavior, memory use, and power draw. Each dimension favors a different architecture under different conditions, and each one deserves a close look before a team commits to a firmware path.

Determinism and Timing Behavior

Bare-metal firmware follows a single, known code path. The processor executes instructions in order, and an interrupt service routine runs the moment hardware raises a flag. This structure delivers short interrupt latency and highly deterministic behavior. A developer can count cycles and predict exactly when each action completes. Timing determinism therefore comes naturally to bare-metal programming, provided the interrupt handlers stay brief.

An rtos changes this picture. The kernel inserts a scheduler between the application and the hardware. A task switch costs cycles, and context switching latency adds to every preemption. The scheduler also runs a periodic tick, which introduces jitter into short timing windows. These costs are small on modern Cortex-M parts, yet they exist and must be budgeted.

The trade works in the other direction for complex systems. A priority-based rtos gives deterministic response times to critical tasks, even when lower-priority work is running. A well-configured kernel bounds the worst-case delay for the highest-priority thread. Engineers who need real-time determinism across several concurrent activities often find the scheduler easier to reason about than a large bare metal loop.

Simple bare-metal code offers predictable response times for a single job. The same code struggles when ten jobs compete, because each new feature lengthens the main loop and delays everything behind it. An rtos keeps predictable latency as the task count grows, since priorities decide the order of execution.

Memory Footprint and RAM Usage

Memory is the most concrete differentiator. Bare-metal firmware carries no kernel, no scheduler tables, and no task stacks beyond the main stack. Every byte of flash and RAM goes to application code. An rtos reserves flash for the kernel and RAM for each task control block and stack. Hubble compared the footprints of FreeRTOS, Zephyr, and bare-metal builds on common IoT microcontrollers.

A simple rule follows from these numbers. Hubble notes that devices with less than 32 KB of RAM and limited flash leave little room for kernel overhead:

Devices with less than 32 KB of RAM and limited flash. An RTOS kernel, even a small one, is overhead you may not be able to afford.

Ezurio reaches a similar conclusion in its comparison of Zephyr and FreeRTOS. FreeRTOS fits more easily into parts under 32 KB of flash, while Zephyr needs careful trimming at that size. FreeRTOS also uses less RAM per thread, because Zephyr adds thread metadata and optional memory protections. Both kernels fit comfortably once flash reaches 64 KB. Ezurio offers practical guidance for each class of device:

• Ultra-constrained devices with tiny memory and ultra-low power budgets suit bare-metal code or a small kernel such as FreeRTOS.
• FreeRTOS's stripped-down design often yields slightly lower power use and memory consumption, since no extra code runs.
• Zephyr runs efficiently on modest hardware and shines when a project can afford its advanced subsystems.

These thresholds guide hardware selection early. A team that picks a 32 KB flash part commits to bare-metal programming by default. A team that plans OTA updates, a network stack, and multiple sensors should budget 256 KB of flash and 64 KB of RAM, where all three options remain open.

Power Consumption and Sleep Behavior

Power behavior depends on how often the firmware wakes the processor. Bare metal programming gives the finest-grained control over power states. The developer decides exactly when to sleep, which event wakes the chip, and how long each state lasts. No scheduler tick interrupts the quiet periods. For a coin-cell sensor that wakes every 30 seconds, measures, transmits, and sleeps, this direct control yields the lowest possible average current.

An rtos adds a periodic tick, typically every 1 ms with default FreeRTOS settings. Each tick wakes the core, services the scheduler, and returns to sleep. The overhead is tiny per event, yet it accumulates over a battery's lifetime. Simma Software summarizes the contrast:

Modern kernels solve most of this problem. Tickless idle suppresses the tick when no task is ready, and the processor stays in deep sleep until the next scheduled deadline. Simma Software flags the missing configuration as a common error:

Mistake 5: Ignoring tickless idle on battery-powered RTOS devices The default 1ms tick interrupt prevents deep sleep. Enable tickless idle (configUSE_TICKLESS_IDLE = 1 in FreeRTOS) or Zephyr's power management subsystem to achieve real low-power performance.

With tickless idle enabled, an rtos converges on bare-metal power figures for most real-world duty cycles. The gap widens only for single-function devices with very long sleep windows. Multi-task products usually gain more from the scheduler than they lose at the power rail.

Neither column wins every row. The rtos pays for structure with cycles, bytes, and microamps, and bare-metal code pays for efficiency with developer effort as the feature list grows.

Boot Time and Responsiveness

Boot time measures how quickly a device becomes ready to do useful work after power-on or reset. Responsiveness measures how fast the firmware reacts to an event once running. Both metrics shape the user experience and the system's fitness for its task. A bare-metal design and an rtos design approach these two metrics from opposite directions.

A bare-metal firmware image starts executing at the reset vector and moves straight into the application. The startup code initializes the clock tree, copies initialized data to RAM, zeroes the BSS section, and jumps to main(). No kernel sits between reset and the first line of application logic. A small bare-metal program can reach its main loop in a few milliseconds, and a highly optimized image can do it in under a millisecond. This short path gives bare-metal firmware a clear edge in products that must act fast after power returns. Automotive body modules, remote keyless entry fobs, and safety cutoffs all benefit from this instant-on behavior.

An rtos adds kernel initialization to the boot path. The kernel creates its internal structures, sets up the scheduler, configures the system tick, and starts the first task. Each step costs time. A trimmed FreeRTOS build might add a few milliseconds to boot, while a full Zephyr image with device drivers and a network stack can take hundreds of milliseconds or more. The exact figure depends on the kernel configuration and the number of drivers that run at startup. Teams that need fast boot from an rtos can defer non-critical initialization to a low-priority task and start the critical task first. This trick recovers much of the gap, yet the kernel overhead never disappears entirely.

Responsiveness during runtime tells a more nuanced story. A bare-metal main loop polls inputs in a fixed order. The firmware reacts to an event only when the loop reaches the code that checks for it. A long loop with many features delays the response to any single input. Developers can move urgent work into interrupt service routines to shorten the reaction time. This approach works well for a handful of events. It becomes fragile when the event count grows, because each new interrupt handler competes for the same processor cycles.

An rtos restructures responsiveness around priorities. A high-priority task preempts lower-priority work the moment its trigger fires. The scheduler guarantees that the critical task runs within a bounded time, regardless of what else the system is doing. This priority model keeps response times stable as features accumulate. A device that must service a radio packet, a sensor sample, and a user button at the same time benefits from this structure. The kernel enforces the order, and the developer does not need to hand-tune the main loop for every new feature.

Interrupt latency deserves separate attention. Bare-metal code often wins here, because an interrupt service routine runs directly on the hardware stack with no scheduler in the path. The processor vectors to the handler and executes it immediately. An rtos adds a small layer of kernel bookkeeping around interrupt entry and exit, and the scheduler may run after the handler returns. On modern Cortex-M parts, this added delay is typically a few microseconds. The difference matters only for the tightest timing requirements, such as motor control loops or high-speed communication protocols. For most IoT sensing and connectivity workloads, both architectures deliver adequate interrupt latency.

A comparison table captures the practical differences:

The boot time advantage of bare-metal programming is real and measurable. The responsiveness advantage of an rtos is equally real, and it grows with system complexity. A team that ships a single-function device should weigh boot time heavily. A team that builds a multi-function product should weigh response stability heavily. Neither metric decides the architecture alone, yet both belong in the evaluation.

Application Fit for IoT PCBA Firmware Design

When Bare-Metal Wins

Bare-metal programming fits products with a small, fixed feature set. A temperature logger, a smart lock, or a single-sensor beacon rarely needs a scheduler. These devices run one job, and a bare-metal architecture keeps the code short and the bill of materials lean. Hard real-time loops in motor drivers and safety cutoffs also favor bare metal, because the developer controls every cycle. Teams with tight flash budgets and strict power targets often find that bare-metal programming delivers the lowest cost per unit. The architecture also suits products that will never ship a firmware update, where simplicity outweighs long-term flexibility.

When an RTOS Is the Right Call

A real-time operating system earns its place when several activities compete for one processor. Connectivity stacks, sensor fusion, and user interfaces all demand attention at once. An rtos assigns priorities, so time-critical tasks meet their deadlines while background work waits. Products with real-time requirements across multiple functions benefit from this structure. Deterministic behavior becomes easier to prove when the kernel enforces the schedule. Devices that must pass certification for real-time constraints, such as medical monitors or industrial controllers, often rely on an rtos for documented timing guarantees. The firmware architecture also stays readable as the team grows.

Scalability and Long-Term Maintenance

Scalability separates the two paths over a product's life. Beningo describes how a team can add an rtos to bare-metal code in 45 minutes, and the effort differs by kernel:

Beningo notes that Zephyr is a complete embedded software platform. It bundles a hardware abstraction layer, driver framework, networking stack, and security services. Those capabilities add value, yet they also raise setup effort and learning curves.

Long-term maintenance exposes deeper risks. A Vitalii Shvetsov post on LinkedIn describes the scalability wall: adding a sensor on a rigid, simple rtos becomes a rewrite, not a patch. The same post warns of a supply chain trap, where a chip shortage forces a firmware rebuild on a proprietary rtos. Security debt compounds the problem as new regulations arrive. Teams also face other traps:

• The innovation trap: engineers fear touching legacy code, because one change could brick the device.
• The compliance wall: undocumented, unpatchable code becomes a legal liability under tightening IoT mandates.
• The talent bottleneck: top embedded engineers avoid debugging undocumented bare-metal C code with no rtos.

These pressures shape the choice for iot pcba firmware design teams. A bare metal start works for a prototype, yet growth often pushes the product toward a kernel. Careful iot pcba firmware design planning now saves rework later.

Regulatory Compliance and Certification

Compliance work now shapes firmware architecture choices. The EU Cyber Resilience Act (CRA) sets binding rules for any connected product sold in Europe. Finitestate reports that the CRA, formally Regulation (EU) 2024/2847, requires security by design, security updates across a declared support period, and documented compliance evidence. Both bare-metal and rtos designs can meet these rules. The effort differs by architecture.

Certification Considerations for Bare-Metal Designs

A bare-metal design keeps the certification surface small. The firmware has fewer components, so auditors review a shorter code path. Teams can document every function and every state transition with modest effort. Bare-metal programming also simplifies the security by design argument, because the developer controls all code that runs on the device. The trade-off appears in update support. A bare-metal product needs a hand-built update path, and that path must satisfy the CRA's lifecycle requirements. Teams should plan the bootloader and signature checks early.

Certification Considerations for RTOS-Based Designs

An rtos brings reusable compliance assets. Zephyr and FreeRTOS ship with documented security services, and vendors maintain vulnerability records for the kernel. Auditors accept these records as evidence. The rtos also supplies a structured update mechanism, which eases the CRA's support-period obligations. The kernel adds scope, however. Each module and driver enters the assessment, and teams must track kernel versions across the product life. A real-time operating system with a strong vendor support program reduces long-term compliance risk.

Security and Update Requirements in 2026

The CRA timeline now drives firmware roadmaps. OneKey outlines the phases:

1. The Cyber Resilience Act came into force on December 10, 2024.
2. From June 11, 2026, the first conformity assessment bodies begin checking product conformity.
3. From September 11, 2026, manufacturers must report exploited vulnerabilities through ENISA's Single Reporting Platform, with an early warning inside 24 hours and a detailed notification inside 72 hours.
4. Full compliance applies from December 11, 2027.

Telit notes that the CRA also demands a software bill of materials (SBOM) with exact version numbers. Both bare metal and rtos projects must produce this inventory. An rtos eases the task, because the kernel and its modules carry version metadata. A bare-metal build requires manual tracking of every library. Teams on either path should enable secure boot and signed updates before the 2026 reporting deadline.

Cost Analysis

Development Cost and Time to Market

Firmware development often becomes the largest single line item in an IoT budget. Rapid Circuitry publishes typical ranges for common firmware work:

A bare-metal programming start usually reaches the market faster on a simple product. An rtos adds setup time, yet it shortens later feature work. Crunch-IS notes that bare metal carries the highest cost of adding concurrency later. Teams that expect several concurrent jobs should weigh that future cost against the lower initial quote.

BOM Cost and Hardware Selection

The firmware choice constrains the microcontroller, and the microcontroller drives the BOM. A bare-metal design can run on a part with 32 KB of flash and 8 KB of RAM. An rtos needs more headroom, so the hardware selection shifts to a larger part with a higher unit price. Aggressive battery targets add another line. Rapid Circuitry reports that low-power firmware architecture, microamp sleep currents, and power profiling routinely add $5,000–$20,000 of engineering. Teams should budget this work early, because it is the most commonly underestimated item.

Total Cost of Ownership

Total cost of ownership extends far past the development invoice. Metadesk Global advises teams to budget the operating cost per device per year, covering connectivity, cloud, support, replacements, and engineering time. The biggest hidden cost after launch is ongoing engineering time for security patching and firmware maintenance across fragmented fleets. Post-launch costs usually exceed the original development spend.

Battery life feeds directly into that figure. Qoitech describes a fleet of 10,000 tracking devices with a five-year target. Real batteries deplete at different rates, so each unit might need two replacements over five years, at a potential cost of $6 million. A well-configured rtos with tickless idle protects that investment. A lean bare-metal design protects it too, provided the team invests in power profiling. Either path works when the team plans for the full lifecycle.

Decision Framework for RTOS vs Bare-Metal Programming

A structured framework turns the rtos vs bare-metal programming debate into a repeatable engineering decision. Teams that follow a clear process avoid two common failures: over-engineering a simple device with a kernel it does not need, and under-engineering a complex product that later demands a painful rewrite. The framework below rests on two parts. The first part lists the questions a team must answer before it commits to an architecture. The second part condenses those answers into a selection matrix that maps project traits to a recommended path.

Key Questions to Ask Before Choosing

The first question concerns the application itself. Does the device run one job, or does it juggle several activities at once? ACL Digital frames this distinction as the dividing line between the two architectures. Single-task applications with minimal logic fit bare-metal code, while multitasking or time-critical applications with concurrent task requirements call for an rtos. A team that cannot name more than one concurrent activity should treat that answer as a strong signal toward bare metal.

The second question covers timing. Does the product carry hard real-time requirements, and how tight are the deadlines? A motor control loop that must close within microseconds behaves differently from a sensor that reports every minute. ACL Digital notes that bare-metal systems deliver deterministic timing with minimal latency for critical control loops. An rtos supplies built-in schedulers and timers that ensure predictable execution in real-time environments. The team must state each deadline in numbers, not adjectives. Jacob Beningo makes this point in a LinkedIn post about firmware planning:

I think it's key to be asking the right questions about the problem and it's constraints and deliverables not only on overall project goals but in regards to hardware / firmware / software timing budgets.

For example, explaining why certain data has to be refreshed or "come in" as a certain time, will improve the requirements doc/spec (if you have one!!) and will help you better decide on the tools to use to accomplish that goal.

The third question addresses resources. How much flash and RAM can the hardware budget spare? ACL Digital reports that bare-metal implementations have a minimal code and memory footprint since there is no kernel or scheduler overhead. An rtos consumes more ROM for system services and more RAM for task stacks, IPC structures, and control blocks. Developers must profile memory allocation carefully for scalability. A part with 32 KB of flash and 8 KB of RAM leaves little room for a kernel. A Cortex-M4 with 256 KB of flash and 64 KB of RAM keeps every option open.

The fourth question covers power. What is the average current target, and how long must the battery last? ACL Digital observes that power usage in bare-metal systems is more predictable and easier to optimize through direct control of peripherals and sleep states. An rtos-based design offers advanced power management APIs, yet it requires careful configuration of idle tasks, tickless scheduling, and peripheral clock gating to match the deterministic behavior of a bare-metal setup. A coin-cell product with a ten-year target should weigh this answer heavily.

The fifth question concerns connectivity and complexity. Does the product need BLE, Wi-Fi, or a TCP/IP stack? Will it add a GUI, a file system, or over-the-air updates? ACL Digital places simple or absent communication stacks in the bare-metal column and asynchronous, time-bound stack interactions in the rtos column. The same source lists the triggers that justify a migration: concurrent task execution, asynchronous event handling, communication stack integration, user interfaces, real-time data logging, and OTA updates. A team that sees two or more of these triggers on the roadmap should plan for a kernel from the start.

The sixth question covers the team and the schedule. How many engineers will touch the code, and how long will the product stay in the field? A single developer shipping a fixed-function device can hold a bare metal programming model in their head. A team of five maintaining a product for a decade needs the separation of concerns that a kernel enforces. Beningo describes the value in the same post:

I'd probably describe RTOSes as something different:

They help managing separation of concerns via proven tools that manage concurrency in a deterministic manner.

Separation of concerns helps to shrink the state space of the problem to manageable size.

These six questions form a checklist. A team that answers all six in writing produces the requirements document that firmware architecture selection demands. The answers also feed directly into the matrix below.

A Simple Selection Matrix

The matrix translates the six questions into a side-by-side comparison. ACL Digital publishes a use-case table that maps common project traits to each architecture, and it serves as a practical starting point for the decision.

A team can score its project against each row. A project that lands on the bare-metal side of five or six rows has a clear answer. A project that splits three and three deserves a closer look at the growth path. The matrix also exposes the rows where the two architectures converge. ACL Digital notes that modern rtos implementations with fine-grained preemption and tickless modes can still meet tight real-time requirements when engineers tune them correctly. The bare-metal advantage in latency and jitter therefore shrinks as kernel quality improves.

The matrix works best as a conversation tool. Engineers, product managers, and hardware designers should each score the project independently, then compare results. Disagreements reveal hidden assumptions about timing, cost, or feature scope. A hardware lead who scores power as tight and a product manager who scores connectivity as essential will surface a real conflict early. That conflict belongs in the requirements document, not in a code review six months later.

The final step converts the scores into a decision record. The record should state the chosen firmware architecture, the reasons behind it, and the conditions that would trigger a revisit. A team that selects bare-metal programming for a sensor node should note the feature that would force a migration, such as a Wi-Fi stack or an OTA update path. A team that selects an rtos should note the memory ceiling that would force a trim. This record gives future engineers the context they need, and it turns the rtos vs bare-metal programming choice into a documented engineering decision rather than a matter of preference. Careful iot pcba firmware design always includes this record, because the architecture outlives the people who chose it.

Common Pitfalls to Avoid

Both architectures carry failure modes. Teams that know them in advance avoid costly debugging cycles late in a project, whether the design uses bare-metal code or an rtos.

Pitfalls in Bare-Metal Projects

Bare-metal code hides its risks in timing and shared state. A bare-metal design leaves no kernel to catch these errors. Bare metal code gives developers full control, and that control cuts both ways. BugProve catalogs the most common bug types in IoT firmware:

Race conditions rank among the hardest bugs to diagnose. A race condition occurs when multiple tasks or interrupt handlers modify the same hardware register, and the outcome depends on precise timing. These faults appear only under specific conditions, so they resist reproduction in a lab. Bare metal programming also tempts developers to grow one large main loop. Maintainability suffers as features pile up. Bare-metal programming rewards careful planning from day one. BugProve still defends the model where it fits:

Bare metal approaches, conversely, offer maximum efficiency for simple, single-purpose devices where every microsecond and microamp counts.

Pitfalls in RTOS Projects

An rtos introduces concurrency hazards of its own. Priority inversion tops the list. Percepio notes that this exact failure struck NASA's Mars Pathfinder mission. A high-priority task waits on a mutex held by a low-priority task, and a medium-priority task preempts the holder. The high-priority task stalls far longer than expected. Sagar Kanjariya walks through the sequence:

1. Task L locks the UART mutex.
2. Task H wakes and tries to lock UART, but Task L holds it.
3. Task M keeps running because it outranks Task L.
4. Task L never gets CPU time to release the mutex.
5. Task H remains stuck.

Priority inheritance solves the problem. The kernel temporarily raises Task L's priority, so it finishes and releases the mutex. Shared resources create a second trap. Inexperienced developers guard a peripheral with a global flag, and a task switch at the wrong moment breaks the lock. Every rtos ships primitives for this job. Percepio recommends the kernel's own services, such as mutexes and queues, over home-cooked solutions. An rtos also demands more design discipline than bare-metal code. Teams must size task stacks, assign priorities, and document every shared resource. A well-configured rtos repays that care with structure. Bare-metal programming avoids these hazards, yet the kernel repays the added care with structure.

---

The correct choice aligns firmware architecture with project needs and constraints. Bare-metal favors simplicity and a minimal footprint; an RTOS favors complexity, concurrency, and maintainability. Teams should revisit the rtos vs. bare metal decision as requirements grow, because migration paths exist in both directions. Careful iot pcba firmware design treats rtos vs bare-metal programming as a living decision. A bare metal start can adopt an rtos later, and an rtos project can trim back to bare-metal code when scope shrinks.

FAQ

Can a team migrate from bare-metal firmware to an rtos later?

Yes. Teams can add a kernel to existing bare-metal code, and vendors document the steps. A structured migration keeps the application logic intact while the rtos takes over scheduling.

Does an rtos always cost more than bare metal firmware?

Not always. A simple product pays more for kernel setup and extra memory. A complex product often saves money, because an rtos reduces rework as features grow.

Which architecture suits battery-powered IoT devices better?

Both work. Bare metal gives the finest sleep control for single-function sensors. An rtos with tickless idle matches that performance for multi-task devices.

How does firmware architecture affect CRA compliance?

Both paths can comply. An rtos ships documented security services and version metadata, which eases audits. Bare-metal designs need manual tracking of every library and update path.