The size of embedded software is increasing every year; in fact, embedded systems contain significantly more software than only a couple of years ago. This expansion has resulted in new types of problems. The issue is no longer how to write individual lines of code; it is making a well thought-out design that is maintainable and how to manage ever-increasing code complexity and increasing development costs and delays, in addition to handling the issues of geographically separated project teams.
Almost all embedded software IDEs focus on the same tasks as 20 years ago: the traditional chain of editing, compiling and debugging lines of code. Until recently, the market has not been offered contemporary and up-to-date tool solutions that increase developer efficiency or team collaboration, or improve return on investment and software quality.
Additionally, it is increasingly important that developers move from being ‘code writers’ only, to being ‘software engineers’ and understand and practise the process of how to develop high-quality software.
Certainly, tools have improved over the past 20 years, but the improvements have largely been made in the traditional steps of editing, compiling and debugging: developers now expect editor features such as the expand/collapse of code blocks, spell checking of text in C/C++ comments, functions for visualisation and navigation of the code structure; embedded compilers handle C++ as well as C, and the code size is improved, even if this is less important in new powerful 32-bit devices; and debuggers are also improved, but still focus on code execution and inspection of variable values.
By looking at tool support from a wider perspective, development teams can address the problems that cost money, delay projects and cause companies to deliver low-quality software products. Modern C/C++ tools need to extend the traditional tasks with new features that provide support for design and documentation, team collaboration, traceability in code changes and better tools for improving quality.
This does not mean that the traditional features are not important; in fact they can also be improved.
New tools should be able to ease complexity management due to simplified navigation in large code bases. They need to support features such as colour-coded syntax (with real-time evaluation and visualisation of pre-processor expressions), folding (expand/collapse) of code blocks, parameter hints, symbol type assistance, content assist and code completion.
Potential features may also include: smart editing with configurable coding style, which works out code formatting including automatic indentation and spacing; and macro expansions that can be ‘single-stepped’ forward and backward to understand how multi-level macro definitions are expanded.
For compilation, an example tool, Atollic TrueSTUDIO, features an advanced build system with the optimising GNU C/C++ compiler and linker, and support application and library projects, which can be built in ‘managed’ or ‘makefile’ mode. TrueSTUDIO also includes two tool chains – one that targets the embedded microcontroller device and another that targets Windows-based PCs. This enables engineers to develop PC utilities that send configuration data to the embedded board, or log data from embedded boards without the need to purchase Microsoft VisualStudio.
TrueSTUDIO goes a step further and is one of the first development tools that can build project files in parallel, shortening build time dramatically in some cases. A parallel build is launched by spawning a number of assembler and compiler processes in parallel, each building one of the files in the project.
Figure 1 outlines the differences between traditional (sequential) and parallel building. It presents a simplified case, but it shows important conceptual differences. In general, parallel builds shorten build time, if projects contain many files, the build is done on a multi-core CPU, and disk I/O is relatively slow.
Parallel builds can also be of benefit on host computers without a multi-core CPU, as program execution and disk I/O can generally be done at least partly in parallel on modern operating systems, such as when compilation of one program is waiting for disk access, another compilation can use the processor.
Figure 2 shows how total build time can be reduced using parallel build also on a single-core CPU, as program execution and disk I/O do not need to wait for each other. The PC processor can be utilised for compilation to a higher degree. R is short for reading source code from the disk, C is for compiling, and W is for writing the compiled object file to disk.
New development tools will need to include a professional debugger with multi-processor debug capabilities, real-time tracing and support for all the expected features, such as simple and conditional code and data breakpoints, full execution control functions, memory and CPU register views and call-stack view. Tools should deliver advanced system analysis enabling in-depth monitoring during execution, for example, for ARM based microcontrollers with support for Serial Wire Viewer (SWV) real-time tracing.
A key ability is the support for multi-processor debugging, enabling the debug of several applications running on different processors, simultaneously in the same debugger. TrueSTUDIO allows any number and combination of embedded single- or multi-processor boards or Windows PC applications to be debugged simultaneously from the same GUI. This enables system-level debugging of two or more embedded boards communicating with each other, or system-level debugging of one or more PC applications communicating with one or more boards.
Embedded project requirements will change and code will need to be extended and modified. Developers may leave a project, and eventually no one will know how the code works or why, or when a change was made, or why it was made or what it looked like previously. A version control system is required – this is essentially a database containing all project files, including all previous versions and old versions of the project’s directory structure.
TrueSTUDIO includes a powerful GUI client for popular version control systems, and even auto-generates graphical charts that visualise the code activities – such as commits, branches/merges and labels/tags – that have been recorded in the version control system server.
Development teams also need to keep track of all feature requests, bug reports and to-do items. These issues are typically stored in a centralised issue management system on the team server, such as Trac or Bugzilla. This becomes the central point of all development activities and essentially becomes an activity tracker that is used as a work planning and prioritisation tool.
A modern C/C++ development tool should be able to connect to this server, and provide integrated features for listing, searching and editing of bug reports and feature requests from inside the C/C++ environment.
Error review, code analysis and test
Code reviews are considered to be one of the cheapest and best ways to improve software quality. Certainly it is far cheaper to find the bug before the test phase is started. Atollic TrueSTUDIO allows the easy creation of a code review session by defining which files in the project shall take part and which project members become reviewers.
Reviewers can study the source code files in the editor and add comments to various code lines that can then be discussed with colleagues in a code review meeting. Now that functions for code reviews are being integrated into professional C/C++ environments, software quality can be dramatically improved.
The manual source code review activity can be extended with automated static source code analysis. Most tools check the coding style versus a formal coding standard, such as MISRA-C. An important feature is the capability to provide statistics about the source code, such as reporting the code complexity level for different C functions. This tool should be integrated in the C/C++ IDE to simplify its daily routine use, as is the case with the TrueINSPECTOR tool that integrates into TrueSTUDIO. The tool lists all detected coding standard violations, but also displays graphical charts providing overview information.
Most embedded projects do not use a formal test methodology, although teams are increasingly looking into the use of unit tests. Unit tests are essentially function calls into C/C++ functions, where each function call use a different combination of input parameter values, to drive different execution paths in the function. But writing unit tests takes time and usually does not cover all the important execution paths anyway.
A better approach is to use a full embedded test automation system. Such tools have not been common in the embedded industry previously, but new tools such as True-VERIFIER, which is fully integrated in the C/C++ IDE, now offer very powerful test automation capabilities. Additionally, tools for measuring the test quality in-target ought to be deployed to ensure that the test procedures do in fact exercise the important parts of the software. Atollic TrueANALYZER is one of the first tools on the market to provide system-level, in-target, test quality measurement for embedded systems.