Embedded Linux Board Farms 101: The Requirements That Actually Matter
When you keep your embedded Linux boards in a rack or remote lab, the "plug in HDMI" workflow breaks down fast. One bad kernel push and SSH never comes back. This post lays out the core requirements for a real board farm: out-of-band serial console access, remote power cycling, and scripted reimaging so you never need someone on-site who knows Linux. Once those primitives are in place, everyday smart home devices — Tasmota switches, Home Assistant, environmental sensors — become legitimate development tools that bring enterprise lab capabilities to a hobbyist budget. Includes a pre-flight checklist for transitioning from KVM-style access to a fully remote setup, and a preview of the full implementation presented at the Embedded Online Conference in May.
Debug, visualize and test embedded C/C++ through instrumentation
Instrumenting a firmware is a highly effective methodology for debugging and testing an embedded softwares. In this article, I will present a way of achieving this using Scrutiny, an open-source software suite developed as a personal initiative, designed to streamline debugging, telemetry, and hardware-in-the-loop (HIL) testing for embedded devices.
Simulating Your Embedded Project on Your Computer (Part 2)
Having a simulation of your embedded project is like having a superpower that improves the quality and pace of your development ten times over! To be useful, though, it can't take longer to develop the simulation than it takes to develop the application code and for many simulation techniques "the juice isn't worth the squeeze"! In the last article, I showed you how to use the terminal (i.e. printf/getchar) to easily make a completely functional simulation. In this article, we'll take simulation to the next level, either in terms of realism (by using virtual hardware) or in terms of user experience (by using a GUI to simulate our hardware, instead of using the terminal).
Simulating Your Embedded Project on Your Computer (Part 1)
Having a simulation of your embedded project is like having a superpower that improves the quality and pace of your development ten times over! To be useful, though, it can't take longer to develop the simulation than it takes to develop the application code and for many simulation techniques "the juice isn't worth the squeeze"! In this two-part blog series, I'll share with you the arguments in favor of simulation (so, hopefully, you too believe in its value) and I'll show you what works (and what doesn't work) to help you to simply, easily, and quickly simulate your embedded project on your computer.
C++ Assertion? Well Yes, But Actually No.
Assertions are a double-edged sword - on one side you enforce program correctness catching bugs close to their origin, on the other your application is subject to run-time error, like any interpreted language. This article explores what C++ can offer to get the advantages of assertions, without risking the crashes by moving contract checking at compile time.
Bit-Banged Async Serial Output And Disciplined Engineering
This post covers implementing asynchronous serial output directly on a GPIO with bit-banging. This can be a valuable debug tool for getting information out of a system. It also covers disciplined engineering, using the bit-banging module as an example and template you can apply to other projects.
Visual Studio Code Extensions for Embedded Software Development
Visual Studio Code can be a solid embedded development environment, if you equip it with the right extensions. Jacob Beningo walks through tools for Cortex-M debugging, register and RTOS inspection, build system support, formatting, linting, and vendor-specific workflows. It is a practical tour of the extensions that help VS Code feel much less like a general-purpose editor and more like an embedded IDE.
Examining The Stack For Fun And Profit
Stack bloat can hide in short initialization paths, and this post walks through finding it with hands-on debugging. The author builds a tiny test program and uses gdb plus custom stack-helper scripts to scan, watch, and walk the stack. That process reveals getaddrinfo pulling in glibc DNS code that allocates large local buffers and uses alloca and PLT resolution, consuming roughly 11KB of stack.
Debugging DSP code.
Strange sinusoidal confidence scores from an HTM neural model revealed a familiar class of DSP bugs. Drawing from forum troubleshooting, the post maps common root causes: signed versus absolute value errors, wrong intermediate references, scaling mistakes, and sampling/stride problems in integer math. Embedded engineers will recognize the diagnostic clues and practical suspects to check first when DSP outputs vary with the input.
The Hardest Bug I Never Solved
A single overlooked sentence in the STM32 datasheet turned intermittent startup resets into a major time-leach. Senior engineers chased DMA buffers and overflows for hours until Unni discovered the ISR vector table had been relocated to RAM with only 256 byte alignment while the MCU required 512 bytes. The misalignment caused interrupts to jump to the reset handler, and fixing the alignment stopped the reboot loop for good.
Debug, visualize and test embedded C/C++ through instrumentation
Instrumenting a firmware is a highly effective methodology for debugging and testing an embedded softwares. In this article, I will present a way of achieving this using Scrutiny, an open-source software suite developed as a personal initiative, designed to streamline debugging, telemetry, and hardware-in-the-loop (HIL) testing for embedded devices.
Analyzing the Linker Map file with a little help from the ELF and the DWARF
Running out of Flash or RAM is a familiar pain for firmware engineers, and the linker map only tells part of the story. This post shows how to combine the linker MAP with ELF symbol tables and DWARF debug info to recover static symbols, sizes, and source files that the map omits. It also describes a C# WinForms viewer that automates the parsing with binutils and helps you spot module and symbol-level memory waste.
Simulating Your Embedded Project on Your Computer (Part 1)
Having a simulation of your embedded project is like having a superpower that improves the quality and pace of your development ten times over! To be useful, though, it can't take longer to develop the simulation than it takes to develop the application code and for many simulation techniques "the juice isn't worth the squeeze"! In this two-part blog series, I'll share with you the arguments in favor of simulation (so, hopefully, you too believe in its value) and I'll show you what works (and what doesn't work) to help you to simply, easily, and quickly simulate your embedded project on your computer.
Visual Studio Code Extensions for Embedded Software Development
Visual Studio Code can be a solid embedded development environment, if you equip it with the right extensions. Jacob Beningo walks through tools for Cortex-M debugging, register and RTOS inspection, build system support, formatting, linting, and vendor-specific workflows. It is a practical tour of the extensions that help VS Code feel much less like a general-purpose editor and more like an embedded IDE.
Simulating Your Embedded Project on Your Computer (Part 2)
Having a simulation of your embedded project is like having a superpower that improves the quality and pace of your development ten times over! To be useful, though, it can't take longer to develop the simulation than it takes to develop the application code and for many simulation techniques "the juice isn't worth the squeeze"! In the last article, I showed you how to use the terminal (i.e. printf/getchar) to easily make a completely functional simulation. In this article, we'll take simulation to the next level, either in terms of realism (by using virtual hardware) or in terms of user experience (by using a GUI to simulate our hardware, instead of using the terminal).
C++ Assertion? Well Yes, But Actually No.
Assertions are a double-edged sword - on one side you enforce program correctness catching bugs close to their origin, on the other your application is subject to run-time error, like any interpreted language. This article explores what C++ can offer to get the advantages of assertions, without risking the crashes by moving contract checking at compile time.
Embedded Linux Board Farms 101: The Requirements That Actually Matter
When you keep your embedded Linux boards in a rack or remote lab, the "plug in HDMI" workflow breaks down fast. One bad kernel push and SSH never comes back. This post lays out the core requirements for a real board farm: out-of-band serial console access, remote power cycling, and scripted reimaging so you never need someone on-site who knows Linux. Once those primitives are in place, everyday smart home devices — Tasmota switches, Home Assistant, environmental sensors — become legitimate development tools that bring enterprise lab capabilities to a hobbyist budget. Includes a pre-flight checklist for transitioning from KVM-style access to a fully remote setup, and a preview of the full implementation presented at the Embedded Online Conference in May.
Examining The Stack For Fun And Profit
Stack bloat can hide in short initialization paths, and this post walks through finding it with hands-on debugging. The author builds a tiny test program and uses gdb plus custom stack-helper scripts to scan, watch, and walk the stack. That process reveals getaddrinfo pulling in glibc DNS code that allocates large local buffers and uses alloca and PLT resolution, consuming roughly 11KB of stack.
Bit-Banged Async Serial Output And Disciplined Engineering
This post covers implementing asynchronous serial output directly on a GPIO with bit-banging. This can be a valuable debug tool for getting information out of a system. It also covers disciplined engineering, using the bit-banging module as an example and template you can apply to other projects.
Unit Tests for Embedded Code
Unit tests are one of the most effective ways to catch logic bugs early and protect embedded firmware against regressions. Stephen Friederichs explains why unit testing matters for microcontroller code, when to test, and the trade-offs between on-target and hosted approaches, with practical advice on stubbing, using the Check framework, simulators, and coverage tools to make testing realistic for embedded projects.
Analyzing the Linker Map file with a little help from the ELF and the DWARF
Running out of Flash or RAM is a familiar pain for firmware engineers, and the linker map only tells part of the story. This post shows how to combine the linker MAP with ELF symbol tables and DWARF debug info to recover static symbols, sizes, and source files that the map omits. It also describes a C# WinForms viewer that automates the parsing with binutils and helps you spot module and symbol-level memory waste.
Unit Tests for Embedded Code
Unit tests are one of the most effective ways to catch logic bugs early and protect embedded firmware against regressions. Stephen Friederichs explains why unit testing matters for microcontroller code, when to test, and the trade-offs between on-target and hosted approaches, with practical advice on stubbing, using the Check framework, simulators, and coverage tools to make testing realistic for embedded projects.
Visual Studio Code Extensions for Embedded Software Development
Visual Studio Code can be a solid embedded development environment, if you equip it with the right extensions. Jacob Beningo walks through tools for Cortex-M debugging, register and RTOS inspection, build system support, formatting, linting, and vendor-specific workflows. It is a practical tour of the extensions that help VS Code feel much less like a general-purpose editor and more like an embedded IDE.
Delayed printf for real-time logging
Yossi Kreinin demonstrates delayed printf, a technique that records printf format pointers and raw argument words into a compact buffer so logging does not disturb real-time timing. He walks through a small C++11 writer using variadic templates and an atomic buffer plus a gdb Python reader that reconstructs formatted messages from executables or core dumps. The result is readable post-processed logs with minimal runtime overhead.
Simulating Your Embedded Project on Your Computer (Part 1)
Having a simulation of your embedded project is like having a superpower that improves the quality and pace of your development ten times over! To be useful, though, it can't take longer to develop the simulation than it takes to develop the application code and for many simulation techniques "the juice isn't worth the squeeze"! In this two-part blog series, I'll share with you the arguments in favor of simulation (so, hopefully, you too believe in its value) and I'll show you what works (and what doesn't work) to help you to simply, easily, and quickly simulate your embedded project on your computer.
Examining The Stack For Fun And Profit
Stack bloat can hide in short initialization paths, and this post walks through finding it with hands-on debugging. The author builds a tiny test program and uses gdb plus custom stack-helper scripts to scan, watch, and walk the stack. That process reveals getaddrinfo pulling in glibc DNS code that allocates large local buffers and uses alloca and PLT resolution, consuming roughly 11KB of stack.
Bit-Banged Async Serial Output And Disciplined Engineering
This post covers implementing asynchronous serial output directly on a GPIO with bit-banging. This can be a valuable debug tool for getting information out of a system. It also covers disciplined engineering, using the bit-banging module as an example and template you can apply to other projects.
Debugging with Heartbeat LEDs
Heartbeat LEDs are one of the simplest and most effective debugging tools for embedded systems. Stephen Friederichs explains how a visible 1Hz blink from your main loop or RTOS idle task proves the MCU is executing and quickly highlights problems like failed programming, watchdog resets, infinite loops, or clock misconfiguration. He also explains why using hardware timers instead of delay loops keeps the blink nonblocking and accurate.
C++ Assertion? Well Yes, But Actually No.
Assertions are a double-edged sword - on one side you enforce program correctness catching bugs close to their origin, on the other your application is subject to run-time error, like any interpreted language. This article explores what C++ can offer to get the advantages of assertions, without risking the crashes by moving contract checking at compile time.
Simulating Your Embedded Project on Your Computer (Part 2)
Having a simulation of your embedded project is like having a superpower that improves the quality and pace of your development ten times over! To be useful, though, it can't take longer to develop the simulation than it takes to develop the application code and for many simulation techniques "the juice isn't worth the squeeze"! In the last article, I showed you how to use the terminal (i.e. printf/getchar) to easily make a completely functional simulation. In this article, we'll take simulation to the next level, either in terms of realism (by using virtual hardware) or in terms of user experience (by using a GUI to simulate our hardware, instead of using the terminal).
