You Don't Need an RTOS (Part 4)
In this fourth (and final!) article I'll share with you the last of the inter-process communication (IPC) methods I mentioned in Part 3: mailboxes/queues, counting semaphores, the Observer pattern, and something I'm calling a "marquee". When we're done, we'll have created the scaffolding for tasks to interact in all sorts of different the ways. Additionally, I'll share with you another alternative design for a non-preemptive scheduler called a dispatch queue that is simple to conceptualize and, like the time-triggered scheduler, can help you schedule some of your most difficult task sets.
ANCS and HID: Controlling Your iPhone From Zephyr
In this blog post, we see how certain BLE services can be used to control an iPhone from a Nordic nRF52840 using The Zephyr Project. Specifically, we see how to control certain multimedia functionality using the HID service. Finally, we learn how to use the ANCS client library provided by Nordic in The Zephyr Project to accept or decline an incoming call.
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.
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.
A design non-methodology
Although writing an RTOS or kernel may be an interesting project, it is unlikely to be a wise course of action.
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.
Getting Started With Zephyr: Bluetooth Low Energy
In this blog post, I show how to enable BLE support in a Zephyr application. First, I show the necessary configuration options in Kconfig. Then, I show how to use the Zephyr functions and macros to create a custom service and characteristic for a contrived application.
Optimizing Real-Time Operating Systems for Efficient Edge Devices
Edge devices need real-time responsiveness but run on tight CPU, memory, and power budgets. This post breaks down what an RTOS brings to the edge: deterministic task scheduling, lean memory management, protocol support, and modular scalability, then tackles common challenges like synchronization and security. Read it for practical best practices on scheduling and protocols plus a look at future trends such as edge AI integration and interoperable infrastructure.
Getting Started With Zephyr: Writing Data to EEPROM
In this blog post, I show how to implement a Zephyr application to interact with EEPROM. I show how the Zephyr device driver model allows application writers to be free of the underlying implementation details. Unfortunately, the application didn't work as expected, and I'm still troubleshooting the cause.
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.
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.
You Don't Need an RTOS (Part 4)
In this fourth (and final!) article I'll share with you the last of the inter-process communication (IPC) methods I mentioned in Part 3: mailboxes/queues, counting semaphores, the Observer pattern, and something I'm calling a "marquee". When we're done, we'll have created the scaffolding for tasks to interact in all sorts of different the ways. Additionally, I'll share with you another alternative design for a non-preemptive scheduler called a dispatch queue that is simple to conceptualize and, like the time-triggered scheduler, can help you schedule some of your most difficult task sets.
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.
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.
Getting Started With Zephyr: Devicetree Bindings
This blog post shines some light on how devicetrees are used in The Zephyr Project. Specifically, we understand the mechanisms that enable us to use nodes in the devicetree in the C source files. We use a sample provided in the Zephyr repository itself and work our way through portions of the Zephyr codebase to get insight into the mechanisms that make this possible.
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 2 - Looking Inside and Creating Your Customized Image
This hands-on guide peels back the NuttX source tree and shows how to assemble a tailored firmware image. You will learn what each top-level directory does, how to enable apps with menuconfig and search tricks to resolve dependencies, and how to save a defconfig as a reusable board profile so you can rebuild the same image without repeating configuration steps.
Modern Embedded Systems Programming: Beyond the RTOS
Blocking-based RTOS tasks make embedded systems brittle and hard to extend, this post argues, and presents a practical alternative: active objects organized as message pumps. It explains why one-blocking-call tasks and nonblocking event handlers improve responsiveness and reduce task proliferation, and recommends using frameworks plus hierarchical state machines and UML to enforce good architecture and make designs scalable.
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.
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.
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.
Modern Embedded Systems Programming: Beyond the RTOS
Blocking-based RTOS tasks make embedded systems brittle and hard to extend, this post argues, and presents a practical alternative: active objects organized as message pumps. It explains why one-blocking-call tasks and nonblocking event handlers improve responsiveness and reduce task proliferation, and recommends using frameworks plus hierarchical state machines and UML to enforce good architecture and make designs scalable.
Getting Started With Zephyr: Kconfig
In this blog post, we briefly look at Kconfig, one of the core pieces of the Zephyr infrastructure. Kconfig allows embedded software developers to turn specific subsystems on or off within Zephyr efficiently and control their behavior. We also learn how we can practically use Kconfig to control the features of our application using the two most common mechanisms.
Getting Started With Zephyr: Devicetrees
This blog post provides an introduction to the "Devicetree", another unique concept in The Zephyr Project. We learn about the basic syntax of a device tree and how its structure and hierarchy mirror hardware, from the SoC to the final board. We also see how hardware described in a devicetree can be referenced and controlled in the source code of a Zephyr-based application.
Getting Started With Zephyr: Writing Data to EEPROM
In this blog post, I show how to implement a Zephyr application to interact with EEPROM. I show how the Zephyr device driver model allows application writers to be free of the underlying implementation details. Unfortunately, the application didn't work as expected, and I'm still troubleshooting the cause.
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.
Dumb Embedded System Mistakes: Running The Wrong Code
Running the wrong firmware on a board can waste hours. This post shows a practical marking strategy for embedded Linux that embeds searchable proof-of-life strings into kernel, rootfs, overlay, and application code. It walks through choosing early-boot log points, using compile-time timestamps, and a small shell script to set, find, and clear marks so you can verify builds before flashing.
Embedded Programming Video Course Teaches RTOS
From basic foreground/background loops to priority-inheritance protocols, this free video course walks you through building and improving an RTOS step by step. Lessons cover manual context switching, round-robin and preemptive priority schedulers, efficient thread blocking, and synchronization primitives. The series finishes with a practical port to a professional RTOS in the QP/C ecosystem, showing semaphores, mutexes, and ways to prevent priority inversion.
