What is an IDE?

Writing embedded software for other architectures than our host usually requires a lot of different tools.
The tools used for a specific project can be grouped together and they form a Development Environment. To make it simpler to work with these tools, they are typically bundled together into an IDE (Integrated Development Environment).

Frequent problems

If you used IDEs before, you probably faced at least some of the following problems:

• The error-prone and time-consuming setup process
• Tools are hardcoded into IDEs
• More instances of the same tool
• Difficult IDE and tool version management
• The IDEs enforce the use of their UI

Join our community

Tooling, development environments, best practices in embedded development platforms, and all things that empower us to create exceptional embedded systems.

Join XM

One of the biggest disadvantages of IDEs

From the list above the second is a crucial problem if you want to create a well-managed infrastructure. When working with IDEs, you cannot easily use the underlying integrated tools separately. They usually depend on the IDE or each other, so standalone usage can be problematic and the whole IDE installation is required.

Problem #1: When navigating multiple projects

Let's say at your company the developers have to work on different projects simultaneously, switching between tools even daily.
If they want to keep all the needed tools on their PCs at the same time, more issues can occur:

• A lot of duplications - storage-consuming
• Tools can interfere
• Version management of the tools is crazy

Re-installing an IDE every time to switch tools is time-consuming and let's face it: most developers don't like operational tasks.
To avoid the re-installation of whole IDEs somehow we have to reduce the dependencies between the tools and provide the possibility of standalone usage.

Problem #2: "It works on MY PC!"

Even if you are not project-based, you probably heard your co-worker say, "I don't know what's wrong with your installation. It works on my PC!"

When setting up your Development Environment the process is unpredictable. Two of the annoying scenarios:

• Everything works smoothly on the first try. (But you already sense something will go wrong and the worst is you don't even see what. You start praying to the gods of tech.)
• Random errors during development. It can be painful to discover after days of debugging that an environment variable had a different value for some obscure reason.

Isolating tools: Containerization

To eliminate these problems, the tools need to operate in their own isolated environments. A lightweight and fast solution for isolation is containerization.
A container is a completely isolated hosting environment, specifically tailored for the needs of the application it runs. The tools get built into their respective container images, and the way they communicate with the host system can be controlled. Containerization also ensures there is no interference between the tools. With this concept, consistent and scalable customized Development Environments can be built easily.

Virtual Machine vs. Container

To understand the containerization concept it can be useful to compare it to the well-known virtual machines:

• A VM runs as a standalone OS on top of the host OS
• The container uses the shared resources of the host OS
• Different lifetime: a VM is persistent, a container only exists while needed

Unveiling the Advantages

Now that we have all the tools in containers on our PC, after setting up the communication between them we have an optimized Development Environment. The advantages of an optimized DevEnv:

• Easy and quick setup process
• Tools are not hardcoded into IDEs anymore, standalone usage is possible
• Keeping one instance of a tool is enough
• The same tool with different versions can be present on our host
• The developer is free to choose her favorite editor
• No interference between the tools
• Communication between the tool and the host can be controlled

Containerization gives flexibility, portability, reproducibility, and scalability to embedded software development and is a key when creating optimized Development Environments.

A little extra: Optimized Hybrid Development Environment

What is a Hybrid Development Environment?

We call a Development Environment Hybrid when the tools part of the DevEnv are not running in the same place. For example, a debugger is running on an SBC, or a build system is running in a cloud environment.

Containerization in a Hybrid Development Environment

After creating an optimized Development Environment, it's worth checking what other benefits can containerization bring to the table.
By combining a Hybrid DevEnv with containerization the following environment can be built easily:

In this case, the client side of the chosen editor is running on the developer's PC, while the editor's server side, the build system, and the toolchain are deployed in the cloud. The project also has a Debugger or Flasher running on an SBC, depending on the state of development.

This example makes one of the greatest advantages of containerization clear: Containerized tools can move across physical and cloud environments easily. As the embedded development landscape continues to evolve, containerization is likely to become an even more significant player in enabling efficient and effective development practices for embedded systems.