FreeRTOS vs Zephyr: Choosing an RTOS for Your Device

Quickstart

If you need to decide this week, don’t start by reading feature lists. Start by running two prototypes on your target hardware: (1) one peripheral you care about (UART/I2C/SPI/ADC) and (2) one connectivity path (BLE/Wi-Fi/Ethernet). That small test surfaces 80% of the real differences: drivers, build friction, debugging, and how quickly you can iterate.

Overview

This post is a practical guide to choosing between FreeRTOS and Zephyr for embedded and IoT devices. Both can power reliable products. The difference is how much the OS provides out of the box versus what you assemble yourself. If you’re building a sensor node, a smart appliance, an industrial controller, or anything that needs networking and long-term support, the choice affects your team’s speed and your risk profile more than it affects raw scheduler performance.

Core concepts

Before comparing features, align on the concepts that actually drive RTOS success: scheduling behavior, interrupt design, configuration model, and how hardware support is expressed and maintained.

RTOS basics: threads, priorities, and determinism

Two different philosophies: “bring your own stack” vs “unified OS”

Tooling: what “developer experience” really means on embedded

Step-by-step

Here’s a decision process you can use for real projects. It’s written like a build checklist: define constraints, run two prototypes, and make the choice based on what will be easiest to ship, test, and update.

Step 1 — Write your constraints in plain language

Step 2 — Decide what you want “the OS” to own

This is the real FreeRTOS vs Zephyr question. Do you want a kernel and you own the stack, or do you want an OS platform where many choices are standardized?

Step 3 — Prototype Zephyr: build, flash, and log on your board

A Zephyr prototype should answer: “Can I build and flash reliably, and do I understand how to express my hardware and configuration?” If this feels smooth, Zephyr tends to scale well as your device grows.

# Zephyr: minimal workspace + build + flash (typical flow)
# Assumes you have the Zephyr SDK/toolchain set up for your host OS.

west init -m https://github.com/zephyrproject-rtos/zephyr.git zephyr-workspace
cd zephyr-workspace
west update
west zephyr-export

# Build a sample for a specific board (replace with your board target)
west build -b nrf52dk_nrf52832 zephyr/samples/basic/blinky

# Flash to device (runner depends on board; often "nrfjprog", "openocd", "pyocd", etc.)
west flash

# Optional: open a serial monitor to confirm logs/blinky behavior
# (Your port name varies: /dev/ttyACM0, COM3, etc.)
# screen /dev/ttyACM0 115200

Step 4 — Prototype FreeRTOS: validate your scheduling and communication patterns

A FreeRTOS prototype should answer: “Can I implement the concurrency patterns I need (queues, event groups, timers), and do I have robust debug visibility?” Most FreeRTOS issues are not “kernel bugs”—they’re stack sizing, priorities, or ISR misuse.

/* FreeRTOS: minimal pattern with two tasks + a queue.
 * Use this to validate your scheduling, priorities, and ISR-to-task design.
 * Notes:
 *  - Keep ISRs short: send to a queue (or task notification), do work in a task.
 *  - Turn on configASSERT and stack overflow checks in FreeRTOSConfig.h.
 */

#include <stdint.h>
#include <stdio.h>
#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"

static QueueHandle_t q;

static void SensorTask(void *arg) {
  (void)arg;
  uint16_t sample = 0;

  for (;;) {
    /* Replace with real sensor read (I2C/SPI/ADC). */
    sample = (uint16_t)((sample + 17u) % 1024u);

    /* Send sample to consumer; block briefly if queue is full. */
    (void)xQueueSend(q, &sample, pdMS_TO_TICKS(10));

    vTaskDelay(pdMS_TO_TICKS(20));
  }
}

static void AppTask(void *arg) {
  (void)arg;
  uint16_t sample = 0;

  for (;;) {
    if (xQueueReceive(q, &sample, portMAX_DELAY) == pdPASS) {
      /* Replace with application logic (filtering, control, reporting). */
      printf("sample=%u\r\n", (unsigned)sample);
    }
  }
}

int main(void) {
  q = xQueueCreate(16, sizeof(uint16_t));
  configASSERT(q != NULL);

  xTaskCreate(SensorTask, "sensor", 384, NULL, tskIDLE_PRIORITY + 2, NULL);
  xTaskCreate(AppTask,    "app",    512, NULL, tskIDLE_PRIORITY + 1, NULL);

  vTaskStartScheduler();

  /* If you get here, heap/stack/config is wrong. */
  for (;;) {}
}

Step 5 — Evaluate drivers and hardware description (the “board scale” test)

The fastest way to understand ecosystem differences is to change one thing about hardware and see what breaks: move a UART pin, add an I2C sensor, change an SPI frequency, or disable a peripheral for power. If you expect multiple board revisions, this matters a lot.

/* Zephyr devicetree overlay example (app.overlay)
 * Goal: enable I2C0 at 400 kHz and define a sensor on address 0x76.
 * (Exact node names vary by board/SoC; this shows the pattern.)
 */

/ {
  aliases {
    i2c-sensor = &bmp280;
  };
};

&i2c0 {
  status = "okay";
  clock-frequency = <I2C_BITRATE_FAST>;

  bmp280: bmp280@76 {
    compatible = "bosch,bmp280";
    reg = <0x76>;
    label = "BMP280";
  };
};

Step 6 — Make the choice using a scored checklist

After both prototypes, pick the RTOS that wins on the constraints you wrote in Step 1. This table is designed to be scored quickly. Mark each row with “FreeRTOS wins / Zephyr wins / tie” and write a one-line reason. That one-line reason becomes your decision record.

Step 7 — Lock your architecture boundaries

Once you choose, set boundaries early. This prevents the “Franken-firmware” outcome where every layer has two competing sources of truth. Keep the rules short and enforce them in code review.

Common mistakes

Most “RTOS bugs” are architecture bugs: priorities, stacks, interrupts, and configuration drift. Here are the common failure modes—and the fixes that save days.

FAQ

Is Zephyr “heavier” than FreeRTOS?

Often, yes—because Zephyr is typically used as a fuller OS platform. But “heavier” is not automatically bad. What matters is whether the included subsystems reduce your custom glue and maintenance. If your product needs drivers, networking, logging, and configuration consistency, Zephyr’s footprint may be worth it. If you need a minimal binary and you’ll build the stack yourself, FreeRTOS usually stays smaller and simpler.

Can I use vendor SDK drivers with either RTOS?

Typically yes. Many real products pair FreeRTOS with vendor SDK drivers, and Zephyr can also integrate vendor components in some cases. The important part is choosing one “primary” model for configuration and initialization. Mixing two driver worlds without boundaries is what creates hard-to-debug conflicts (clock init, interrupt priorities, power states).

Which one is better for networking and IoT features?

It depends on your vendor and constraints. Zephyr tends to offer a more integrated OS approach (consistent configuration and APIs), while FreeRTOS projects often rely on vendor or curated stacks. For IoT devices, test the exact combination you need: TLS handshake memory usage, reconnection behavior, and long-run stability under poor connectivity.

How do I avoid RTOS “random crashes” in production?

Treat observability as a feature: enable asserts, add stack usage tracking, keep ISRs short, and build a soak test. Most “random” crashes are stack overflow, race conditions, or priority problems. Catch them early with strict debug settings and by measuring stack/heap/queue usage over time.

Do I need tickless idle?

If you run on batteries or care about power, tickless idle (or equivalent low-power scheduling) is usually a must. But it only helps if your timers and wake sources are configured correctly and your peripherals truly allow deep sleep. Measure current draw and wake frequency—don’t assume.

What’s a safe way to decide if both seem fine?

Choose the one that best matches your long-term maintenance model: vendor-first (often FreeRTOS in SDKs) versus upstream-first (often Zephyr). If your team expects multiple boards and wants a consistent build/config story, Zephyr is frequently easier to scale. If your product is tightly tied to one vendor SDK and needs a minimal kernel, FreeRTOS is frequently the pragmatic choice.

Cheatsheet

Use this as a quick “RTOS selection and setup” checklist. If you can confidently check most of these boxes, you’re in a good place.

Wrap-up

FreeRTOS vs Zephyr is ultimately about choosing a development model. If you want a small, well-known kernel that fits neatly into vendor SDKs and you’re comfortable assembling your own stack, FreeRTOS is a strong and pragmatic choice. If you want a consistent, upstream-first platform with unified configuration, board support, and a driver model that scales across variants, Zephyr often pays off as the project grows.

The best next step is simple: take your target board and run the two prototypes from Quickstart—one peripheral, one connectivity path. Then make the choice based on what you can build, debug, and update confidently.

Related posts

• ESP32 Starter Guide: GPIO, Wi-Fi, and Real Projects
• Arduino to Prototyping: Sensors, Actuators, and Clean Wiring
• Raspberry Pi as a Home Server: Safe Setup and Use Cases
• UART vs I2C vs SPI: Which Protocol to Use and Why
• MQTT Explained: The Message Bus Behind Many IoT Systems
• Bluetooth Low Energy Basics: Advertising, GATT, and Power