Most bare-metal to RTOS comparisons focus on technical decision factors and miss important business factors such as:
- Marketing keeps adding features.
- Powerful microcontrollers are dirt cheap.
- Security is becoming mandatory.
Bare Metal Examples
If a new product is very simple, it might seem that a minimal microcontroller (MCU) with bare- metal firmware is the best choice. Two examples of this are:
- Thermostat
- Garage door opener
A thermostat merely needs to periodically read a temperature sensor and decide if to turn the HVAC on or off. How complicated could that be? Well, my eco thermostat reports time and weather, allows various eco setting, and allows settings from home or away. It also connects to the Internet, which requires authentication. It allows remote control and presumably gathers data and provides over the air (OTA) updates. If its developers chose bare metal, I am sure they regret it now.
A garage door opener opens a garage door or closes it when someone presses a button. How complicated could that be? Well, my garage door opener also reports time and temperature and it responds to remote control. The latter requires a wireless connection and some form of authentication, which currently is a 4-digit code. But a 4-digit code is not hard to hack, so if there is a rash of garage break-ins, more sophisticated authentication may be required and probably OTA to keep up with the cyber thieves. So, complexity will grow.
Hence, a project that seems ideal for bare metal can end up in trouble. The usual results are:
- Spaghetti code
- Custom multi-tasking kernel
Neither is good. I like spaghetti, but not in my code! Those who write a custom kernel are reinventing the wheel at their employer’s expense. However satisfying that may seem, it is not the correct thing to do. There are many standard RTOSs that have solved the complexities of multitasking and are field-proven. Creating a custom kernel that works correctly is likely to be more difficult and cost more time than expected.
Feature Creep
Although we may think that feature creep is the result of marketeers with too little useful to do, there may be good reasons for it (i.e. let’s cut them some slack). In cases where battery life is crucial or there is no chance of feature creep and large quantities will be produced, picking a minimal MCU for which only bare metal firmware is possible can be the right decision.
But, that is not the case for most IoT devices. For them, starting with bare metal and adding features is likely to result in excessive development cost and a weak product. An RTOS-based design allows new features to be added without disrupting the existing design, provided that the MCU chosen has sufficient performance and memory.
Cost Tradeoffs
An example of an RTOS-capable MCU is a Cortex-M3 MCU with 64KB flash, 20KB SRAM, 72MHz clock, ADC, and timers. It costs about $3.50 in production volume, which adds about $3.00 to the bill of materials (BOM) vs. a minimal MCU. For a typical IoT device, with lifetime shipments of 100,000 units, this amounts to a $300K cost increase over the life of the product.
The average mid- to senior-level, embedded system engineer costs his company about $200K per year. A medium-size project requires 2 to 5 firmware programmers and lasts 6 to 12 months. So the employer’s firmware expense is $200K to $1M, with an average of $600K. And the maintenance cost for a product with high technical debt can substantially add to this cost over the life of the product.
The bottom line is that embedded and IoT project managers should consider engineering costs as well as BOM costs to make correct MCU selections. If there is a possibility that the intended market might require more features as time goes on, then the best choice is an RTOS, even if the application initially seems too simple for it.
Impact of Security
Security is the elephant in this room. We live in a modern-day world of increasingly frequent and severe security attacks. Even devices as simple as security cameras and routers are being breached routinely. This allows cyber criminals to access home and business networks and the secrets contained therein, such as passwords and cyber keys. So, to the above factors against bare metal must be added the potential for lawsuits and blocked market access because of non-compliance with security statutes. These can cost companies millions of dollars in settlements and lost revenues.
A case in point is the European Cyber Resiliency Act (CRA), which will take effect in December 2027. Work on essential cybersecurity requirements for operating systems [Ref 1] is currently in progress. Its current draft states the following:
Memory safety errors are a recurring source of exploitable vulnerabilities in operating systems written in memory unsafe languages. This clause groups mitigations that prevent the product from reading or writing memory outside the bounds of validly allocated regions …
The product shall implement mandatory hardware-enforced access control to memory, or an equivalent software enforced isolation mechanism documented by the manufacturer, to prevent unauthorized access of memory.
These, plus later requirements, require dividing firmware into isolated partitions for IoT devices that are connected to the Internet. This document also requires other security features such as stack overflow detection, MPU-based task isolation, etc. In addition the CRA applies a heavy burden on IoT device OEMs to report and fix exploited vulnerabilities quickly as they are found. Complying with this requirement is likely to be easier for well-designed RTOS-based firmware than for bare metal spaghetti code. Failure to comply with the CRA after Dec 2027 will result in draconian fines and banishment of the product from the European market.
Conclusion
A bare-metal or custom-RTOS decision should be carefully reviewed by all stakeholders in an organization, including security and legal people. In particular, an RTOS that supports isolated partitioning and other security features, like SecureSMX, should be considered. SecureSMX is available under a dual open source/commercial license. Full source code is available at www.github.com/Micro-Digital/SecureSMX.
References
1. “Cybersecurity (CYBER); Cyber Resilience Act (CRA); Essential cybersecurity requirements for operating systems” ETSI EN 304 626 V0.2.0 (2026-04).