Checklist to get embedded software quality right from start

For embedded software developers to build quality embedded software, they must get things right the first time. The checklist below is intended to help developers to kick-off their embedded software implementation phase correctly, from the beginning and with quality in mind. (The checklist can also be downloaded in a more usable form from here).

Phase 1—Project Setup

Setup Revision control

Create the project

Create the project directory structure

White Space config/setup

The first phase in project setup may look trivial but contains very critical steps to getting the quality ball rolling. Setting up a revision control system should be done first, NOT when the software reaches a complexity level that developers start to lose track of the code. Another aspect that is often neglected is setting up the white and tab spacing for the project editor. Many developers have their own preferences on IDE so in order to ensure that source files remain formatted properly, the white space needs to be set consistently across all environments.

Phase 2 – Configuration

Doxy Templates and tool setup

Import skeleton HAL/API templates

Version Log

Hardware configuration

Once the project environment is set up, developers should create a base version so that they can track changes to the code base from the beginning. Version logs are often last on a developers list but to properly capture changes the version log should be created first. Hardware will often change multiple times throughout the development cycle from development kit hardware through alpha and beta releases. The hardware configuration file can be used to to conditionally compile and adjust the code base for the target hardware.

Developers who are configuring their project should also consider using source and header templates. Embedded software should have a consistent look and feel and be well documented. Doxygen based templates can provide that look and feel in addition to providing the ability to automatically generate a manual for the software. For sample Doxygen templates for use within an embedded software project click here. An example skeleton hardware abstraction layer (HAL) for a GPIO peripheral can be found here.

Phase 3 – Code Analysis

Setup a static analysis tool

Setup Code Metrics

Dynamic code analysis (if the tool is available to you)

Many developers and teams are fairly bad at performing code analysis or metric measurements until it has gotten too late in the project. Setting up static and dynamic code analysis early in the development cycle will help developers catch potential issues and verify compliance to coding standards as they develop code, rather than at the very end. Analysis and metric tools—if used early—can decrease bugs and help developers discover problems as they occur, before they build up into a large and unmanageable number.

Phase 4 – Scheduler Setup

Setup RTOS or bare metal scheduler

Requires setting up a system timer/driver

Create a single task to blink an LED as an indicator

Nearly every embedded system has a scheduler driving the system. The scheduler can range from a simple bare-metal scheduler such as the one located here or be a full blown real-time operating system (RTOS). In order to decide which makes the most sense for the application, developers may want to read "Do you need an RTOS? Yes and here are 7 reasons why". Once the scheduler is in place, creating a task that can blink an LED at a periodic rate is a great way to have the embedded system say "Hello World."

Phase 5 – Setup Debug Messages

Setup debug messages

RTT through debugger

UART driver

Printf setup or equivalent RTT

Configure assert

Many developers wait to set up debug messages or real-time trace until a problem is discovered with the software's behaviour. Waiting for a problem to be discovered is far too late! Catching potential bugs, timing issues or other problems are far easier to fix if they are discovered when they first occur in the system rather than weeks or months later. Setting up debugging and trace capabilities and messaging through printf or RTT should therefore top priority, before any application code is ever written.

Phase 6–Begin Development

Only after the tasks in the first five phases are completed should developers consider starting application software development. Certainly, depending on the team, there may be additions to this checklist. The list contained in this article provides a minimum task set that developers should work through in order to begin the development process successfully. Obviously quality software won't write itself and developers will need to be disciplined and use the tools that they set up.

-Jacob Beningo