Tricking out Your Toolbox
Tooling up for Embedded Software Development

The duct tape kept sticking to the hairs on my hand. Every time I tried to turn the wrench, it would adhere and tear at the skin, sending pain up my freshly burned arm (hint: let the engine cool before attempting to remove a major component), which was jammed between the front of the alternator and a frame cross-member. A bolt I had misplaced earlier made its presence known as I inadvertently slid over it on my back, causing it to gouge through my work shirt, poking my shoulder. WD-40 dripped down the front of the engine onto my work goggles, almost running up my nose, and I struggled to move out of the way.

I had been trying unsuccessfully to coax the same screw from its socket for over an hour with my makeshift apparatus consisting of a screwdriver bit, a crescent wrench, some duct tape, and a chunk of wood. I finally gave up. An hour later, I returned from the parts store with the correct angle screwdriver, a ramp to lift the front of the car, and some wheel chocks. Thirty seconds after that, the offending screw was in my hand. Sometimes, having the right tools for the job makes an enormous difference.

Starting on an embedded software development project without an understanding of the special requirements of embedded development can leave you with a good deal of virtual WD-40 on your cheek as well. Embedded development differs from conventional desktop or enterprise-level software creation in several important ways, and starting out with the right tools to accommodate those differences can make a world of difference in the success of your project and in the pain you’ll encounter along the way.

First, we have the well-known “Where’s my hardware” syndrome. Unlike developing for desktop Windows or Unix, you can’t run down to CompUSA and buy yourself a development platform for your company’s next embedded device. (If you can, you probably need to update either your business plan or your resume.) If you’re like most embedded shops, the hardware and software are developed at the same time. You’ll find yourself debugging your software using simulated or emulated hardware, or prototypes stuck together with FPGAs, wire-wrap and duct tape. In such an environment, when you detect a bug, there’s a reasonable chance that your software is working fine, and the target hardware is just malfunctioning. (Warning! Do NOT attempt this excuse in a design review unless you are absolutely certain that you’re right.) Your software development tool options in this scenario are somewhat more restricted (although the situation is improving rapidly) than they are in mainstream applications development.

The second common trait in embedded development is an explosion of variants. Your smartphone software may have to operate on twelve different models, each with different underlying middleware driving different standards, geographical preferences, languages, and feature sets. Each one of these variants of your software has to be developed, tested, and deployed as if it were stand-alone, but your development process is likely to be anything but. A configuration management system that facilitates branching with minimal effort and allows both development and production builds to be quickly and reliably accomplished across many versions of the product is indispensable for variant-intensive embedded design.

In desktop-application software development, we seldom even consider memory footprint. We’ve become accustomed to the Moore’s-Law-driven bounty of space available in modern platforms. In the embedded world, however, every byte still counts. With market pressures pushing product costs to the basement, on-board memory is one of the favorite places for system designers to save cost on the bill-of-materials (BOM), as well as physical space, power consumption and reliability. The net result is less space available for you on which to put your application. You’ll want compilers that can squeeze your code to the bare minimum, operating systems that can be componentized so only the required pieces are used, and profiling capability that will allow you to see where you’ve splurged and used too much memory.

You’ll also want the capability to watch extra hard for memory leaks. A trickle of orphaned bits that would never amount to much in a desktop environment can quickly become a serious problem in a small-footprint, long-active embedded application. The cost of fixing a bug in embedded can be much larger, too. The ubiquitous “download the latest patch now” panacea that permeates the desktop world has not yet become pervasive or even practical for most embedded applications.

One thing you won’t have to worry about as much as your counter-bound counterparts is portability. They often have to be sure their application will play nicely when their customer carries their CD home and plugs it into anything from a 1995 laptop with a pre-historic Windows installation to a home-brew desktop machine running someone’s personal version of Linux. Your embedded software, on the other hand, will run in a comparatively controlled environment, probably only on the hardware/OS combinations that your company actually ships (which are likely to be far less numerous than desktop computer variants.)

So – with all these special requirements, what do you need for software development tools? The usual – almost. Like me with my duct-taped dynamically reconfigurable standard mechanics tools, you can create embedded software with the same approach and tools you use for more conventional software development – as long as you don’t mind some compromises in convenience. To do the job right, however, with minimal impact to project schedules and your own upward mobility in your company, you’ll want to start with the right setup.

At a top level, the choices look suspiciously familiar to anyone who has done development in that “other” world. On the left, we have the suddenly-almost-universal Eclipse. On the right (far to the right), is Microsoft’s Visual Studio. Basically, if you’re targeting a device with one of Microsoft’s flavors of embedded OS, you’ll probably want to do your code crunching in some version of Visual Studio. If you’re doing anything else, from one of the commercial, fully-supported, proprietary, hard-real-time operating systems, to any of the flavors, versions, and variants of open-source Linux, you’ll probably be diving into something that’s somehow Eclipse-based.

If you’re on the Microsoft side of things, the world’s largest software company has tailored numerous features, extensions, and add-ons to their Visual Studio tools to accommodate embedded development. Microsoft’s approach to the embedded market has been decidedly vertical – aiming at high-value market segments with tailored, focused versions of its OS, development tools, and software IP. If you’ve selected one of their OS options as your deployment platform, you’re probably best served by eating the whole enchilada and using their tools as well. The integration, libraries, IP and add-on capabilities are impressive, and you’ll be hard-pressed to custom-craft a solution that will get you to market any faster.

On the Eclipse side of the world, things are significantly more complicated. Because Eclipse is open source, and because mainstream Eclipse development doesn’t focus primarily on the embedded developer, there are a number of opportunities for enterprising third parties to add value and support by creating “Eclipse-based” development suites. The interpretation of “Eclipse-based” varies widely, meaning anything from proprietary tools with a loose Eclipse integration to specialized, customized Eclipse distributions supported by third-party vendors.

The embedded world is now starting to embrace Eclipse across the board, however, as more and more companies are racing to announce and release their Eclipse-based offerings. Embedded system stalwart Wind River has embraced the Eclipse Device Software Development Platform Project (DSDP) and is leading the charge to open-source, extensible development platforms for device software. The focus of the DSDP effort is adding extensions to Eclipse to better support the embedded development project. Like many vendors, Wind River has apparently decided that re-inventing basic software development tools is not a high-value market, and that the smarter strategy is to ride on the open source progress for basic capabilities, adding proprietary extensions where there is market opportunity.

Wind River has created a versatile development platform called “Wind River Workbench” that spans the gamut of the company’s embedded OS offerings, including VxWorks, Linus, and ThreadX. They also have specialized versions for application developers running and de-bugging on several combinations of emulated environments, native hosts, and on-chip debuggers.

Mentor Graphics also offers a tool suite based on Eclipse. They have focused their efforts on standardizing on an Eclipse-based platform and creating add-ons that will supplement the open source package with extra embedded goodies. For example, they’ve created a capability called “codelets” that runs on the host but executes at a breakpoint on the embedded application. Codelets allow rapid debugging and what-if analysis by providing the ability to run trial or diagnostic code on the host without re-loading to the target hardware. On top of the codelet capability, they have added viewers for various types of data (like images, for example), allowing more realistic evaluation of results by visualizing in a more accessible mode.

Long-time veteran LinuxWorks offers “Luminosity” which is also based on Eclipse. In the same vein as Wind River and Mentor, LinuxWorks boosts and augments the basic Eclipse IDE with extensions and add-ons aimed at embedded developers. Their extensions include tools for multiprocess, multithread debugging on the company’s LynxOS real-time operating systems, and an event-trace tool for displaying OS and application events on the remote target.

If you happen to be in one of the application areas where Ada is the development language of choice, AdaCore provides a robust, Ada-centric environment called “GNAT Programming Studio (GPS).” GPS focuses on developers of safety-critical applications running on a variety of embedded operating systems.

Because of the footprint and performance constraints of embedded platforms, one thing to watch for is the compiler you choose for embedded development. While open-source compilers may work just fine for desktop applications, in the embedded world you often need that last bit of performance and footprint advantage that a specialized compiler can offer. Look to your processor (or processor core) vendor for the compiler that will eek out the last bit of performance. It’s in their best interest to make their compilers show their processors in the best possible light. You want to be the beneficiary of that effort.

Because of the huge number of variants embedded applications can accumulate, old-fashioned make files can become a bit unwieldy. You might want to look at a solution like that offered by Catalyst. Their Openmake product helps you automatically generate those pesky make files, making short work of sorting out that plethora of product configurations, and making sure you don’t inadvertently link in bloated, space-eating, extra libraries without knowing it.

You don’t have to use these specialized embedded development tools, of course. As we pointed out earlier, you can get the job done with a normal, run-of-the-mill software development, a little duct tape, some WD-40, and maybe a supply of aloe vera gel as well.

Kevin Morris, Embedded Technology Journal

January 31, 2006

[back to top]

Comments on this article? Send them to comments@embeddedtechjournal.com