My head hurts. As usual, I’ve been floundering around in embedded space (where no one can hear you scream). And as a result, I’ve been introduced to something with so many possibilities and potentialities that I don’t know whether I’m coming or going or doing something else entirely.
I was just chatting with Rolf Segger, the Founder, Owner, and Chief Strategist, and Dirk Akemann, the Partnership Marketing Manager at SEGGER Microcontroller Systems.. Rolf and Dirk were bringing me up to date on their latest and greatest offering, a virtualization tool called emApps, but before we dive into the fray with gusto and abandon, let’s first set the scene…
Let’s start with the fact that SEGGER is an interesting company in more ways than one. For example, it’s a name known to just about anyone who dips their toes into the embedded systems waters. At the same time, many embedded systems developers who use one or more of SEGGER’s tools every day manage to remain blissfully unaware of the range of the company’s offerings.
SEGGER was founded in Germany in 1992 with a focus on embedded software and tooling. From the outset, the company adopted a very pragmatic philosophy: solve real problems for embedded developers, then do it reliably and efficiently. At that time, embedded systems were deeply resource-constrained and tooling was often an afterthought, conditions that strongly influenced the company’s problem-driven approach. SEGGER’s first product was a real-time operating system (RTOS) that is now known as embOS, and they have myriad other offerings on the embedded software side.
Having said this, if you ask many embedded engineers what comes to mind when they hear the name SEGGER, it’s two of the company’s hardware products that tend to dominate the conversation: J-Link and Flasher. Together, these “bookend” the embedded lifecycle, with J-Link anchoring development and debugging, and Flasher underpinning reliable, repeatable production programming.
J-Link connects your PC (IDE, debugger, CLI tools) to your target processor. It lets you download code, single-step through instructions, set breakpoints, inspect registers and memory, and trace execution (on supported models). J-Link supports SWD and JTAG, works with virtually all major IDEs (Keil, IAR, STM32CubeIDE, Eclipse, VS Code, PlatformIO, Arduino), and offers excellent command-line tools for scripting.
Unlike J-Link, which is primarily a PC-connected debugging tool, Flasher is designed to operate as a self-contained programmer. Firmware images are preloaded into the Flasher via USB or Ethernet, after which it can be used independently of a host computer. In production or field use, the workflow is deliberately simple: connect the Flasher to the target, press a button (or trigger it remotely), and the device programs and verifies the target automatically. Flashers support a wide range of targets, including microcontrollers (MCUs), application processors (APs), SoCs, FPGAs, and external SPI flash devices. This autonomy makes Flashers particularly well-suited to manufacturing lines, automated test stations, and field-update scenarios, where repeatability, reliability, and freedom from PCs are essential.
Now let’s return to SEGGER emApps. This is a tiny, efficient framework that transforms any embedded device into a flexible platform, enabling developers to deploy new features as “apps” without compromising the core system’s stability.
I distinctly remember telling Rolf and Dirk that their job was to make me look clever. I acknowledged that this would be something of an uphill battle, while assuring them that I was confident they were up to the task. However, I fear they failed because I still don’t feel as though I have a clue.
Rolf and Dirk started by presenting a high-level approach to visualizing emApps, comparing it to apps on today’s smartphones, as illustrated below.
Comparing cell phones pre/post apps (left) with embedded systems pre/post emApps (right) (Source: SEGGER)
Around the turn of the millennium (it still feels strange saying that), mobile phones were, by modern standards, remarkably static devices. You could make calls and send text messages, and that was about it. The software was tightly coupled to the hardware, typically fixed at the factory, and any meaningful change required a full firmware update, which rarely (if ever) occurred. Phones did what they did (if you were lucky), and that was that.
Then, in 2007, Apple unveiled the iPhone, and with it a radically different model. For the first time, a mass-market phone behaved like a “platform.” You could download new applications (apps) long after you’d bought the device, install them in seconds, and start using them immediately, all without the necessity to recompile, reflash, or reboot the entire system.
Crucially, these apps were “sandboxed,” meaning each ran in its own protected environment, with clearly defined boundaries that prevented it from interfering with the operating system or with other apps. If an app misbehaved or crashed, it failed in isolation rather than bringing the whole system down. This separation made phones both safer and more stable, while giving developers the freedom to innovate without fear of catastrophic side effects.
The combination was transformative. Phones were no longer closed appliances; they became continuously evolving devices whose capabilities could grow over time. That shift—from monolithic, fixed-function firmware to downloadable, isolated applications—didn’t just change mobile phones. It reset expectations as to how modern computing systems should work.
Well, emApps does much the same for embedded systems. Phew! Explaining that was a lot easier than I expected.
What? You want more? Give me strength. I’m too young for all this excitement! Well, if you insist, let’s take another look at the image above. In the case of embedded systems, we can visualize the old way of doing things (i.e., without emApps) as being a big “blob” of firmware (I hope I’m not getting too technical). By comparison, we can visualize the new way of doing things (i.e., with emApps) as a lean, mean, well-defined firmware core hosting a collection of small, sandboxed apps, each one downloadable, replaceable, and free to evolve independently—much like the apps on a modern smartphone.
SEGGER’s emApps applies that same app-centric model to embedded systems—but at a scale and efficiency that makes sense for microcontrollers. At its core, emApps is a lightweight application platform built around a tiny virtual CPU, explicitly designed for deeply embedded environments.
Applications are written in standard C and compiled—not for the underlying hardware—but for SEGGER’s virtual processor. This virtual CPU is implemented in portable C, making it remarkably easy to integrate into existing firmware projects and inherently transferable across architectures, whether the host MCU is Arm, RISC-V, or something else entirely.
The footprint is intentionally small. The virtual CPU and executor can run in roughly 2–3 KB of flash, and simple applications can be well under 100 bytes in size, which is orders of magnitude smaller than alternatives like Java or WebAssembly, which were never designed for such constrained systems.
Once compiled, emApps apps (if you see what I mean) can be loaded dynamically into RAM (or stored in flash for persistence) without reflashing or recompiling the main firmware, which simply loads the app and invokes it via a defined entry point. This means new functionality can be added, tested, or removed without retesting the entire system firmware, which is a huge advantage for production systems and certified designs.
Crucially, each app runs in a sandboxed environment. Memory access is tightly controlled, and any attempt at illegal access immediately halts the offending app without affecting the rest of the system. Apps cannot interfere with one another or with the core firmware unless explicitly allowed via a controlled API table—very much like permissions on a smartphone.
Although emApps is a general-purpose embedded technology, it has already been battle-tested inside SEGGER products, most notably within Flasher production programmers. There, emApps originated as a means to implement device-specific flash loaders and time-critical operations without bloating firmware or requiring constant updates. Over time, the folks at SEGGER realized that this same mechanism could also be used for testing, diagnostics, protocol handling, user customization, and—ultimately—to implement any embedded product.
What began as an internal solution for programming tools has now emerged as a broader architectural concept: treating embedded devices as platforms that can safely run apps, rather than as fixed-function appliances.
A few years ago, in 2021, I wrote about Luos, a distributed embedded framework that allowed application modules to discover and call each other across multiple microcontrollers (see New Paradigms for Implementing, Monitoring, and Debugging Embedded Systems). At the time, this technology felt genuinely radical. In hindsight (the one exact science), it was an early glimpse of where embedded software was heading.
Sad to relate, Luos is no longer with us; the company officially closed its doors in early 2023 after failing to secure further funding. I have to say that I loved their technology. The core challenge was that Luos was, to a large extent, a solution still searching for its killer application.
By contrast, as with many SEGGER offerings, emApps started life as an internal engineering solution designed to solve very real, practical problems. Only later did the team step back and realize they’d created something with much broader appeal. That realization carries extra weight when it comes from a company with an enviable, multi-decade track record of delivering—and sustaining—what ultimately becomes de facto standard hardware and software solutions throughout the embedded industry.
Now, all that remains is for me to close this column in an unexpected way. Rolf and Dirk kindly offered to send me a Flasher and access to emApps so I could explore the technology hands-on. Of course, if I’d actually managed to make it to work, that would have been unexpected.
I explained that I’m a hardware design engineer by trade, and that I wouldn’t be able to do the system justice, but I asked if we could send one to a knowledgeable embedded systems developer friend who could then tell me all about his experiences with it. I was thinking about Jacob Beningo, who is President of the Beningo Group.
Do you remember this scene in Monty Python and the Holy Grail when King Arthur says to the French taunter, “Tell your master he can join us in our quest for the Holy Grail,” and the taunter responds, “Well, I’ll ask him, but I don’t think he’ll be very keen. He’s already got one, you see.”
The reason I mention this is that I called Jacob and asked if he would be interested in this bodacious beauty, and he replied, “I’ve already got one.” I should have guessed that the folks at SEGGER would already have beaten me to the punch by equipping the embedded world’s resident sages. Oh well, “Great minds…” and all that.
What say you? Do you have any thoughts you’d care to share on anything you’ve read here? As always, I welcome your cunning comments, insightful questions, and thought-provoking suggestions.
