Ultimate Embedded Firmware DevOps Infrastructure

This training helps you implement continuous delivery process for your firmware.

In a way, it is also a comprehensive “Zephyr RTOS Getting Started Guide”.

How is this different from existing getting started guide provided by Zephyr? It is aimed at your custom firmware application development in a custom repository outside of Zephyr – while zephyr guide focusing on getting started working ON zephyr – which is not what you are doing every day. So it’s a big difference in focus in this guide.

What is included

The training is divided into 6 parts:

• Overview – a quick overview of the course – similar to this page.

• Setting up repository – here we start from scratch and I show you how to configure the repository correctly.

• Setting up GitLab CI – here we create a basic CI pipeline for our firmware repository that will allow us to run the whole build process automatically.

• Directory Structure – we create a comprehensive directory structure that can accommodate for everything we may add to our project later.

• Documentation Generation – here we add a documentation generator form Zephyr that will generate good looking reference manual for our project.

• Test Infrastructure – here we build out an automated test infrastructure using renode and CMock.

• Release Generation – here we generate a release with all files included – docs, software bill of materials and firmware.

Setting up repository

In this section we set up a basic repository from scratch. The advantage of doing this from scratch is that you get to learn how the whole repository is set up. While we are following a similar setup to Zephyr, we are not starting with an already set up repository. Instead we start from zero.

In this section the following topics are covered:

• Adding the first robot framework scripts that will serve as the “definition of done” for this step.

• Adding the required files: CMake files, Kconfig files, CODEOWNERS, gitignore etc.

• Adding a pre-commit hook that will run checks on changed files before each commit.

• Adding a repository init script that will set up local repository and system after a checkout.

Setting up GitLab CI

Once the repository has been set up, we now need to configure gitlab so that we can move over to working with merge requests. To do this, we do the following:

• Configure a CI pipeline through .gitlab-ci.yml

• Create a proper task template (for creating tasks in gitlab)

• Build docker images so that we can run the pipeline locally through gitlab-runner.

• Add merge request template

• Configure repository for trunk based development.

• Add check to ensure that merge request title contains clickable reference to ticket being solved.

• Add zephyr compliance checking scripts – so that you can verify content of a merge request before merging it.

Directory Structure

Once we have a gitlab pipeline working, we can now work through merge requests and in this step we add the rest of the directory structure.

This includes:

• Adding an example application – so that you have a template to work from.

• Adding a custom board – so that we can build the application for custom hardware.

• Adding cmake library directory – this will be the place where we later put cmake helper scripts.

• Adding an example device driver – so that we have a template for device driver directories.

• Adding documentation folder – we will add docs to it later.

• Adding global include directory – for public interfaces of libraries and drivers visible across the whole firmware project.

• Adding an example library – so that we have a way of adding libraries shared between multiple applications.

• Adding example samples – so we can later boot them in renode to run user stories.

Documentation Generation

Once the full directory structure is in place it’s time to add documentation generation. In this module we adopt Zephyr documentation generator so that it works in an external repository – such as the repository where we have our firmware code.

This involves:

• Moving the doc generator and adopting scripts so they build docs for our project.

• Adding robot framework scripts for verifying chapter structure – so that we can ensure that docs follow roughly the same structure.

• Linking the docs together so that we can generate a single PDF or HTML output.

• Adding doc build process to CI and making everything pass all CI checks that we have setup earlier.

Test Infrastructure

In this section we focus on testing. There are three main types of tests that we need to add – unit, integration and system tests. Zephyr only has support for integration tests and a limited support for unit tests – so we have to add this. System tests are designed to take to final firmware, run it in a simulator (we will use renode in this training) and run user scenarios against it – this verifies the integrity of the whole system.

• Adding unity – so that we can ditch ZTest and use a standardized testing framework.

• Adding CMock – so that we can mock any function in our unit tests and have the ability to verify our code for logical integrity.

• Adding renode support – so that we can simulate our firmware through renode and write scenarios in robot framework syntax.

• Code coverage checking – so that we don’t allow any source file to be merged unless it has been fully tested.