Continuous Integration CI
Continuous Integration CI for embedded
Automated builds and tests have become an integral part of modern software development. Continuous Integration - or in short CI - is also becoming more and more popular in the embedded field.
When you start the video, content is loaded from Youtube and thereby your IP address is transmitted to YouTube.
A “rapid feedback loop”
Every single time a developer integrates a code change into the version control system a fast and highly automated series of steps - a so-called pipeline - is triggered. Typical steps can be Build, Static Analysis, Unit and System testing (see image below).
After each pipeline run, a qualified statement is available on how the change has affected the state and quality of the software. Within minutes, it is clear to the developer whether the pipeline run has been completed successfully.
If the pipeline fails since for example the build is broken, test cases fail or important metrics are not met, rework is necessary. Errors and faults are detected early and can be fixed quickly which is time- and cost-saving. Implemented the right way, CI can be a real productivity booster for software development.
Hardware in CI infrastructure
Although extensive tests can be executed independently from the target hardware, there will be a point in time when the software has to run on the target hardware. Stubbed or simulated environments cannot cover all the potential pitfalls: hardware peripherals are not available or don’t behave similar to the real hardware, the timing behavior is different, the cross-compiler generates target specific code and thus not the same code than the compiler that is used for the test environment and so forth. This is why it is reasonable to start with testing on the target hardware already in early phases.
“Get the most out of your targets”
Working with embedded targets is always accompanied with some challenges: Limited availability of the latest hardware, evaluation boards and related tools like debuggers are rare goods, and can be damaged quite easily.
A solution can be a setup of dedicated hardware test racks. iC5700 CI and iC5000 CI BlueBoxes are accessible via USB and Ethernet. That allows shared access scenarios: Targets are located in an appropriate environment and available 24/7 from all around the globe. Engineers can access them for development purposes and manual tests, the CI Infrastructure is able to execute commit - or time-triggered (like nightly) pipeline runs.
Hardware debugger - a powerful testing tool
Testing with winIDEA
Complex test cases can be directly performed via winIDEA by using the flexible and extensive iSYSTEM isystem.connect SDK to implement the tests. Since debugging tools have full control over the target, it is possible to directly stimulate APIs and verify certain conditions during runtime. It is possible to manipulate parameters and variables and thus force error scenarios via fault injection.
With this approach, on-target tests can be performed on different levels without the need of any test code or test instrumentation on the target-side (non-intrusive testing).
Integration in third party tools
isystem.connect SDK offers the ideal solution to give third-party or inhouse developed testing tools access and control over the hardware and thus allow on-target test execution. Optimized algorithms ensure high-performance and lifetime-preserving (e.g., reducing flash wear-out) target downloads. The execution of selected test cases can be controlled and test results can be acquired and provided for further processing.
How does a code change affect the performance of the application?
What impact does a module have on the runtime behavior of the system?
Since applications are becoming more and more complex and controllers get maxed out to their limit, it is necessary to deal with such questions. With the implementation of automated timing analysis, it is easy to verify timing constraints and keep an eye on important timing metrics over the evolution of the software. Bottlenecks can be detected at an early stage and if necessary, corrective measures can be initiated. Using tracing technology also allows the non-intrusive measurement of code coverage. Instrumentation code that will affect the runtime-behavior is not required.
IOM6 Add-on modules
With the iSYSTEM IOM6 product line, where all products are also fully controllable via the iSYSTEM isystem.connect SDK, it is possible to greatly expand the range of applications in the CI environment.
With the IOM6 CAN/LIN accessory it is possible to analyze the communication on busses in detail and in parallel to the software. The IOM6 ADIO accessory module can analyze the signals of the microcontroller’s output pins and stimulate the input pins.