What’s Cooking at SEGGER: Introducing Embedded Apps

In today’s fast-paced world of embedded systems, flexibility and adaptability are key. That’s why we’re excited to unveil our latest innovation at SEGGER:
Embedded apps, similar to the ones on your phone (only less visible and much smaller), running on your embedded system.

Apps are small, dynamic pieces of software that can be linked to your device’s firmware, either statically or dynamically. Typically, they’re dynamically linked, which means you can download and add them to your existing firmware at any time.
SEGGER apps are executed by a small and highly optimized piece of code in the firmware, the executor, which basically implements the instruction set of the virtual CPU. This capability extends your device’s functionality, making it more versatile and adaptable to new needs and updates. Essentially, apps allow you to turn your embedded device into an embedded platform!

One of the standout features of SEGGER apps is that they are sandboxed. In other words, they run in a protected environment where the underlying operating system can monitor their behavior. If an app tries to do something it shouldn’t, the executor suspends execution of the app and returns to the firmware (the caller), which can now decide how to deal with this situation. No harm is done. This ensures that even if something goes wrong within the app, the rest of your system remains stable and secure.

Basic concept


Things are a bit hard to visualize, but we tried … The executor and the sandbox with API functions need to be added to your firmware and your device is ready to execute Apps. To add functionality to the apps, API functions can be added. So to add read access to a file system, one would typically add 3 functions like OpenFile, ReadFile, CloseFile. To allow write access, a WriteFile would be added.
How apps are loaded and in what context / thread they are executed is up to the firmware designer.

Multiple apps can run simultaneously, whether on the same core or different cores, all under the control of a real-time operating system (RTOS). Any RTOS can do, as the executor is called by the firmware, which runs under the RTOS (should your firmware use one).
Each app can have its own memory space. Should an app encounter an issue (crash…), it won’t affect system stability, similar to a crashing app on your phone or desktop not affecting the system. This can allow apps to even run in safety critical environments; it can even make it easier to certify a critical system as peripheral functionality (such as the control of a display) can be shifted into an app which then does not need to be part of the certification process.

Memory requirements

Too big for your system..? Think again!
Not only do these apps enhance flexibility, but their memory consumption is also minimal. The executor, which is part of the embedded firmware, typically requires between 600 and 1000 bytes. We have an ARM optimized version as well as portable C version which runs on pretty much anything, including a PC to allow a simulation. The firmware provides API functions, which typically add between 1 and 3 KB, depending primarily on the native functions you want to expose to your apps.
This means emApps can run even on smaller systems (64KB Flash) without a hitch. The framework can easily be integrated into an existing firmware.

Code density

The code density of the virtual CPU that runs these apps is impressively high, often even higher than that of the host CPU, especially in RISC-V environments. This can even help save valuable program space, particularly when apps are statically built into the program!
We have our own C-compiler for this virtual CPU. Other languages such as Basic, Pascal, Phyton can be used by using a “To C” converter.

Memory protection – sandboxing

Apps can only use the memory space assigned by the firmware (the program the embedded system is running).
The firmware provides that memory for as long as the app is active. Any intent to access memory outside of this assigned memory space is intercepted, the executor returns and lets the caller (the firmware) decide how to handle this situation.

Performance

Apps are executor by a small and highly optimized piece of code in the firmware, the executor. The executor basically implements the instruction set of a virtual CPU, which we have optimized for this purpose:
This instruction set is very dense, so that the number of instructions executed by the virtual CPU is typically significantly lower than the number of instructions the host CPU would require for the same functionality, and it can be efficiently easily executed on any CPU. Combined with the ability to offload compute intense tasks to the host CPU, performance is typically very close to that of the host CPU.

How did we come up with this?

We’ve integrated this innovative approach into our J-Link and Flasher product lines, because we saw an need for it.

Programming apps can be created by us or 3rd parties, without having to recompile the firmware or sacrificing performance. Any required crypto code can be part of these apps (we have libs so they can easily be used). This way the firmware itself can stay small and “crypto free”.

Other Apps can program FPGAs or perform a post-production test of a programmed target system.

The future

We continue to integrate this into other products …

When it comes to J-Link, it will be possible to add support for new CPUs. This will be possible for anyone, even outside of SEGGER.
With a powerful API and 2 in-house designed single-cycle soft cores (“Speedy”) which can run at up to 200MHz, single cycle,
even tricky dual and single pin interfaces can be added not just other cores using JTAG, SWD or cJTAG.
In Flasher Hub, one example is a customer web server, which allows customizing the web user interface, adding new features or simply changing the language of the user interface to whatever is desired.

Once apps are available, new ideas spring to mind. Even software running on powerful host can benefit from emApps.
The fact that they run sandboxed, with a clearly defined API gives them advantages over regular plug-ins.

We see a future where many embedded applications across different industries can leverage this technology. With apps, you can extend functionality in a safe and controlled way, similar to how apps on a smartphone work. This approach not only enhances flexibility but also opens up opportunities for third-party developers to contribute to the ecosystem.

We’re thrilled to see how emApps will shape the future of embedded systems, and we can’t wait for you to experience the benefits they bring.
Stay tuned for more updates and get ready to explore a whole new world of possibilities with SEGGER’s emApps!

And if you are interested in using emApps in a commercial product and would like to know more, please contact us: info@segger.com

All the best from SEGGER, the Embedded Experts!