Do you GNU? If so, some points to ponder

By Mark Mitchell, Mentor Graphics |  1 Comment  |  Posted: March 21, 2012
Topics/Categories: Embedded - Platforms  |  Tags: , ,  | Organizations:

Open-source toolchains give companies ultimate control over their development environments, but how many can really afford the resources to debug and develop their own tools? Would they be better off with a commercially supported open-source approach?

The GNU Project, founded and supported by the Free Software Foundation, is one of  the most widely used outputs of the Free Software movement. It has become the cornerstone upon which hundreds of millions of lines of code depend. For embedded Linux projects, GNU is the de facto standard toolchain.

Embedded-software developers can take comfort in the fact that a wide variety of Linux development technologies are available, thanks to the emergence of multiple open-source communities. The bad news is that even with all this technology, there are still risks associated with building your own toolchain based on open-source components.

Integration issues

Developers working on embedded Linux projects using the GNU toolchain often think that a ‘build from source’ mechanism eliminates most integration issues. This is a dangerous assumption. Most projects don’t get stuck working out how to build cross-development tools and libraries, but may hit problems when the tool-chain fails to work in some subtle, unanticipated way.

To help eliminate integration risks, embedded-software developers must first accept that a ‘build from source’ methodology does not necessarily mean that the engineering team has internalized all the expertise necessary to do the job correctly. One way of tackling this issue is to create a dedicated tools integration, delivery, and maintenance team to reduce integration risk. Once established, this team needs to be isolated from the daily demands of product development if it is to maintain and contribute appropriately to ongoing open-source projects. This means taking engineers away from their core competencies, of designing differentiating applications and products, so they can focus on building, maintaining, and testing toolchains.

Software defects

Toolchain defects can stop a project in its tracks. Unfortunately, software defects rarely strike at predictable places in the development flow, so those responsible for maintaining toolchains need to develop expertise at every level of the toolchain and library software stack. All too often, this means developing competency across a frighteningly broad swath of the code.

In addition to large amounts of code, community projects can also change quickly. Consider the GNU Compiler Collection (GCC), which ten years ago had about two million lines of code. According to Ohloh.net, over the past ten years, an average of more than 400,000 lines of code have been added to GCC each year.

This is relevant because compiler defects are typically detected late in the engineering schedule, when projects can least afford a delay. By this point, the open-source community may have significantly modified its codebase and is often only interested in diagnosing and fixing defects at the tip of the development branch upon which it is currently working. The open-source community may show little interest in solving a problem with an older version of the software upon which the embedded-software engineering team is now dependent.

The commercial open-source toolchain

Given these factors, software developers may want to consider using a commercial open-source development toolchain, such as Mentor Embedded’s Sourcery CodeBench. Working with a commercial partner reduces integration risk by offering an engineered, tested, and supported product based on open-source technologies. The commercial partner takes on the burden of keeping up to date with the progress of community software projects. Further, when a suspected tool bug is encountered, the commercial partner’s engineering staff can diagnose and fix the defects. Commercial tool partners may also supplement the open-source workflow with proprietary components; or enhance the developer experience through plugins, analysis tools, and agents that are not available from community projects.

Finally, a commercial tool partner can usually offer sustaining engineering services so that your hardware development team can keep working with one version of software, even as newer versions are made available.

A simple test drive

A commercial tool flow is robust and validated and usually includes the latest enhancements to the GNU toolchain. Evaluation versions of the toolchain are often offered as a part of a bigger design package including runtime, prototyping board, supporting packages, etc., which helps to expose users to the wider development task. For example, Mentor has created a Mentor Embedded Linux Kit which is a prebuilt image for the PandaBoard and BeagleBoard and a derivative of its larger Mentor Embedded Linux offering, which is itself derived from the popular Yocto Project. This kit includes a cross-development toolchain in a Linux runtime environment. With the pre-built, Yocto-based distribution, embedded-software developers can start experimenting with the Yocto offering and then build from there.

Figure 1
Using an open-source commercial toolchain, such as Sourcery CodeBench, to build and debug applications on the PandaBoard (Source: Mentor Graphics – click image to enlarge)

Experimenting with these boards will give the embedded-software engineer an idea of the advantages of a controlled GNU toolchain. It is a fast and easy way to build or create a customized application for the target device, in a GNU microenvironment that can be relied upon to be without any integration issues or software defects.

To test drive the BeagleBoard or PandaBoard, click here.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

About the Author

Mark Mitchell is Director of Embedded Tools, Embedded Software Division at Mentor Graphics. Before joining Mentor, Mark was the founder and Chief Sourcerer of CodeSourcery, Inc. Mark has worked on C/C++ software development tools since 1994, and he has been the Free Software Foundation’s GNU Compiler Collection (GCC) Release Manager and a member of the GCC Steering Committee since 2001. He holds degrees in computer science from Harvard and Stanford.

Contacts

Mentor Graphics
Worldwide Headquarters
8005 SW Boeckman Rd
Wilsonville
OR 97070-7777
USA

T: +1 503-685-7000
W: www.mentor.com

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors