How to Choose Between FreeRTOS Zephyr and Bare Metal

Most embedded teams spend less time choosing their RTOS than they spend choosing their lunch. Then they live with the consequences for five to ten years. The irony is that this decision shapes almost everything downstream: your hardware abstraction layer, your debugging workflow, which engineers you can hire, and how painful your next chip shortage will be. Yet the typical approach is “our MCU vendor bundles FreeRTOS, so I guess we’re using FreeRTOS.” Or worse: “Zephyr looks cool on Hacker News, let’s try it.”

Neither is a strategy. And the comparison tables floating around (kernel size, tick resolution, number of supported boards) don’t actually help you decide. They tell you what each option is. They don’t tell you which one fits your project.

This article gives you a practical framework for choosing between FreeRTOS, Zephyr, and bare metal. Not a feature dump. A decision process, built around the constraints that actually matter: hardware resources, connectivity needs, team size, product lifespan, and vendor lock-in.

When Bare Metal Is the Right Call

Let’s start by being clear: bare metal is not a consolation prize. It’s a deliberate architectural choice, and for many products, it’s the optimal one.

“Bare metal” in practice means a super-loop architecture, possibly with interrupt-driven state machines, and no scheduler. You control the execution flow entirely. There’s no task switching, no tick interrupt, no kernel footprint.

This approach wins in specific scenarios:

• Ultra-constrained MCUs. 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.
• Hard real-time, single-function devices. A sensor node that samples an ADC at a precise interval, applies a filter, and transmits a result. If the timing requirements are tight and the functional scope is narrow, a super-loop gives you deterministic behavior that’s trivial to verify.
• Safety-critical systems requiring certification. Bare metal is easier to certify in many safety contexts (IEC 61508, DO-178C) because there’s less code to analyze and no scheduler behavior to characterize.

The advantages are real: zero overhead, full control over every cycle and byte, no dependency risk, and a codebase that a single engineer can hold in their head.

The limitation is equally real: complexity scales poorly. When you’re juggling six or more asynchronous concerns (UART parsing, sensor sampling, BLE events, timers, button debouncing, LED state) your super-loop starts to look like an ad-hoc, poorly tested RTOS. If you find yourself building priority schemes and cooperative yielding mechanisms by hand, you’ve already decided you need an RTOS. You’re just building a worse one.

The rule of thumb: if your problem is simple, keep your solution simple. Don’t reach for an RTOS out of habit. But recognize the inflection point when you’re past it.

FreeRTOS: The Established Default

FreeRTOS is the most widely deployed RTOS in the world. It’s MIT-licensed, maintained under AWS stewardship since Amazon’s 2017 acquisition, and its kernel is genuinely tiny, roughly 6–15 KB of flash and a few hundred bytes of RAM per task, depending on configuration.

The strongest case for FreeRTOS is practical, not technical: nearly every MCU vendor ships a FreeRTOS port. If you’re starting a project on an STM32, ESP32, Renesas RA, TI CC series, or NXP LPC, there’s already a working reference project with FreeRTOS integrated into the vendor’s SDK. That means you go from zero to multitasking fast, with examples tuned to your exact chip.

The ecosystem around FreeRTOS has grown substantially. coreMQTT, coreHTTP, FreeRTOS+TCP, and the AWS IoT libraries give you a path to cloud connectivity, particularly if you’re in the AWS ecosystem. The community is enormous, Stack Overflow has answers for nearly every common problem, and the learning curve from bare metal is gentle. Tasks, queues, semaphores, and timers are straightforward concepts for anyone comfortable with C and interrupts.

But there are honest limitations. FreeRTOS is a kernel, not a platform. It gives you a scheduler and synchronization primitives. Everything else, your HAL, your networking stack, your logging framework, your build system, comes from somewhere else, usually your MCU vendor. This means your project becomes coupled not to FreeRTOS itself, but to ST’s HAL, or NXP’s SDK, or Espressif’s IDF. FreeRTOS is portable in theory; your project often isn’t.

There’s also no standardized device model, no opinion about project structure, and no built-in subsystem for things like device power management or file systems. For teams without strong firmware architecture conventions, FreeRTOS codebases can diverge significantly. Two FreeRTOS projects at the same company can look nothing alike.

Zephyr: The Modern Contender

Zephyr is a Linux Foundation project with backing from Intel, Nordic, NXP, Texas Instruments, and others. It’s the fastest-growing RTOS by contributor count and commit velocity, with over 1,500 contributors supporting 700+ boards as of recent releases. If FreeRTOS is the established default, Zephyr is the direction the industry is moving.

The core differentiator is scope. Zephyr isn’t just a kernel; it’s a full embedded platform. Out of the box, you get:

• Networking stacks: Bluetooth LE (with a qualification-ready host stack), Thread, Wi-Fi, LTE, Matter
• Subsystems: USB, file systems, logging, shell, power management, device firmware update (DFU)
• Build infrastructure: Kconfig for feature selection, CMake-based builds, west as a meta-tool for managing repositories and flashing

The portability story is Zephyr’s strongest technical argument. Its device-tree model, borrowed from Linux, abstracts hardware descriptions from application code. In practice, this means you can write an application targeting Nordic’s nRF5340, then retarget it to an NXP RT1060 by changing a board definition and adjusting pin mappings, without rewriting your application logic. During the 2021–2023 chip shortages, teams on Zephyr had a measurably easier time switching silicon vendors. That’s not a hypothetical benefit. It’s a supply chain risk mitigation strategy.

The honest trade-offs: Zephyr’s learning curve is significantly steeper. Device tree syntax, Kconfig options, the west tool, overlay files, shield definitions. These are all new concepts for most embedded developers, and the documentation, while improving rapidly, can still be uneven for advanced use cases. The RAM and flash footprint is heavier than FreeRTOS. A minimal Zephyr application might need 64 KB of flash and 8–16 KB of RAM, compared to FreeRTOS’s ability to run on much less. And Zephyr’s API surface moves faster than FreeRTOS’s. Upgrading between major versions sometimes requires migration effort.

Zephyr asks more of you upfront. It pays dividends in long-lived, multi-platform, connectivity-heavy products.

The Decision Framework: Mapping Constraints to Choices

This is where the comparison tables end and actual engineering judgment begins. Work through these factors in order of relevance to your project.

Hardware constraints come first. If your target MCU has less than 64 KB of flash or less than 16 KB of RAM, Zephyr is likely off the table. It simply won’t fit in a meaningful configuration. FreeRTOS or bare metal are your options. If resources are extremely tight (under 32 KB flash, under 8 KB RAM), bare metal is almost certainly the right call. If you have 256 KB+ of flash and 64 KB+ of RAM, increasingly common even on Cortex-M4 parts, all three options are viable and you should move to the next factor.

Connectivity requirements are the next filter. If your product needs BLE, Thread, Wi-Fi, or Matter, Zephyr’s integrated, maintained stacks are a significant advantage. You get a single codebase, a single build system, and a single community for the kernel and the networking layer. FreeRTOS can do networking, but you’ll typically pull in your MCU vendor’s stack (Nordic’s SoftDevice, Espressif’s IDF Wi-Fi layer) or a third-party library. That works, but you’re integrating components from different projects with different release cadences, different bug trackers, and different levels of maintenance. If your device has no wireless connectivity (a wired sensor, a motor controller, a display module) this advantage evaporates, and FreeRTOS or bare metal becomes more attractive.

Number of hardware targets matters more than people think. If your product will run on one MCU family for its entire lifecycle, and you’re confident in that chip’s availability, FreeRTOS or bare metal is fine. You’ll write to the vendor’s HAL and that’s a reasonable coupling. But if you’re building a product line across multiple silicon vendors, or if your procurement team is telling you to have a backup chip qualified, or if you experienced the chip shortage panic of 2022, Zephyr’s device-tree abstraction genuinely reduces the cost of retargeting. This is one of the rare cases where an architectural choice directly affects supply chain resilience.

Team expertise and hiring pipeline are practical constraints. FreeRTOS has a lower barrier to entry. An embedded developer who’s been writing bare-metal C can be productive with FreeRTOS in a week. Zephyr’s ramp-up time is more like two to four weeks for a competent embedded engineer, longer if they’ve never encountered device trees or Kconfig. On the other hand, Zephyr attracts developers who value modern tooling, CI/CD integration, and Linux-style workflows. If you’re building a firmware team, consider what skill set you want to invest in long-term.

Long-term maintenance over a 3–5 year product lifecycle deserves serious weight. Zephyr publishes LTS releases with defined support windows and has an active governance model through the Linux Foundation. FreeRTOS benefits from AWS’s backing and has a strong track record of stability. Bare metal means you own everything: every bug fix, every security patch, every adaptation to a new compiler version. For a product that ships and never updates, that might be fine. For a product with OTA updates and security requirements, a maintained RTOS with a security response process is worth its weight in gold.

Vendor lock-in is the sleeper concern. FreeRTOS is vendor-neutral as a kernel, but your real dependency is on the MCU vendor’s BSP, which often isn’t portable at all. Zephyr explicitly aims to decouple your application from the silicon vendor. That’s the entire point of the device-tree model. Bare metal is maximally coupled to your specific hardware. None of these positions is inherently wrong, but you should make the choice deliberately.

Certification and safety requirements have specific implications. If you need IEC 61508 or DO-178C certification, investigate carefully. SafeRTOS, the commercial sibling of FreeRTOS, has pre-certified configurations. Zephyr has an active safety working group but its certification artifacts are less mature. Bare metal remains the simplest to certify due to reduced code volume and complexity.

What About ThreadX, RIOT, and NuttX?

FreeRTOS, Zephyr, and bare metal cover the vast majority of new project starts, but they’re not the only options. Eclipse ThreadX (formerly Azure RTOS) is worth evaluating if you’re in the Azure IoT ecosystem. It’s well-optimized and has a strong networking stack. Mbed OS is effectively end-of-life; don’t start new projects on it. RIOT and NuttX have loyal communities and specific strengths (RIOT for IoT research, NuttX for POSIX compatibility), but smaller ecosystems. For most commercial products, the three options in this article are your practical shortlist.

Build Your Evaluation Before You Commit

Don’t make this decision from a spec sheet. Prototype on your target hardware with your top candidate before committing. The evaluation criteria that matter most are often experiential:

• How long does it take to get a blinking LED and UART log output? If it’s over an hour, something is wrong with the tooling or documentation for your board.
• How does adding BLE or Wi-Fi feel? Is it a subsystem you enable, or a third-party integration project?
• How does debugging work? Can you inspect task states, stack usage, and queue contents?

For FreeRTOS, start with your MCU vendor’s reference project. It’ll be the fastest path to running code. For Zephyr, run west init, build a sample for your board, and spend time studying the device tree for your target. For bare metal, you already know what to do.

One final, critical point: switching cost increases exponentially after the first few months of development. Once your HAL is written, your drivers are integrated, and your team has built patterns around a specific RTOS, migration becomes a rewrite. Invest a week in evaluation now. It will save you months later.

The right choice is context-dependent. There’s no shame in bare metal, no risk in FreeRTOS’s proven maturity, and real upside in Zephyr’s trajectory if your project can absorb the learning curve. The embedded ecosystem is converging on more software-defined, portable approaches. Understanding this landscape is a career investment regardless of what you choose today.

Hubble Network enables direct Bluetooth-to-satellite connectivity for embedded devices — no extra radios, no gateway infrastructure. See how it works →