Why do you need automated firmware builds (sometimes called a Continuous Integration (CI) pipeline) for your embedded project?
Oftentimes we have found that customers do not trust their firmware release process because their firmware builds require some tribal knowledge. It can be a challenge to set up machines to produce consistent builds across an entire team, and may even require expensive dongles to get working. Occasionally there’s a build machine in the corner of the room which can help, but is still less than ideal. A CI pipeline automatically compiles, analyzes, and tests releases, while allowing output files and reports to be distributed accordingly. All of this can be triggered simply without user intervention when code changes are pushed to the source control provider.
Ways to set up an embedded CI pipeline
YAML file
Most existing CI tools require some kind of YAML config file to kick off the CI pipeline. If you have your repository on GitLab, you can get started with GitLabs’ built-in CI pipeline by adding a .gitlab-ci.yml file in your repository. Next you will need a Gitlab Runner which is an application used by GitLab to process builds. If you instead use Bitbucket, they also have built in CI/CD pipelines that you may leverage. You will just need to include a bitbucket-pipelines.yml file in your repository and set up a Runner application.
Docker image
By adopting Docker image in your CI workflow, in other words, using the image in the YAML file, it creates an environment for you to build your firmware. In the Docker container, you can install the compiler, run make, etc. This allows for you to build your firmware, create and save the output as an artifact that you can use to flash your device consistently across multiple different host machines. On Docker hub, you can find some existing Docker images with a compiler installed such as gcc:latest.
Remote Virtual Machines
Now, for a more complicated scenario. Picture your repository is hosted on Bitbucket and it is an IAR based project. You have engineers working remotely from all over the world. IAR Embedded Workbench only runs on Windows which would add additional complexity when installing the IAR Embedded Workbench in a Docker container. Not to mention IAR licenses are expensive!
So how can we get around these constraints? One option is to leverage virtual machines like those available on Amazon EC2. For the CI Runner, BitBucket offers self-hosted runner applications that may be installed on many windows environments. Once you have a valid Windows instance and Runner setup, you just need an IAR license installed and you will be ready to start using your new pipeline. Just don’t forget to include a .gitlab-ci.yml file in your repository!
Summary
While setting up a CI pipeline can be time consuming and frustrating, the benefits can be seen almost immediately! No more worrying about differences between build machines, no more reliance on tribal knowledge, and peace of mind from continuous testing across releases. If you need help getting started with your CI pipeline, we would love to hear from you! You can book a call with us to start the conversation. We have tools and experience to help you along the way.
