Maximizing efficiency

Creating an Optimized Development Environment beyond traditional IDEs

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).

Example: Tools bundled into an IDE Example: Tools bundled into an IDE

Frequent problems

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

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

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.

Tools used standalone, isolated in containers Tools used standalone, isolated in containers

Virtual Machine vs. Container

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

VM concept VM concept Container concept Container concept

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:

Example: A Hybrid Development Environment with containerized tools Example: A Hybrid Development Environment with containerized tools

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.

We need some cookies to make axem work. axem and our social media, advertising, analytics etc. partners would like to use additional cookies to store your preferences, gather statistics and assist with our marketing - this helps us improve axem. By clicking [Acccept all] you consent to the use of these cookies and you acknowledge that you read and understood our Cookie and Privacy Policy.

Read Privacy and Cookie Policy
Accept all Reject all