Embedded Systems & Product Development Consultancy · London, UK

RTOS firmware: FreeRTOS, Zephyr and Micrium OS

Real-time firmware that keeps its timing as features, radios and sensors pile up. We design the task structure, priorities, memory and power states on FreeRTOS, Zephyr and Micrium OS, and take over RTOS codebases that have become hard to change.

Talk to an engineer Our firmware service

Tasks, priorities and the bugs that hide between them

An RTOS makes it easy to add one more task. Most real-time problems come from how those tasks share time, memory and data.

Priority inversion and starved tasks that only show up under full load.
Stack sizes guessed at the start and never measured, until one overflows in the field.
Shared data protected inconsistently, so race conditions appear as soon as the timing changes.
Interrupt handlers doing too much work, so latency grows with every new feature.
Heap fragmentation from dynamic allocation in a device that has to run for years.
Power modes fighting the scheduler: the device never sleeps, or wakes up too late.

We design the task model up front and measure it on hardware, so the timing stays predictable as the product grows.

RTOS work we take on

Task and timing architecture. Tasks, priorities, queues and event flows designed from the product’s real-time needs, with a timing budget for each critical path.
Board support and drivers. Interrupt and DMA drivers for SPI, I²C, UART, ADC and timers, written to work with the scheduler rather than against it. →
Connectivity stacks. BLE and Thread on Zephyr and Micrium OS, TCP/IP with lwIP on FreeRTOS, and MQTT through to the cloud. →
Low-power firmware. Tickless idle, sleep states and peripheral power control, measured with a power analyser on the real board. →
Displays and HMI. LVGL interfaces running alongside networking and sensor tasks without stalling either. →
Bootloaders and updates. Secure boot and over-the-air updates with rollback, from MCUboot on Zephyr to custom bootloaders. →

Designing for timing from day one

Start from the timing requirements. Which events need a response within microseconds, milliseconds or seconds, and what happens if one is missed.
Choose the kernel for the product. FreeRTOS, Zephyr, Micrium OS or bare metal, judged on footprint, vendor support, connectivity stacks, safety needs and licensing.
Design tasks, priorities and memory. Static allocation where possible, sized stacks and queues, and one clear owner for every shared resource.
Measure on the target. Trace recordings, stack watermarks, CPU load and current measured on real hardware, not estimated.
Test and hand over. Unit tests for the logic, hardware-in-the-loop tests for the timing, and a documented task model for whoever maintains it next.

Kernels, chips and debug tools

Kernels: FreeRTOS, Zephyr with the nRF Connect SDK, Micrium OS, custom schedulers and bare metal

Microcontrollers: STM32 (Cortex-M3, M4 and M7), NXP i.MX RT, Nordic nRF52 and nRF53, Silicon Labs EFR32, Microchip PIC32 and SAM, ESP32

Stacks and libraries: lwIP, Bluetooth LE, Thread, MQTT, LVGL, MCUboot, CMSIS

Debug and analysis: SEGGER J-Link and SystemView, Percepio Tracealyzer, IAR, Keil, MCUXpresso, STM32CubeIDE, GCC, power analysers

Three kernels, three products

Client names stay private. The engineering doesn’t.

Micrium OS firmware for a safety-critical device built at over a million units

View case studies

Zephyr firmware for a low-power wearable medical device

Read the case study

FreeRTOS in industrial monitoring

FreeRTOS with a tuned lwIP stack and an LVGL interface on an i.MX RT air-quality monitor for power stations, plus multi-processor RTOS firmware for marine transponders.

Ask about this work

Frequently asked RTOS questions

FreeRTOS or Zephyr: which should we use?

It depends on the chip, the connectivity you need and your team. FreeRTOS is small, simple and runs on almost every microcontroller. Zephyr brings drivers, Bluetooth LE and Thread stacks, a device tree and a full build system, which pays off on larger connected products, especially on Nordic parts. We’ll recommend one with reasons, not habit.

Do we need an RTOS at all?

Not always. A simple device with one main loop and a few interrupts can be cleaner on bare metal. An RTOS earns its place when several activities with different deadlines share the processor, or when you need a connectivity stack that expects one.

Can you move our firmware to an RTOS, or from one RTOS to another?

Yes. We map the existing loops and interrupts to tasks, move one subsystem at a time and keep the product working at every step. Moves from FreeRTOS to Zephyr are common when a product gains Bluetooth LE or Thread.

How do you find timing and memory problems?

By measuring: trace recordings of task switches and interrupts, stack watermarks, heap statistics and CPU load on the real hardware. Most RTOS bugs become obvious once the timeline is visible. For a product already in trouble, see embedded debugging and troubleshooting.

Can you work to safety standards on an RTOS?

Yes. We have developed safety-critical firmware to IEC 61508 on Micrium OS, with unit testing and code review in LDRA. Where certification is required, a pre-certified kernel is worth choosing early.

What about licensing?

FreeRTOS uses the MIT licence and Zephyr the Apache 2.0 licence, both suited to commercial products. We check the licence of every kernel, stack and library before it goes into your product.

Starting an RTOS project, or stuck in one?

Tell us the chip, the RTOS and what the firmware has to do on time.

An engineer will read it and reply within one business day.

Talk to an engineer