Embedded Control Systems Design/Software toolchain
The Wikibook of
Embedded Control Systems Design
|
This chapter introduces some software tools are available to support system developers. Not only in the creation of the software to control their systems, but during the complete design process, for hardware as well as software.
Integrated development environment (IDE)
[edit | edit source]An Integrated Development Environment (IDE) is software that assists programmers in developing software (and only software!). IDEs normally consist of a source code editor, a compiler, a linker/locater and usually a debugger. Most often, various tools to simplify the construction of the code are included as well, such as for example version control support, and integration with software frameworks from which code can be reused. Sometimes, an IDE is devoted to one specific programming language or one (family of) specific processor or hardware (for example, the software with which you can program robots from one specific vendor), but more often the IDEs support multiple languages, processors, etc. Some commonly used IDEs for embedded systems are the GNU compiler collection (gcc), Eclipse, Delphi, Kylix, KDevelop, Matlab, Microsoft Visual Studio, Netbeans, Powerbuilder, DevC++, Jdeveloper, IntelliJ, etc.
The industry (and not only the embedded systems industry!) is gravitating towards either the open source Eclipse framework, or the proprietary Visual Studio. The reason why only these two will most probably survive in the future is the effect of increasing returns: an IDE that offers already a lot of integration between component tools has an easier job attracting more users, and more users attract more further development opportunities. (This effect works irrespective of whether the tool is open source or not.) The embedded industry has made to a large extent the choice for Eclipse.
Editor
[edit | edit source]A source code editor is a text editor program designed specifically for editing source code to control embedded systems. It may be a standalone application or it may be built into an integrated development environment (e.g. IDE). Source code editors may have features specifically designed to simplify and speed up input of source code, such as syntax highlighting and auto complete functionality. These features ease the development of code. Some commonly used editors for embedded systems are BBEdit (for Mac), Emacs (GNU), Kate (KDE), Microsoft Visual Studio (built-in editor) and Vi (vim)
Compiler
[edit | edit source]A compiler is a computer program that translates the source code into computer language (object code). Commonly the output has a form suitable for processing by other programs (e.g., a linker), but it may be a human-readable text file. A compiler translates source code from a high level language to a lower level language (e.g., assembly language or machine language). The most common reason for wanting to translate source code is to create a program that can be executed on a computer or on an embedded system. The compiler is called a cross compiler if the source code is compiled to run on a platform other than the one on which the cross compiler is run. For embedded systems the compiler always runs on another platform, so a cross compiler is needed. A cross compiler is a tool that one must use for a platform where it is inconvenient or impossible to compile on that platform, like micro controllers that run with a minimal amount of memory for their own purpose. Since many embedded systems have limited resources, cross-compiling is very common.
A compiler is likely to perform many or all of the following operations: lexing, preprocessing, parsing, semantic analysis, code generation, and code optimizations. Some commonly used compilers for embedded systems are GCC (GNU), Visual C/C++, CPPBuilder (Delphi/Kylix).
Linker
[edit | edit source]A linker or link editor is a program that takes one or more objects generated by compilers and assembles them into a single executable program or a library that can later be linked to in itself. All of the object files resulting from compiling must be combined in a special way before the program can be executed. The object files themselves are individually incomplete, most notably is that some of the internal variable and function references have not yet been resolved. The job of the linker is to combine these object files and, in the process, to resolve all of the unresolved symbols. Linkers can take objects from a collection called a library. Some linkers do not include the whole library in the output. They only include its symbols that are referenced from other object files or libraries. Libraries for diverse purposes exist, and one or more system libraries are usually linked in by default. Unfortunately, the standard library routines often require some changes before they can be used in an embedded program. The problem here is that the standard libraries provided with most software development tool suites arrive only in object form. So you only rarely have access to the library source code to make the necessary changes yourself. If you weren’t working on an embedded system, you’d be finished building your software. For embedded systems the program is complete except for one thing: no memory addresses have been assigned to the code and data. You’ll have to provide information about the memory on the target board as input to the locator. The locator uses this information to assign physical memory addresses to each of the code and data sections. It will produce an output file that contains a binary image that can be loaded into the target ROM. A commonly used linker/locater for embedded systems is ld (GNU).
Debugger
[edit | edit source]A debugger is a computer program that is used to test and debug other programs. The code to be examined might alternatively be running on an instruction set simulator (ISS), a technique that allows great power in its ability to halt when specific conditions are encountered but which will typically be much slower than executing the code directly on the appropriate processor. When the program crashes, the debugger shows the position in the original code if it is a source-level debugger or symbolic debugger, commonly seen in integrated development environments. If it is a low-level debugger or a machine-language debugger it shows the line in the disassembly. Usually programmers use unit testers. These testers can test a minimal software component, or module. An emulator helps programmers test their software, it makes testing with hardware in the loop possible. An emulator simulates the systems that must be controlled by the embedded system. It is possible to use Standard Test Access Ports (JTAG) to debug the software on the embedded system. These standards defines a 5-pin serial protocol for accessing and controlling the signal-levels on the pins of a digital circuit, and has some extensions for testing the internal circuitry on the chip itself. Some commonly used debug programs for embedded systems are GDB (GNU), Microsoft Visual Studio Debugger
Often programmers use bugdatabases. A bugdatabase-program makes it possible to database of all the bugs with their description. So colleagues can find information about bugs easily. They don’t have to waste time by searching a solution for a bug because others already solved it. Some bugdatabase-programs make it possible to discuss bugs with other engineers. A frequently used program is Bugzilla.
Version control
[edit | edit source]Version control is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code and other critical information that may be worked on by a team of people. Changes to these documents are identified by incrementing an associated number or letter code, termed the "revision number", and associated historically with the person making the change. Software tools for revision control are increasingly recognized as being necessary for almost all software development projects. Nowadays, most products are assembled from several components. In order to know what version of each component was used to construct the assembly, all information needs to be kept in a detailed database. In the future, version control software should offer a feature to keep track of all versions of the components in a certain version of the assembly. This makes it easier to solve problems with a product on a later date. Version control software currently used for embedded systems are for example Concurrent Version System (CVS), Subversion (A new version of CVS) and GNU arch.
Model-Driven Engineering toolchains
[edit | edit source]In the past there was a trend to integrate the different steps of the software toolchain in one integrated development environment. This trend continues, more and more features are added to IDEs. A trend for the future is more integration of software development with Computer Aided Engineering (CAE) analyses. For example: developers of software have to adjust their software-code because there are problems with the dynamic response of the system to control. In the future, CAE models of dynamic response and FE analysis will be inherently embedded into the design of the software.
=Modelling standards
[edit | edit source]UML2, SysML, Marte, AADL
MDE projects
[edit | edit source]Important MDE projects for embedded systems development are: www.Topcased.org, www.openEmbedd.org, and www.papyrusuml.org; these projects are cooperating towards more interoperability.
Further reading
[edit | edit source]- Computer programming discusses programming in general (mostly oriented towards desktop and network server computers).
- Eclipse is a popular IDE
- Revctrl : the revision control wiki discusses and compares various version control systems.
- the OpenJTAG wiki