Can an RTOS be really real-time?
Real-Time Operating Systems are meant for real-time applications. But with conventional shared-state concurrency and blocking, can you honestly know the worst-case execution time of an RTOS thread?
Getting Started With Zephyr: DTS vs DTSI vs Overlays
Devicetrees can be daunting for traditional embedded software engineers that are new to Zephyr. In this blog post, I address these fears and show how navigating Devicetrees can be much easier if you understand that they represent the layered structure of the underlying hardware.
Getting Started With Zephyr: Using GDB To Fix a Driver Bug
In this blog post, I show how to use GDB to debug an issue encountered with a TSL2591 light sensor driver in Zephyr. The fix was submitted and successfully incorporated into The Zephyr Project.
How to Achieve Deterministic Behavior in Real-Time Embedded Systems
Ensuring deterministic behavior in real-time embedded systems is paramount for their reliability and performance. The ability to predict precisely how a system will respond to various inputs at any given time is crucial in critical applications such as medical devices, aerospace systems, and automotive safety mechanisms. Achieving deterministic behavior involves meticulous design, stringent testing, and adherence to strict timing constraints.
Hidden Gems from the Embedded Online Conference Archives - Part 1
Discussion of a "hidden gem" from the Embedded Online Conference archives!
OS influence on power consumption
Power consumption of an embedded system may be influenced in software in general, but selection of an operating system can be key.
Zephyr: West Manifest For Application Development
In this blog post, I show a simpler way to create custom West manifest files. This technique eliminates the need to duplicate the complex West manifest from upstream Zephyr. I also show how we can use the West manifest to include out-of-tree board and SoC definitions, and include our own out-of-tree drivers.
What is “real time”?
The post clarifies the technical meaning of “real time” for embedded systems and contrasts it with the colloquial sense of immediacy. It presents a precise definition: a real-time system’s correctness depends on both logical results and the time at which those results are produced, so missing timing constraints constitutes failure. The article emphasizes determinism — low variance in operation timing — as the key property of real-time systems, and contrasts classic RTOS behavior with general-purpose Linux’s higher timing variance. It also notes that raw CPU overprovisioning can mask nondeterminism in some designs, but is not always practical, reinforcing that real time means predictable timing sufficient for the application, not simply “fast.”
Product quality: belief or proof?
Embedded software development is a challenging activity, so it is essential to have tools and IP that is of the best quality. However, assessing that quality can be, in itself, a challenge.
Stand-by or boot-up
Many factors affect the usability of devices - a key one is how long it takes to start up.
You Don't Need an RTOS (Part 1)
In this first article, we'll compare our two contenders, the superloop and the RTOS. We'll define a few terms that help us describe exactly what functions a scheduler does and why an RTOS can help make certain systems work that wouldn't with a superloop. By the end of this article, you'll be able to: - Measure or calculate the deadlines, periods, and worst-case execution times for each task in your system, - Determine, using either a response-time analysis or a utilization test, if that set of tasks is schedulable using either a superloop or an RTOS, and - Assign RTOS task priorities optimally.
How to Achieve Deterministic Behavior in Real-Time Embedded Systems
Ensuring deterministic behavior in real-time embedded systems is paramount for their reliability and performance. The ability to predict precisely how a system will respond to various inputs at any given time is crucial in critical applications such as medical devices, aerospace systems, and automotive safety mechanisms. Achieving deterministic behavior involves meticulous design, stringent testing, and adherence to strict timing constraints.
You Don't Need an RTOS (Part 2)
In this second article, we'll tweak the simple superloop in three critical ways that will improve it's worst-case response time (WCRT) to be nearly as good as a preemptive RTOS ("real-time operating system"). We'll do this by adding task priorities, interrupts, and finite state machines. Additionally, we'll discuss how to incorporate a sleep mode when there's no work to be done and I'll also share with you a different variation on the superloop that can help schedule even the toughest of task sets.
You Don't Need an RTOS (Part 3)
In this third article I'll share with you a few cooperative schedulers (with a mix of both free and commercial licenses) that implement a few of the OS primitives that the "Superduperloop" is currently missing, possibly giving you a ready-to-go solution for your system. On the other hand, I don't think it's all that hard to add thread flags, binary and counting semaphores, event flags, mailboxes/queues, a simple Observer pattern, and something I call a "marquee" to the "Superduperloop"; I'll show you how to do that in the second half of this article and the next. Although it will take a little more work than just using one of the projects above, it will give you the maximum amount of control over your system and it will let you write tasks in ways you could only dream of using an RTOS or other off-the-shelf system.
Review: Hands-On RTOS with Microcontrollers
Brian Amos's Hands-On RTOS with Microcontrollers delivers a practical path from bare-metal to full RTOS applications using FreeRTOS on an STM32 Nucleo-F767ZI board. The book combines clear explanations of concurrency, interrupts, and DMA with step-by-step toolchain setup and runnable examples that show building, debugging, monitoring, and scaling embedded systems for real projects and coursework.
Mutex vs. Semaphore - Part 1
Most forum answers get the semaphore versus mutex debate wrong. This post traces semaphores back to Dijkstra and Scholten, explains the difference between binary and counting semaphores, and highlights runtime hazards such as accidental release, recursive and task-death deadlocks, priority inversion, and misuse as signals. Read if you want to avoid common concurrency pitfalls in RTOS code.
Getting Started with (Apache) NuttX RTOS - Part 1
NuttX RTOS is used in many products from companies like Sony, Xiaomi, Samsung, Google/Fitbit, WildernessLabs and many other companis. So, probably you are already using NuttX even without knowing it, like the you was using Linux on your TV, WiFi router more than 10 years ago and didn't know too! Today you will have the chance to discover a little bit of this fantastic Linux-like RTOS! Are you ready? So, let's get started!
Can an RTOS be really real-time?
Real-Time Operating Systems are meant for real-time applications. But with conventional shared-state concurrency and blocking, can you honestly know the worst-case execution time of an RTOS thread?
Getting Started With Zephyr: DTS vs DTSI vs Overlays
Devicetrees can be daunting for traditional embedded software engineers that are new to Zephyr. In this blog post, I address these fears and show how navigating Devicetrees can be much easier if you understand that they represent the layered structure of the underlying hardware.
Getting Started With Zephyr: Saving Data To Files
In this blog post, I show how to implement a Zephyr application to mount a microSD card, create a new file on the microSD card, and write data to it. The lessons learned from such an application can be helpful for devices out in the field that need to write data to off-board memory periodically, especially in cases where Internet access may be sporadic.
Using the Beaglebone PRU to achieve realtime at low cost
Fabien Le Mentec shows how the BeagleBone Black's PRU coprocessors can run hard realtime control loops, removing the need for an FPGA or dedicated microcontroller. He walks through Linux setup, device tree enabling, assembler and loader tools, and a timer example that reads ADCs and drives PWM from PRU code. The post highlights community SDKs and a recent TI Code Composer Studio option for C-based PRU development.
From Baremetal to RTOS: A review of scheduling techniques
Jacob Beningo walks through five common embedded scheduling techniques, showing how each scales from a single super loop to a full RTOS. He highlights practical trade-offs for round-robin, interrupt-driven, queued, cooperative, and RTOS approaches so you can spot when timing becomes fragile and when added complexity is justified. This primer sets up the next post on when to adopt an RTOS.
You Don't Need an RTOS (Part 1)
In this first article, we'll compare our two contenders, the superloop and the RTOS. We'll define a few terms that help us describe exactly what functions a scheduler does and why an RTOS can help make certain systems work that wouldn't with a superloop. By the end of this article, you'll be able to: - Measure or calculate the deadlines, periods, and worst-case execution times for each task in your system, - Determine, using either a response-time analysis or a utilization test, if that set of tasks is schedulable using either a superloop or an RTOS, and - Assign RTOS task priorities optimally.
From bare-metal to RTOS: 5 Reasons to use an RTOS
Most developers default to bare-metal, but Jacob Beningo argues an RTOS often simplifies modern embedded design. He outlines five practical reasons to move to an RTOS: easier integration of connectivity stacks and GUIs, true preemptive scheduling with priorities, tunable footprints, API-driven portability, and a common toolset for tasks and synchronization. The piece helps decide when RTOS adoption speeds development.
Getting Started with (Apache) NuttX RTOS - Part 1
NuttX RTOS is used in many products from companies like Sony, Xiaomi, Samsung, Google/Fitbit, WildernessLabs and many other companis. So, probably you are already using NuttX even without knowing it, like the you was using Linux on your TV, WiFi router more than 10 years ago and didn't know too! Today you will have the chance to discover a little bit of this fantastic Linux-like RTOS! Are you ready? So, let's get started!
Mutex vs. Semaphore - Part 1
Most forum answers get the semaphore versus mutex debate wrong. This post traces semaphores back to Dijkstra and Scholten, explains the difference between binary and counting semaphores, and highlights runtime hazards such as accidental release, recursive and task-death deadlocks, priority inversion, and misuse as signals. Read if you want to avoid common concurrency pitfalls in RTOS code.
Getting Started With Zephyr: West Manifest Customization
Create a reproducible Zephyr development baseline by customizing a West manifest, so your team avoids surprises from upstream changes. This post walks through forking Zephyr and MCUBoot when you need local changes, adapting Nordic Semiconductor's west.yml as a template, and updating remotes and defaults to point at your forks. Finish by running west init -m
Review: Hands-On RTOS with Microcontrollers
Brian Amos's Hands-On RTOS with Microcontrollers delivers a practical path from bare-metal to full RTOS applications using FreeRTOS on an STM32 Nucleo-F767ZI board. The book combines clear explanations of concurrency, interrupts, and DMA with step-by-step toolchain setup and runnable examples that show building, debugging, monitoring, and scaling embedded systems for real projects and coursework.
Getting Started With Zephyr: Devicetree Overlays
In this blog post, I show how the Devicetree overlay is a valuable construct in The Zephyr Project RTOS. Overlays allow embedded software engineers to override the default pin configuration specified in Zephyr for a particular board. In this blog post, I use I2C as an example. Specifically, I showed the default I2C pins used for the nRF52840 development kit in the nominal Zephyr Devicetree. Then, I demonstrated how an overlay can be used to override this pin configuration and the final result.
Round-robin or RTOS for my embedded system
Manuel Herrera walks through the practical tradeoffs between bare-metal round-robin loops and adopting an RTOS for embedded projects. He outlines two round-robin styles, explains how an RTOS gives independent threads and synchronization primitives, and highlights added code, licensing, interrupt latency, and the learning curve. Read this to sharpen decision criteria around timing guarantees, reuse, and whether an RTOS truly adds value to your firmware.
