Faster code writing may not speed applications

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.

Basic edit, compile and debug tools are no longer sufficient in the task of writing high-quality software in a timely manner. A new type of tool that manages software complexity and software quality in a better way is required.

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 improved software quality.

Additionally, it is increasingly important that developers move from being ‘code writers’ only, to being ‘software engineers’ and understand and practice 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 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 multilevel macro definitions are expanded.

For compilation, an example tool, Atollic TrueStudio, features a 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. The package also includes two toolchains – 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 buy VisualStudio.

The Atollic software goes a step further and is one of the first development tools that can build project files in parallel, shortening build time 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.

Fig 1: Parallel compilation in TrueStudio can reduce build times

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 used 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.

Fig 2: Parallel compilation reduces build time.

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. The software 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 GUI client for 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 bug reports and feature requests from inside the C/C++ environment.

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. The software 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 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 increasingly teams are looking into the use of unit tests. These are essentially function calls into C/C++ functions, where each function call uses a different combination of input parameter values, to drive different execution paths in the function.

But writing unit tests take time and usually do 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 TrueVerifier, which is fully integrated in the C/C++ IDE, now offer 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.

So, while the software industry has been progressing rapidly overall, arguably embedded software development tools have not kept pace.

However, new tools will provide embedded system developers with integrated products that will provide development projects with increased possibilities to deliver well designed software, on time and on budget, with improved quality.