Software startup checklist gives quality a head start
Building quality into embedded software doesn’t happen by accident. Quality must be built-in from the beginning. Below is a checklist embedded software developers can use to make sure they kick-off their embedded software implementation phase the right way, 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 behavior. 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.
What other tasks or software start-up items do you think should be added to the checklist?
Jacob Beningo is principal consultant at Beningo Engineering, an embedded software consulting company. Jacob has experience developing, reviewing and critiquing drivers, frameworks and application code for companies requiring robust and scalable firmware. Jacob is actively involved in improving the general understanding of embedded software development through workshops, webinars and blogging. Feel free to contact him at firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.