6

I come from an embedded world where we use C/C++ for programming, and use an IDE to generate a binary file, which is then programmed into a Hardware Board, which can then be tested.

With this background, what is a better workflow for automated builds than the current workflow of -build(using IDE)->Flash into the hardware->test. In other words, is there a way I can benefit from the advantages of CI in the domain that I operate in?

Vaibhav Garg
  • 427
  • 1
  • 4
  • 14
  • For an extreme embedded example, consider the software used to control a rocket. There a hardware test starts at 8 figures and hopefully winds up in orbit. It is worth putting in a ridiculous amount of effort into any techniques that might catch software bugs before that hardware test! – btilly Jun 22 '13 at 02:10
  • See this question for interesting ideas on how to write tests in embedded development: http://programmers.stackexchange.com/questions/119317/how-do-i-do-tdd-on-embedded-devices – makes Sep 18 '13 at 02:36

2 Answers2

2

For embedded software, Continuous Integration can be helpful

  • if you have (unit) tests that can be executed in a simulation environment, or
  • if you have a means to perform unattended updates of the target device and you can automatically trigger the tests (including their required stimuli).

In the first case, you can set-up a CI server that periodically creates a build for the simulation target and executes the tests on that simulated target automatically. In the second case, you would need to hook an actual target to the CI server and then periodically create a build and test it.

The advantage in both cases is that you get automated, unattended, regression tests that will tell you is you accidentally broke something, even if that is in a seemingly unrelated part of the software (which you thus would not have touched with your manual tests).

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
1

There are a gazillion good reasons to use CI in an embedded team (if you are working alone in your IDE, advantages of CI are less obvious, I in CI is integration and you aren't integrating with anyone when you are working alone)

  • It forces you to have a repeatable, scripted, automated build process. The output from your CI system is the output that gets tested and will be consistent. No matter what developpers install on their machine, the build will be unaffected.

  • The big advantage of CI is the ability to run automated unit tests. These test can be cross compiled to the CI machine platform. This has the architectural side effect of decoupling your hardware dependant logic from the rest, easing an eventual port to another platform and easing reuse of platform independent code to another project.

  • It will make sure that what everyone's commit into source control builds, and quickly give feedback when it doesn't. It really speeds up things to know which commit broke the build.

  • It will give the testing team a common place to get the latest version without any burden on the dev team. Or to quickly bissect a newfound bug that appeared since 2 weeks ago...

  • Automated code inspection, metrics and analysis tools can trigger warning on code that got checked in.

The usual workflow is usually to have the build products available on the server to be flashed on the board. In your everyday development, you use your IDE's build/flash workflow. I do not know about your project, but it is also possible to have an automated script to flash the new firmware on the actual board and then start/stop tests automatically on the board via a serial interface, for example.

Vincent Hubert
  • 209
  • 1
  • 4