EDA & Development
Rise of the software engineer
Speeding up embedded application development is not just a case of writing code quicker. As Magnus Unemyr explains, it’s about developers using the right tools to become, in essence, software engineers
T
he 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. 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.
Traditional Tools 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 38 December 2011/January 2012
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.
Editing
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.
Compilation
For compilation, as an example, Atollic’s 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. It 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 purchase Microsoft VisualStudio. TrueSTUDIO also goes a step further and is believed to be one of the first development tools that can build project files in parallel, shortening build time
Components in Electronics Figure 1: Parallel compilation in Atollic TrueSTUDIO can reduce build times
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
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.
Debug New development tools will need to
www.cieonline.co.uk
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.
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.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48