Continuous Integration

From SEGGER Wiki
Revision as of 15:00, 20 October 2023 by BiancaS (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Continuous Integration (CI) is a practice in modern software development that involves frequently integrating code changes from multiple developers into a shared repository and serves as a cornerstone of efficient and collaborative software development.

Key principles of Continuous Integration

The core principles of Continuous Integration can be summarized as follows:

Continuous-Integration 01.svg
  • Frequent code integration: CI emphasizes the importance of regularly merging code changes into a central codebase. Developers commit their changes to a shared repository, and these changes are integrated into the main codebase, usually several times a day.
  • Early bug detection: The primary goal of CI is to detect integration issues and bugs as early as possible in the development process. Automated testing and build processes are used to ensure that code changes do not introduce new defects.
  • Automation: CI relies on automation tools and systems to streamline the process of code compilation, unit testing, and reporting. Popular CI tools such as Jenkins, Travis CI, and CircleCI are often used to automate these tasks.

Continuous Integration on embedded systems

Embedded software development requires rigorous testing methodologies to ensure the reliability and functionality of software running on specialized hardware. In this context, two primary approaches are commonly employed for unit testing, regression testing, and reporting.

Simulation-based testing

One approach to testing embedded software is simulation-based testing. This method involves running the software in a simulated environment on a computer, which emulates the processor and, if necessary, the peripherals or components of the target product. Test applications are loaded into the simulation, allowing for controlled execution and reporting of test results.

However, this approach has its limitations. The accuracy of the results depends on how closely the simulation replicates the actual product. In essence, the quality of the simulation determines the reliability of the testing outcomes. It is important to note that simulating hardware components can be challenging and often requires significant effort.

Hardware-based testing

The second approach is hardware-based testing, where the software is loaded onto the actual target hardware. This is achieved using a debug probe, such as the J-Link, connected to the product. Test applications are then executed on the hardware, with results (such as OK or not OK) and test details reported through the debug interface.

Testing on real hardware offers the advantage of testing in an environment that closely resembles the actual product.

Advantages of J-Link PRO PoE for hardware-based testing

Hardware testing may be slower than simulation-based testing, and it might require dividing tests into multiple runs due to hardware limitations. However, the J-Link PRO PoE offers several advantages for hardware testing:

Test farm using several J-Link PRO PoE devices
  • Parallel testing: Hardware tests can be time-consuming, and sometimes it is necessary to run multiple tests simultaneously. Both the J-Link PRO and the J-Link PRO PoE allow users to control numerous J-Links from a single test machine, which can be particularly beneficial in setups with many tests (from a few up to thousands of test units).
  • Remote control: Hardware testing setups can be complex, taking up valuable space. The J-Link PRO PoE and J-Link PRO can be connected to the network via Ethernet, enabling remote control. This means that a "test lab" can be set up in a dedicated location, and developers can initiate and monitor tests from their individual workstations.
  • Power management: For certain tests, it is essential that the hardware starts from an off state. It is also a good idea to turn power off when no tests are running. The J-Link PRO PoE features a switchable USB output. This can either directly supply power to the hardware or connect to a switching relay, allowing external control of the hardware's power. This feature enables developers to power cycle the hardware from the computer running the tests.
  • Simplified power supply: Setting up a test environment typically requires connecting the J-Link to the network and providing power to both the J-Link and the target hardware. With Power-over-Ethernet (PoE), the power supply is integrated into the network cable. If the hardware can be powered through USB, this reduces the need for multiple external cables, resulting in a neater and more efficient setup.

In summary, when testing embedded software, developers have the option to use simulation-based testing or hardware-based testing. The choice between these approaches may depend on factors like the accuracy of the simulation, the need for realistic hardware testing, and the advantages offered by specialized tools such as the J-Link PRO PoE. These debug probes facilitate efficient and flexible testing of embedded software on real hardware while addressing power management and remote control needs.