Hidden Gems from the Embedded Online Conference Archives - Part 3
Jack Ganssle shows us what we can learn by studying previous failures - and why this is essential for anyone working in embedded systems.
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.
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.
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.
Are We Shooting Ourselves in the Foot with Stack Overflow?
Most traditional, beaten-path memory layouts allocate the stack space above the data sections in RAM, even though the stack grows “down” (towards the lower memory addresses) in most embedded processors. This arrangement puts your program data in the path of destruction of a stack overflow. In other words, you violate the first Gun Safety Rule (ALWAYS keep the gun pointed in a safe direction!) and you end up shooting yourself in the foot. This article shows how to locate the stack at the BEGINNING of RAM and thus point it in the "safe" direction.
Watchdog Timer Anti-patterns
A watchdog timer can be useless or even harmful when misused. This post catalogs the most common watchdog anti-patterns, including feeding the watchdog unconditionally from a timer ISR, suspending it during long operations, sprinkling resets across code, timeout auctions, incomplete reset trees, and treating process supervision as a substitute for hardware. It finishes with practical rules to design watchdogs that genuinely improve embedded system reliability.
Is it a Bug or an Error?
The famous moth-in-the-relay story helped 'bug' and 'debugging' become everyday terms, but this piece questions whether that cozy label softens accountability. It argues software failures usually come from human mistakes in requirements or implementation, not literal insects, and asks whether using words like 'error' or 'mistake' would push engineers to treat safety and reliability more seriously. Join the conversation.
The three laws of safe embedded systems
This short article is part of an ongoing series in which I aim to explore some techniques that may be useful for developers and organisations that are beginning their first safety-related embedded project.
Developing software for a safety-related embedded system for the first time
Developing a safety-related embedded product is not the same as writing ordinary firmware, and this article lays out eight practical steps to get you started. Using a washing-machine controller as a running example, it covers scoping, key requirements, hazard analysis, applicable standards, platform and MCU choices, runtime monitoring, and prototyping. The checklist helps teams prepare for verification, testing, and later certification work.
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.
Are We Shooting Ourselves in the Foot with Stack Overflow?
Most traditional, beaten-path memory layouts allocate the stack space above the data sections in RAM, even though the stack grows “down” (towards the lower memory addresses) in most embedded processors. This arrangement puts your program data in the path of destruction of a stack overflow. In other words, you violate the first Gun Safety Rule (ALWAYS keep the gun pointed in a safe direction!) and you end up shooting yourself in the foot. This article shows how to locate the stack at the BEGINNING of RAM and thus point it in the "safe" direction.
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.
Watchdog Timer Anti-patterns
A watchdog timer can be useless or even harmful when misused. This post catalogs the most common watchdog anti-patterns, including feeding the watchdog unconditionally from a timer ISR, suspending it during long operations, sprinkling resets across code, timeout auctions, incomplete reset trees, and treating process supervision as a substitute for hardware. It finishes with practical rules to design watchdogs that genuinely improve embedded system reliability.
Developing software for a safety-related embedded system for the first time
Developing a safety-related embedded product is not the same as writing ordinary firmware, and this article lays out eight practical steps to get you started. Using a washing-machine controller as a running example, it covers scoping, key requirements, hazard analysis, applicable standards, platform and MCU choices, runtime monitoring, and prototyping. The checklist helps teams prepare for verification, testing, and later certification work.
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.
The three laws of safe embedded systems
This short article is part of an ongoing series in which I aim to explore some techniques that may be useful for developers and organisations that are beginning their first safety-related embedded project.
Is it a Bug or an Error?
The famous moth-in-the-relay story helped 'bug' and 'debugging' become everyday terms, but this piece questions whether that cozy label softens accountability. It argues software failures usually come from human mistakes in requirements or implementation, not literal insects, and asks whether using words like 'error' or 'mistake' would push engineers to treat safety and reliability more seriously. Join the conversation.
Hidden Gems from the Embedded Online Conference Archives - Part 3
Jack Ganssle shows us what we can learn by studying previous failures - and why this is essential for anyone working in embedded systems.
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.
Watchdog Timer Anti-patterns
A watchdog timer can be useless or even harmful when misused. This post catalogs the most common watchdog anti-patterns, including feeding the watchdog unconditionally from a timer ISR, suspending it during long operations, sprinkling resets across code, timeout auctions, incomplete reset trees, and treating process supervision as a substitute for hardware. It finishes with practical rules to design watchdogs that genuinely improve embedded system reliability.
Are We Shooting Ourselves in the Foot with Stack Overflow?
Most traditional, beaten-path memory layouts allocate the stack space above the data sections in RAM, even though the stack grows “down” (towards the lower memory addresses) in most embedded processors. This arrangement puts your program data in the path of destruction of a stack overflow. In other words, you violate the first Gun Safety Rule (ALWAYS keep the gun pointed in a safe direction!) and you end up shooting yourself in the foot. This article shows how to locate the stack at the BEGINNING of RAM and thus point it in the "safe" direction.
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.
Developing software for a safety-related embedded system for the first time
Developing a safety-related embedded product is not the same as writing ordinary firmware, and this article lays out eight practical steps to get you started. Using a washing-machine controller as a running example, it covers scoping, key requirements, hazard analysis, applicable standards, platform and MCU choices, runtime monitoring, and prototyping. The checklist helps teams prepare for verification, testing, and later certification work.
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.
Hidden Gems from the Embedded Online Conference Archives - Part 3
Jack Ganssle shows us what we can learn by studying previous failures - and why this is essential for anyone working in embedded systems.
The three laws of safe embedded systems
This short article is part of an ongoing series in which I aim to explore some techniques that may be useful for developers and organisations that are beginning their first safety-related embedded project.
Is it a Bug or an Error?
The famous moth-in-the-relay story helped 'bug' and 'debugging' become everyday terms, but this piece questions whether that cozy label softens accountability. It argues software failures usually come from human mistakes in requirements or implementation, not literal insects, and asks whether using words like 'error' or 'mistake' would push engineers to treat safety and reliability more seriously. Join the conversation.
