Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Embedded software development tools: A third option

Posted: 22 Dec 2014     Print Version  Bookmark and Share

Keywords:embedded software  programming  EDA  Debugger  cygwin 

What is so exceptional 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 utilise 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 optimise 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 specialised 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 utilising 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.
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.

1 • 2 Next Page Last Page

Comment on "Embedded software development tools:..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top