When should you choose Zephyr for an embedded product?

Product teams have to choose early between bare-metal, an RTOS and embedded Linux. Zephyr is a strong option once your firmware grows from a simple control loop into a connected software platform. At the same time, not every microcontroller project needs an RTOS. For simple, deterministic tasks, bare-metal is often smaller, more transparent and easier to maintain. Below we explain how we weigh that decision.

From firmware to software platform

Many microcontroller projects start out simple. You read a few inputs, update a state machine, drive some outputs and start over. For that kind of application a classic bare-metal architecture often works very well. That changes quickly once the product gains Bluetooth, Wi-Fi, LTE-M, Ethernet, TLS, MQTT, local storage, firmware updates, power management or several tasks running at once.

At that point you are no longer really writing firmware around a control loop. You are building a small software platform, and that is where Zephyr starts to get interesting.

Zephyr is more than a scheduler. It combines a real-time kernel with drivers, networking, Bluetooth, storage, logging, power management, cryptography, configuration, hardware description and integrations for secure boot and firmware updates.

What Zephyr brings

• Pre-emptive and cooperative scheduling, threads, timers and synchronization primitives.
• A broad driver model for GPIO, I²C, SPI, UART, CAN, sensors, flash and other peripherals.
• Networking stacks and protocols, including IPv4/IPv6, TCP/UDP, MQTT and Bluetooth.
• Kconfig for compile-time configuration and DeviceTree for hardware description.
• CMake and west for builds, dependencies and multi-repository workflows.
• Infrastructure for logging, a shell, settings, storage and power management.
• Integration with MCUboot and ecosystems for signed firmware and firmware updates.

DeviceTree and Kconfig keep hardware and software apart

Where Zephyr differs from many classic firmware projects is that it explicitly structures the hardware description and the software configuration. DeviceTree describes which hardware is present and how it is connected. Kconfig determines which software components and features end up in the build.

This pays off especially for product families. Products A, B and C can each have their own board definition and DeviceTree overlay, while a large part of the application logic stays the same. That makes managing variants and reusing code a lot easier.

When Zephyr really becomes interesting

Zephyr pays off most when different kinds of complexity come together in one product:

• Several activities run at the same time, such as communication, sensors, control loops, logging and background tasks.
• The device is connected over BLE, Wi-Fi, Ethernet or cellular.
• You need TLS, certificates, MQTT or other protocols that you would rather not integrate as separate libraries.
• The same firmware has to run on several hardware variants or boards.
• The product needs remote updates, secure boot and lifecycle management.
• It is a low-power product in which you have to coordinate several subsystems and wake-up sources.

The vendor ecosystem makes the difference

Zephyr’s value does not lie in the upstream project alone. Chip manufacturers increasingly build extensive SDKs around it. Nordic Semiconductor is a good example with the nRF Connect SDK. For a cellular product based on an nRF9151, for instance, that gives you one coherent platform for the modem, LTE-M/NB-IoT, GNSS, TLS, MQTT, power management and firmware updates.

Whether an MCU supports Zephyr is therefore only the starting point. At least as important is how mature the drivers, examples, vendor libraries, debugging tools, release processes and long-term support are for exactly the peripherals your product needs.

Sometimes bare-metal is simply better

An RTOS is not a goal in itself. Every abstraction layer brings its own concepts, configuration and dependencies. If the application is small and easy to oversee, that extra infrastructure can cost you more than it gives back.

Our X Series displays, for example, contain a simple AVR32DD32 microcontroller for supporting tasks around the main computer. The firmware switches the power rails on in the right order, monitors the ignition, handles the status indication and talks to the main processor in a simple way, among other things for the shutdown sequence. It is a compact, deterministic state machine with little concurrency and no complex networking. Zephyr would add little in functional terms there. Bare-metal is smaller and more direct in this case, and you can understand the code completely.

That is why we choose the smallest software architecture that covers the requirements in a robust and maintainable way. For that power controller, it comes down to this:

• A few GPIOs, timers, UART/I²C and a straightforward state machine.
• No BLE, IP networking, TLS or complex protocol stack.
• No dozens of independent tasks.
• Strict control over boot behavior and timing is something you simply handle directly.
• A small codebase keeps review, debugging and long-term maintenance manageable.

Zephyr or FreeRTOS

FreeRTOS and Zephyr overlap, but historically they come from different places. At its core, FreeRTOS is a compact and very widely used RTOS kernel that you usually complement with a vendor SDK and separate libraries. Zephyr positions itself more as an integrated embedded platform.

Aspect	Zephyr	FreeRTOS
RTOS kernel	Yes	Yes
Hardware description	DeviceTree, integrated	Usually vendor or project specific
Configuration	Kconfig	Project or vendor specific
Drivers and subsystems	Broad integrated platform	Often through a vendor SDK or libraries
Networking and BLE	Tightly integrated	Depends on the chosen stack or SDK
Build workflow	CMake and west	Heavily ecosystem dependent
Typical strength	Complex or connected MCU products	Compact RTOS base, broad vendor adoption

There is no universal winner. For some products a compact FreeRTOS setup is perfectly adequate. For others, the broader Zephyr platform saves a lot of integration work.

Zephyr or embedded Linux

Zephyr does not replace embedded Linux, because they solve different problems. On a Cortex-M microcontroller, Zephyr runs close to the hardware, with low latency, limited memory and a fast boot. Linux belongs on powerful application processors with a rich HMI, multimedia, containers, large applications and a complex userspace. Which Linux distribution to pick in that case is covered in Yocto vs Ubuntu vs Debian.

	Zephyr	Embedded Linux
Typical CPU	Cortex-M, MCU	Cortex-A, MPU
Memory	KB to a few MB	Hundreds of MB to GB
Boot	Milliseconds, very fast	Typically a few seconds
Real-time control	Strong	Different architecture, RT options available
Rich HMI	Limited	Strong, with Qt, web and others
Containers and process isolation	Not the goal	Strong

Quite often the answer is actually both. An industrial product can easily use a Linux application processor for the HMI, cloud connectivity and data processing, alongside an MCU running Zephyr for real-time I/O, sensors, motor control or supporting safety-related functions.

Security, secure boot and firmware updates

You have to be able to maintain connected firmware for as long as the product is in use. Zephyr fits well in an architecture where firmware signing, secure boot, versioning and remote updates are part of the design from the start.

Zephyr ecosystems often use MCUboot as the secure bootloader. Depending on the MCU, the flash architecture and the product requirements, you can work with signed images, different rollback strategies and different update flows. How secure the result is always depends on the chosen MCU, key storage, the boot chain and the update architecture. Using Zephyr does not by itself make a product secure.

Once a device is connected, updatability, vulnerabilities, SBOM and CVE tracking and a controlled release process belong to the entire product lifecycle, and not just to the initial firmware development.

How we handle this for Linux images is described in SBOM and CVE monitoring with Yocto.

The downside: complexity and a learning curve

Zephyr also comes at a price, and you should know it up front:

• DeviceTree, Kconfig, CMake and west together form a powerful but far from trivial toolchain.
• Because of the abstraction layers, debugging is less direct than in a small bare-metal codebase.
• The footprint is hard to justify for every very small MCU or minimal application.
• Vendor forks and SDK versions need to be managed deliberately.
• Not every peripheral or driver is equally mature on every SoC.
• In a good architecture, you limit vendor-specific APIs to the places where the standard Zephyr interfaces fall short.

Upstream Zephyr or a vendor SDK?

In practice you often do not work directly on upstream Zephyr. A vendor includes Zephyr in its own SDK, together with proprietary or vendor-specific libraries, tooling and releases. For hardware enablement and support that is often a big advantage, but it also means you take on a dependency on that vendor.

We use the standard Zephyr APIs where that makes sense, keep vendor-specific functionality deliberately separate, and agree up front how we will manage updates to the SDK and to Zephyr itself for as long as the product is in use.

A practical decision guide

Product type	Logical starting point
Simple power controller or supervisor	Bare-metal
Small machine I/O controller	Bare-metal or an RTOS, depending on concurrency
BLE sensor	Zephyr is often strong
LTE-M or NB-IoT device	Zephyr, or a vendor SDK based on Zephyr, is often strong
Battery-powered connected IoT device	Zephyr is often interesting
Complex graphical HMI	Embedded Linux
Industrial panel PC	Embedded Linux with Yocto
HMI with a real-time peripheral controller	Linux plus an MCU with Zephyr or bare-metal

Choose the platform based on the product

Which framework is most popular says little about what suits your device. Look first at timing, connectivity, power consumption, security, updatability, hardware variants, product lifetime and how complex the software is likely to become.

At Invisto we work across the full embedded stack, from small microcontroller firmware and connected devices on Zephyr to custom Yocto Linux platforms and HMI applications. That lets us derive the software architecture from the product, instead of pushing every product onto the same platform. How this ties in with the choice of hardware is covered in SOM vs custom PCB and, for HMI licensing, in Qt licensing for embedded devices.