Embedded software development tools and its requirememts

inShare14

What is so special about programming embedded software? More specifically, how does it differ from programming for desktop computers? Along with addressing these questions, this article looks at why there are so many options for embedded development tools - why such a wide choice? And what strategy makes sense for selecting them? Are free tools worth having or do you need to pay real money?

The need for embedded tools
A significant factor in getting any kind of job done properly is having the right tools. This is true whether you are remodeling a kitchen, fixing your car, or developing embedded software. Of course, it is the last of these that is of interest here. I have been evangelizing on this topic for years (decades!). The problem is that there is a similarity - arguably superficial - between programming an embedded system and programming a desktop computer. The same kind of languages are used and software design techniques are fairly universal. However, there are some major differences.

There are three key areas of difference between desktop and embedded programming:

• The degree of control required by the embedded developer is much greater, in order to utilize resources (time, memory and power) effectively.
• The approaches to verification and debugging are quite different for an embedded system, as an external connection and/or a selection of instruments need to be employed. Also, further tools may be needed to optimize the performance of the application.
• Every embedded system is different, whereas every desktop computer is basically the same. So, desktop programming tools can make numerous assumptions about the execution environment and user requirements and expectations. Embedded development tools make few such assumptions. This means that the tools (like the programmers) need to be much more flexible and adaptable.

Getting tools
Because there are so many desktop programmers, all working in the same environment, there is a huge demand for tools. The result is that very good tools are effectively (or literally) free. The apparent similarity of embedded to desktop programming means that developers have a misguided expectation that their tools should be free too - regardless of their specialized needs and much lower demand level. In the electronic design (EDA) world, there is no such expectation. Tools are valued and price tickets are commonly in five figures.

There are essentially two ways that embedded developers can currently get tools:

• They can purchase commercial tools that are dedicated to the needs of the embedded developer. This is undoubtedly the best approach, but their costs are substantial. There is a reasonable expectation that the tools will work "out of the box" and that good quality technical support is available.
• They can choose free open source tools that have been adapted for embedded use, or do the adaptation themselves. The direct costs are lower, but the extra time needed to get the tools into shape and to obtain support from the open source community cannot be ignored.

The challenges associated with utilizing open source tools should not be under-estimated.

Open source tools deployment
There are a number of key issues to be addressed and decisions to be made when deploying open source tools. This process starts with consideration of exactly which tools are needed for the project; each one needs to be considered in turn:
C/C++ compilers – Do you need C++? GNU C++ runtime library can be difficult to build. Some C++ features, like EHS, require additional configuration and validation.
Assembler
Linker
Runtime Libraries – libgcc provides low level compiler support. Which C runtime library is appropriate?

• GLIBC is POSIX compliant
• uClibc has smaller footprint
• Newlib smaller still for no OS

Debugger – GDB gives source- and assembly-level debugging. Can be used as command line or as back end to Eclipse.
Debug Stub(s) – How does your JTAG unit connect to GDB? How will you program flash memory? Standard stubs only support TCP/IP. Need to find or write full featured stub.
Integrated Development Environment – Do you want a GUI? Proper configuration of Eclipse with GDB and stub is challenging. Eclipse must not be modified as this may compromise 3rd party plug-ins.

Following on from this decision, there are a series of questions to answer:

• Are the right tools available to build the toolchain?
• On Windows, will Cygwin be used or Win32 API? It is easier to build with Cygwin, but pathname issues make Cygwin toolchain less easy to integrate with other tools. Cygwin also has runtime overhead and toolchain users must have Cygwin DLL.
• What versions of the various toolchain components will be used? And what patches should be applied?
• How should the various toolchain components be configured? This is a not a trivial matter, as the configure scripts have thousands of options.
• What CPUs will be used on the target systems? Will both big endian and little endian code be required? For example, bare metal ARM runtime libraries are optimized for little endian ARM V5 (). This will not work with ARM V4. Also the ARM V6 architecture would not be used efficiently.

Figure 1. A tool chain for embedded development should include an IDE, compilers for C and C++, assembler, linker, a debugger, virtual machine hypervisor, code libraries, and JTAG resources.

Having built the toolchain (Figure 1), there is the question of its validation. This is comprised of four steps:

• Compiling programs and running those programs in the target environment.
• Compiling programs and inspecting the generated object file or executable image, without running the generated code.
• Compiling fragments of a program with multiple compilers and linking the fragments together.
• Compiling invalid program fragments and checking for appropriate error messages.

Test suites are available to assist with this part of the process.

A third way?
Given these issues, the deployment of open source tools may suddenly look unattractive. But maybe there is a third way. What if a vendor were to take the best-in-class open source tools, comprehensively adapt them to the needs of the embedded developer, add some additional tools that fulfill their specialized requirements, and offer this as a reasonably priced package?

This package might be available in various editions, recognizing the diverse needs of embedded developers, and be available for immediate purchase and download on the Web. High quality technical support would also be available. For users with particularly specialized needs, services would be available to further adapt the tools to fit their specific requirements. Also, silicon vendors might commission this company to produce industry standard toolchains for their specific devices.
What if such a company existed? We can dream. But sometimes dreams come true ...