Bare Metal Deja Vu or Embedded Renaissance?

Developing a bare metal application may sound like a forgotten art but it is not. Bare metal is well and alive, and even becoming more widely adopted. Last week, Nordic Semiconductor launched nRF Connect SDK Bare Metal option for the nRF54L Series. This shows a positive shift in the industry, but what is bare metal?

Bare metal firmware runs in a main program loop and all events are interrupt driven. The code is in total control and our system is deterministic. This usually makes the application flow easier to debug. The use of connectivity like Wi-Fi and TCP/IP can be difficult but there are commercial third party libraries that provide such features in a form ready for bare metal integration.

RTOS runs using a scheduler and interrupt handlers call the scheduler at the end of the interrupt. The scheduler makes the decision which task gets to be executed next, when to block an existing task and start another, etc. RTOS-based firmware can become hard to debug and trace. The use of Wi-Fi and BLE is easier with RTOS because MCU vendors tend to provide a complete RTOS-integrated network stack.

Mass produced products with over 1,000,000 units per year usually have bare metal firmware as part of the product. It can be a finite state machine (FSM) running on a component or the main application firmware. For example, medical devices often run as bare metal FSM. Some modern medical devices gained lots of connectivity and switched to Linux, but others still have highly integrated embedded systems. For example, some hearing aids with BLE run on bare metal firmware. The same applies to the smart home and wearables.

We do not hear about the success stories of bare metal development because there are few incentives to report the technical success — the product works, mass produced, end of story. In comparison, both FreeRTOS and Zephyr are open source projects that benefit from public success stories that prove the usefulness of the public RTOS code base. This is normal but it creates a survivorship bias. The visible part of the industry creates a sort of “iceberg” image that nowadays everyone is using Zephyr and FreeRTOS when this is not the case.

For example, there are plenty of graphics libraries for bare metal development:

• “QT for MCUs” can be used bare metal on NXP, Infineon, Renesas, and STMicroelectronics.
• “ARM-2D” can be used bare metal on any Arm Cortex-M system.
• “LVGL” can be used bare metal on almost any embedded system (Arm, RISCV, etc.)

The reason so many graphics libraries intentionally support bare metal applications is that many products and companies still use bare metal. The move by Nordic Semiconductor to release a bare metal variant of its nRFConnect SDK further proves this, even if only for the nRF54L for now. Bare metal is more deterministic than RTOS, thus helping achieve efficiency and performance.

How did we get here?

Modern products often include connectivity and vendor drivers for connectivity started to depend on real-time operating systems. For example, using Bluetooth or Wi-Fi on Infineon PSOC 6 requires FreeRTOS or Zephyr (which is also an RTOS). The Wi-Fi driver sets up its own task to manage the network events and network stack.

It can get even more complicated depending on the connectivity type, with multiple tasks: one to manage the physical communication layer and a separate task to manage the application layer. Sometimes, a third task can manage in real-time the power and performance of the interface (network, radio, etc.)

Eventually, Wi-Fi and BLE drivers requiring FreeRTOS became the norm. Bare metal development continued but we were seeing a new pattern. Multi-core systems that run bare metal firmware on one core and FreeRTOS on the other to enable connectivity.

Then, Zephyr came and it took a while for vendors to port to the new RTOS, but the situation remained pretty similar. Very large customers and customers with special requirements kept using bare metal development.

What is the difference between bare metal and RTOS?

Back in the day, it would definitely be a case of latency, power consumption and memory footprint. Today, we have a technical comparison by Nordic that shows similar numbers in performance and power consumption for Zephyr and bare metal applications with the new SDK. Others report two times the memory footprint difference in favor of the new bare metal nRFConnect SDK and this gap will only increase as features are added in.

In summary: Bare metal can still definitely help with optimizing memory footprint, and depending on your application it may help with latency and power consumption because bare metal is more deterministic than RTOS.

Cost is a big factor, too. Cost that comes from the development time, development effort, and maintenance. Without going into extreme examples like a team of skilled developers who do not use RTOS and will take a longer time to develop with RTOS, the total cost of ownership is a real factor.

Maintenance can be split into two categories: maintaining own code and maintaining third-party code (e.g. vendor SDK, Zephyr). Taking care of only internal code has the benefit of not dealing with issues brought from external code, but also limits the available external resources who can help with the problem. This is also one reason why we see bare metal adoption in either very large volume projects or very small projects.

How does the embedded future look?

According to the technical deep dive by Nordic linked above, Zephyr is comparable at power consumption with bare metal, but a bare metal nRFConnect SDK was still needed. This means many things, including many customers with large volumes need it. Monolith firmware design is alive and well. It is not good for every product, but proprietary software and firmware that drive commercial IoT and edge products is highly monolithic.

Developing edge AI products with connectivity will probably require both bare metal and RTOS. Remember, edge AI microcontrollers have many computing cores for different purposes. Internet connectivity will likely continue to require RTOS because the network drivers will require RTOS. In the other part of the firmware, the machine learning model running on-device may live in a bare metal firmware on a dedicated core. Or there could be a bare metal firmware for a critical set of interrupts from the external world.

High-performance digital signal processing (DSP) applications use bare metal to this day. With the mass availability of Cortex-M85, Cortex-M55 and the NPU Cortex-U55, we may use DMA-enabled bare metal firmware that performs a strict set of operations for maximum bandwidth and minimum latency. Any time spent preparing the data is a fixed delay for our ML inference. By leveraging bare metal for data collection, pre-processing and post-processing, we may see big gains in ML performance. Of course, all depends on your application requirements.

What about security?

Before, secure firmware ran as bare metal and today Trusted Execution Environments (TEE) usually run integrated with an RTOS. For example, the reference implementation of TrustZone-M (TF-M) supports both a bare metal design and RTOS design using mutex.

Five years ago, I would say run TF-M as bare metal. But today if you are having connectivity it is likely there is RTOS in your main application firmware because of the vendor drivers, so we better use an RTOS-enabled TF-M to make the integration between the secure and non-secure world easier.

We will definitely see more adoption of memory isolation technologies like TrustZone because minimizing the attack surface is more important than ever with edge AI systems, intelligent IoT sensors, and connected industrial IoT systems.

Security at the edge does not become easier, it becomes more challenging. This is why the mission of Thistle is to create a platform that reduces the security work required for every development environment and embedded design, Linux, RTOS and bare metal.