FreeRTOS or Zephyr: choosing an RTOS for an embedded project

FreeRTOS and Zephyr answer the same starting question, how to run several activities on one microcontroller, with two answers that have almost nothing in common. FreeRTOS is a scheduler you add to your project. Zephyr is an operating system your project fits into. Everything else follows from that sentence.

Footprint, with numbers

This is the first comparison people make, and it misleads unless you compare equivalent scopes.

The only figure either project publishes is FreeRTOS's: the kernel alone occupies 5 to 10 KB of ROM according to its official documentation, the exact value depending on compiler, optimisation level and enabled features.

Zephyr publishes no equivalent, because the question makes less sense there: size depends entirely on which subsystems Kconfig enables. What the project does provide is the west build -t ram_report and rom_report targets, which give the real breakdown of your configuration, symbol by symbol. That is the only measurement worth having.

Take the principle rather than the numbers: the first row favours FreeRTOS. The gap narrows sharply once you add what a real product needs, because what Zephyr ships by default has to be bolted onto FreeRTOS. Measure your own configuration before deciding on this criterion: any general figure, including the ones quoted everywhere, rests on assumptions that are not yours.

So the useful question is not "which is smaller" but "at equal functional scope, which is smaller". The answer then depends on your scope.

What FreeRTOS does not provide

FreeRTOS gives you tasks, semaphores, queues, priority-inheritance mutexes, software timers and event groups. That is complete, proven, and it stops there.

It provides no driver model, no hardware abstraction layer, no network stack, no filesystem, no power management, no configuration system. All of that comes from the microcontroller vendor, as an SDK specific to them.

The practical consequence is lock-in: your application code calls vendor HAL functions. Changing silicon means rewriting that layer. On a product whose supply chain may tighten, that is a real industrial risk.

What Zephyr brings, and what it demands

Zephyr provides a unified driver model. A temperature sensor uses the same API whether it sits on I2C, SPI or inside the SoC. Changing microcontroller means, in the favourable case, changing a board file.

It also brings a full network stack with IPv6, Bluetooth LE, Thread and CAN, a filesystem, power management, a logging subsystem, an embedded shell and a test framework.

The price is real. The learning curve is steep: you must understand devicetree, Kconfig, the west tool and the module model before being productive. Budget two to four weeks for an experienced developer, against two or three days for FreeRTOS.

And configuration happens through two distinct mechanisms people must stop conflating: devicetree describes the hardware, Kconfig enables software features. A peripheral present in the devicetree whose driver is not enabled in Kconfig will not exist, and the reverse holds too.

The deciding factor: security and compliance

This is what changed most in the past three years, and it now outweighs footprint.

Zephyr is a Linux Foundation project with a written, public coordinated disclosure process. Its documentation states that any issue considered a security vulnerability shall be assigned a CVE number, and sets an embargo of at most 90 days, split into 30 days to fix within the project and 60 days for external parties building products on Zephyr to apply and distribute the fix. The project also publishes long-term support releases and builds SBOM generation into its tooling.

On certifications, be careful with what you read: functional safety work and security certifications apply to specific configurations and versions, not to "Zephyr" in general. Always check the exact scope of a certificate before relying on it in a compliance file.

FreeRTOS is maintained by Amazon, with long-term support releases and a certified variant, SafeRTOS, for functional safety use. But coverage extends only to the scheduler: the drivers and network stack you add remain your responsibility, including their CVE monitoring.

With the Cyber Resilience Act, that difference becomes structural. A system that produces its own SBOM and publishes CVEs per module removes a compliance burden you would otherwise carry yourself, for at least five years.

The decision table

How to decide

Pick FreeRTOS if the product is simple and fixed-function, if footprint is genuinely tight, if the team must ship fast with no ramp-up time, or if the vendor SDK already covers your whole need.

Pick Zephyr if the product is a range across several silicon parts, if it is connected and in CRA scope, if you need Bluetooth or Thread, or if its lifetime exceeds five years.

The most expensive trap is choosing FreeRTOS for the fast start, then spending three years rebuilding an abstraction layer, a network stack and a vulnerability management process. That is exactly what Zephyr provided, and having written it yourself does not make compliance any easier.

References

• FreeRTOS, Memory usage, boot times and context switch times FAQ, the 5 to 10 KB ROM figure for the kernel
• Zephyr Project, Security Vulnerability Reporting, CVE assignment and the 90-day embargo
• Zephyr Project, Optimization tools, ram_report and rom_report targets
• Zephyr Project, Release process and LTS
• WITTENSTEIN high integrity systems, SafeRTOS, the certified FreeRTOS variant

Going further

This choice becomes clear once you have written the same application on both, and measured what each demands before the first useful line. That is what our FreeRTOS and Zephyr RTOS programming courses cover.