Technology
RTOS Development (FreeRTOS, Zephyr)
A real-time operating system earns its place when a product has to hit deterministic deadlines under bounded jitter - control loops, communication stacks, and safety-adjacent systems where a missed deadline is a defect, not a warning. We build with FreeRTOS, Zephyr and Azure RTOS depending on which fits the product’s constraints.
What it is
What an RTOS is and when to reach for one.
A real-time operating system provides deterministic task scheduling, inter-task communication (queues, semaphores, event flags) and abstracted peripheral access - the primitives that let firmware do more than one thing predictably. FreeRTOS is the default for its ubiquity and vendor support (Amazon-backed, most silicon vendors ship reference ports); Zephyr is our default for greenfield programs where the drivers, security-model and device-tree architecture matter; Azure RTOS (ThreadX) shows up where the existing product ecosystem or certifications drive that choice.
We reach for an RTOS when a product runs multiple concurrent responsibilities (a sensor loop, a comms stack, a UI, a logging path) that must not block each other; when the timing budget requires deterministic scheduling; and when memory and compute headroom permit the runtime overhead. We stay on bare metal for hot control loops with a single dominant responsibility, and move to embedded Linux when the drivers, filesystems and networking of a full OS earn their weight.
Where we use it
RTOS Development (FreeRTOS, Zephyr) in shipped programs.
- Grid instrumentation firmware - FreeRTOS with DSP-class processing running deterministic sensing on Cortex-M7 hardware
- Autonomous platform safety monitors - Zephyr micro-ROS nodes on MCUs bridging to Linux compute over Zenoh
- Connected consumer products - FreeRTOS running Wi-Fi, BLE, sensor and cloud paths concurrently on ESP32 or STM32
Patterns and gotchas
What we watch for when building on an RTOS.
Priority inversion is real; design against it. Priority inheritance mutexes and disciplined priority assignment eliminate the class of bug where a low-priority task blocks a high-priority one indefinitely. We design the priority scheme up-front rather than debugging inversion in the field.
ISR discipline is the whole game. Interrupt service routines should be short, deterministic, and defer real work to a queued task; long ISRs are what make an RTOS-based system unpredictable. Every ISR gets a documented worst-case execution time before it ships.
Zephyr’s device tree is a first-class design surface. Coming from FreeRTOS, engineers sometimes treat Zephyr’s device tree as bureaucracy. It is not; it is where the hardware abstraction lives and where the vendor-provided drivers hook in. Design the tree the way you design the schematic.
Related
How this fits our practices.
RTOS Development (FreeRTOS, Zephyr) is a lens on our embedded firmware development practice. Adjacent tools and services: embedded systems, STM32 development, ESP32 development, embedded Linux.
Tell us what you’re building.
Send the constraint that worries you most - a latency budget, a power budget, a certification date. We’ll tell you straight whether we’re the right team.