eSOL Blog

Overcoming Major Challenges of Continuous Integration (CI) in Embedded Software Development

May 12, 2023 5:00:00 PM


Software development must respond flexibly and quickly to ever-changing social conditions and requirements while reducing development costs, improving efficiency, and ensuring quality.
To meet this, the introduction of continuous integration (CI), which automates testing, is standard in cloud-based software development.
But there are many challenges in implementing CI in embedded software development. 
This article presents some of the eSOL product development team's efforts to overcome these challenges.
By combining eSOL's open-source CI tool, version control tool, and eDEVS®, an IDE (Integrated Development Environment) to run CI, we were able to reduce the man-days required for testing by 400 hours per month and complete tests in one day instead of 20 days. As a result, we have significantly reduced man-days for product development.

How was this possible?

Three Challenges Preventing CI Implementation

The eSOL product development team faced three main challenges, each of which required a solution.

1. Automatic operation of development hardware

The first problem is that many IDEs for embedded software development do not support command-line based operations (CLI) and thus do not allow automated operations with CI tools.
eDEVS, an integrated development environment (IDE) for eSOL's RTOS platform, eMCOS, supports CLI so that it could be easily and quickly integrated with CI tools. eDEVS supports the GDB (GNU Project Debugger) standard, which enables automated debugging with CLI. The complete CI environment is realized by combining eDEVS with open source CI tools.


2. Automatic target board operation

The second problem is that the embedded software developer has to operate the target board manually, e.g., to update the test image and reset the target board. 
These operations can be done automatically with a special eDEVS function: The Host File System of eSOL (HFS) is used to update the test image in this case. The HFS allows a specific folder on the host PC to be treated in the same way as a physical storage medium on the target board, e.g., an SD card. In this case, the target board can freely access a specific folder on the host PC. By instructing the CI tool to store the created test images in a folder designated as HFS on the host PC, the test images can be updated without having to manually manipulate the target board.
Especially the debug probe is used to reset the target board. By setting the target board to be initialized via the debug probe from eDEVS prior to test execution, manual operation of the target board is also not required here.

We mention "especially" because there are target boards which cannot be initialized by the debug-probe due to their hardware configuration. When using such hardware, the initialization must be done by modifying the board. For example, the signal line required for the reset can be externally added out and connected to another control board. This control board can then be operated via a serial network communication from a PC connected to the network, and thus the reset of the target board can be performed via the network.

3. Lack of physical development equipment

The third problem is a lack of development hardware.
CI tools can run multiple tests simultaneously, but they also require the target system for each test run. Due to the global shortage of semiconductors, the lack of target boards has become an even tighter bottleneck than it was before the shortage. To address this bottleneck, eSOL uses target hardware simulators such as the open-source QEMU simulator and Arm FVP (Arm Fixed Virtual Platform). In particular, Arm FVP allows full, and very cycle-accurate simulation of an Arm system of CPU, peripherals, and all memories, including cashes.
A virtual Ethernet IP is also available for Arm FVP. Combined with eDEVS’ HFS functionality mentioned earlier, this allows the basic hardware functions needed for media access, network access and platform development to be implemented virtually.
This virtual environment allows multiple testing independent of real target boards.


By overcoming these three challenges, eSOL's product development team has converted about 90% of all system testing to continuous integration.
As a result, the number of man-days required to run tests has decreased, and the many daily system tests have allowed us to catch bugs much earlier, reducing rework and saving huge costs.
But the automation and development efficiency of a CI pipeline remains a task that requires continuous improvement. In the future, we will improve the automation/development efficiency through CI for system testing, as well as extend bug detection and direct notification to the appropriate development team.
At eSOL, this competence is also made available to our customers as an engineering service, so that they can also use our products in their CI pipeline and reap the benefits. For more information on CI implementation and eDEVS, please contact eSOL.

Click here for an overview of eDEVS

Click here for eSOL’s engineering services
Contact us

Marketing Communications Team