Tech news in 3 minutes
Reinventing the Embedded Firmware Ecosystem (Again)!
Just when I think I’ve seen everything, I find myself being introduced to an AI-powered hardware-in-the-loop (HIL) testing framework that lets any embedded design team build a fully automated pipeline on real hardware in a matter of hours. I hail from the land before time and the days before embedded systems. This isn’t to say that embedded systems didn’t exist; it’s just that no one had coined the “embedded” moniker at that time, and the systems themselves bore little resemblance to what we think of as embedded systems today. Just to set the scene… how would you define an embedded system? Does it have to be electronic, or could it be clockwork? Must it be digital, or can it be analog? Does it have to involve a computer in the form of a microprocessor or a microcontroller? I’m afraid this is one of my hobby horses; that is, cogitating, ruminating, and waffling on about this with my embedded engineering friends is one of my favorite pastimes. For example, this is the point in the conversation where I would typically say something like, “But what about centrifugal governors, examples of which were invented by Christiaan Huygens in the seventeenth century?” I would then go on to note (irrespective of how hard they tried to stop me) that the same technology was used by James Watt to control steam engines. An example is shown below. As the speed of rotation increases, the two balls move outwards and upwards, thereby controlling a valve. By automatically adjusting the steam flow in response to engine speed, the governor formed a closed feedback loop that maintained a constant speed without human intervention. In 1868, James Clerk Maxwell analyzed such governors in his landmark paper On Governors, laying much of the mathematical foundation for modern control theory. Boulton & Watt steam engine circa 1788 (Source: Dr. Mirko Junge/Wikipedia) The point here is that this is purely analog, with no digital processing involved, yet I would argue that as a key element of a much larger system, it was the equivalent of an embedded controller—albeit one constructed entirely from brass, steel, and cleverness. Precursors to what we now consider to be embedded systems date back to the 1960s. The Apollo Guidance Computer (1965) is often cited as one of the first recognizably modern examples. However, engineers in the 1960s and much of the 1970s didn’t generally talk about “embedded systems.” They were more likely to refer to dedicated computers, process-control computers, microprocessor-based controllers, intelligent instruments, microcomputer-based products, and firmware-controlled devices. The phrase “embedded system“ didn’t start to become common until the late 1970s and early 1980s as microprocessors and microcontrollers began to find their way into industrial equipment, automobiles, appliances, instrumentation, and communications products. By the mid-to-late 1980s, this term was well established in the engineering press, textbooks, and conferences. For much of their history, embedded systems lived quiet, self-contained lives. They were tucked away inside washing machines, industrial controllers, automobiles, medical instruments, and countless other products. They monitored sensors, drove actuators, and faithfully performed their assigned tasks, but they rarely communicated beyond the boundaries of the system they inhabited. In fact, a definition of an embedded system that resonated with me at that time was: “A system you don’t even know is there… until it stops working.” Then came the Internet, followed by the Internet of Things (IoT). Suddenly, embedded systems were no longer isolated. They started talking to cloud services, smartphones, other devices, and each other. Data flowed in every direction. Updates could be delivered remotely. Intelligence could be distributed across entire fleets of devices. At the same time, many embedded systems emerged from their dark and dingy hiding places and began basking in the light of day. No longer buried deep inside industrial equipment, they appeared in smartwatches, fitness trackers, augmented-reality glasses, handheld medical devices, smart speakers, and countless other products that users interact with directly every day. In a sense, the term “embedded system” has become a victim of its own success. Many of today’s systems are no longer hidden away. They’re right there in front of us. Perhaps “in-your-face systems” would be a more appropriate description. Of course, if that term had caught on, generations of engineers would now be proudly describing themselves as “in-your-face system designers,” which somehow doesn’t have quite the same ring to it, but—as usual—we digress… The point is that embedded systems have reinvented themselves several times already. They evolved from mechanical analog controllers to digital microprocessor-based systems, from isolated devices to connected IoT nodes, and from hidden components to products in their own right. Now they appear to be embarking on yet another transformation—one in which artificial intelligence is becoming an active participant in the design, development, testing, and maintenance process itself. The reason for this historical ramble is that I was just chatting with Noah Pacik-Nelson, Co-Founder and CEO at BootLoop, along with Ollie Rubens, who is helping build out the company and bring its technology to larger enterprise customers. BootLoop may be a newcomer, having been incorporated only in the summer of 2025, but it has already attracted customers working on everything from aerospace systems and fusion-energy projects to medical devices, wearables, and datacenter infrastructure. Now, I don’t care what anyone says; that’s impressive! The founders bring a rather eclectic mix of expertise to the table. Noah’s background spans ultra-low-power AI research, embedded vision and speech systems, and large-language-model agent frameworks. The company’s other founder, Chris Markus, contributes the sort of firmware pedigree that tends to make embedded engineers sit up and take notice. Among other things, Chris served as the firmware lead for SpaceX’s Raptor engine and later led software efforts for Starship booster recovery. The two founders first worked together during the COVID-19 pandemic on a ventilator project and later collaborated at the MIT Media Lab before deciding to tackle what they saw as some of the biggest bottlenecks in embedded hardware development. The interesting thing is that BootLoop isn’t simply another AI coding assistant. The company views embedded development as a three-stage process: build it, test it, and fix it. To address these stages, the platform comprises three complementary offerings: Develop, Test, and Debug. The first of these, BootLoop Develop, focuses on firmware creation and hardware bring-up. Before generating a single line of code, the system ingests schematics, netlists, board design files, datasheets, reference manuals, register maps, API documentation, and other design collateral. In effect, it constructs a firmware-centric understanding of the hardware platform. Only then does it begin generating code. More importantly, it doesn’t simply generate code and wish the developer good luck. The generated firmware is continuously exercised on real hardware throughout the process. As the folks at BootLoop like to say, the goal is to create code that works, not merely code that compiles. BootLoop Develop can be used for new-board bring-up, driver development, MCU migration projects, feature additions, performance tuning, and security hardening. In each case, the system leverages its understanding of both the hardware and software environment to accelerate work that would traditionally consume days or weeks of engineering effort. At the opposite end of the lifecycle lies BootLoop Debug, internally known as Sentinel. This tool addresses the inevitable reality that no matter how carefully we design our systems, bugs will eventually escape into the wild. When a bug report arrives—perhaps as a Jira ticket accompanied by logs, crash dumps, or diagnostic data—Sentinel analyzes the available information alongside the codebase itself. It then generates a root cause analysis (RCA) report that highlights likely failure mechanisms, relevant files, execution paths, and potential fixes. Over time, the system develops an institutional memory of previous failures and their resolutions, allowing it to recognize recurring patterns and accelerate future investigations. Although both Develop and Debug are impressive in their own right, the real reason for our conversation was the launch of BootLoop Test, which occupies the critical middle ground between firmware creation and field maintenance. BootLoop Test: From zero to CI in under 30 minutes (Source: BootLoop) To understand why this matters, consider the current state of hardware-in-the-loop (HIL) testing. The most sophisticated hardware companies have long relied on HIL environments to validate their products. Unfortunately, creating and maintaining these environments often requires months of specialized work. As a result, many engineering teams continue to rely on manual bench testing, collections of one-off scripts, and procedures that exist only inside the heads of a handful of experienced engineers. BootLoop’s ambition is to make enterprise-grade HIL testing as easy to deploy and scale as modern continuous integration (CI) systems. At the heart of the approach is the same hardware understanding that powers the BootLoop Develop product. Because the platform already understands the schematic, signal paths, peripherals, register maps, and their relationships, it can reason about the hardware in a surprisingly sophisticated fashion. If a peripheral fails to initialize correctly, for example, the system can inspect debugger information, interact with GDB (GNU Debugger), examine register contents, monitor serial interfaces, and correlate those observations with its knowledge of