Debugging is not popularly viewed as an opportunity for personal growth and enlightenment. Surveys show that embedded programmers hate debugging more than any other task. Perhaps not coincidentally, the same surveys show that most programmers spend more time debugging code than they did writing it.
So what’s a poor embedded developer to do? Debugging tools are clearly important, given the amount of quality time that talented and well-paid programmers are going to spend using them. Any gains in debug efficiency pay off in reduced frustration, quicker product development, and the all-important “time to market” metric.
One approach to improving debug efficiency is to standardize the tools. If debug tools all looked more or less the same, programmers wouldn’t have to learn afresh with every new project, new microprocessor, new operating system, or new employer. Debug skills and shortcuts learned on one project could be transferred to another. Debugging sessions would become less of a time sink and more like personal career growth. Even if the bugs themselves don’t migrate, maybe the debugging skills can.
Enter Eclipse. Eclipse is one of many so-called integrated development environments (IDEs) offered from a variety of software companies. An IDE, by definition, combines the compiler and debugger into a single program, on the wholly valid assumption that programmers will be using both tools more or less simultaneously. When the compiler and debugger are combined (at least, visually), it’s easier to correlate what’s happening in one window with what’s happening in the other. Good IDEs can single-step through object code while highlighting the corresponding lines of source code. Breakpoints set in the source appear in the debugger, and vice versa.
Taking the idea a step further, the Eclipse IDE sets a visual tone and style that all Eclipse tools share. Just as all Windows programs or MacOS applications share a certain menu structure and visual style, Eclipse tools all look like they’re related and operate similarly.
Finally, Eclipse is an open-source product that encourages – indeed, invites – users and developers to add their own tools into the IDE. It’s this last characteristic that attracts so many embedded programmers. Instead of relying on debug tools from a single vendor, an Eclipse IDE allows you to mix and match compilers, debuggers, and other tools from anywhere while still enjoying the familiar Eclipse look and feel.
Enter the Serpent
Naturally, there are problems with this, not the least of which is that Eclipse itself was never designed for embedded development. It was originally an IT tool, designed for enterprise-level development on “real” computers, not embedded systems. Eclipse is built on Java, which makes it theoretically portable but also requires a development system with full Java support — in other words, a PC or similar workstation.
Eclipse’s creators originally assumed that most of the programming work itself would be done in Java, which is unlikely for an embedded system. Eclipse didn’t anticipate cross-development, where the code is written on one machine but executed and debugged on another. There was no provision for a download link. There was no need to simulate the target hardware or its microprocessor. There was little need to debug low-level operating system functions and no concept at all of real-time operating systems.
In short, Eclipse was a lousy fit. But several thousand programmers have made it into something quite remarkable and useful. One by one, embedded software companies, RTOS vendors, chipmakers, and tool providers have jumped on the Eclipse bandwagon. With two notable exceptions (Microsoft and Green Hills), most embedded software vendors now provide Eclipse-compatible tools.
In keeping with the open-source origins of Eclipse, the most common compiler for Eclipse is from gnu. Some commercial C/C++ compilers, as well as compilers for other languages, are also Eclipse-compatible. Likewise, gdb is the most common debugger, but there are plenty of other choices.
Eclipse is extensible by its nature and accommodates any number of software “plug-ins” from outside sources. With more than a thousand such plug-ins available, it’s clear that developers are enthusiastic about Eclipse’s possibilities. Some plug-ins are remarkably single-purpose, while others (like text editors) might be useful for almost any embedded project.
Each plug-in adds its own features and may add on-screen buttons or tweak the menu structure appropriately. San Diego RTOS vendor Express Logic, for example, disables (“grays out”) some of the buttons, options, or menu items that aren’t applicable to embedded code while adding ones that are. The changes are more than cosmetic. The company also added RTOS kernel awareness. Rather than generically debug RTOS objects as if they were like any other code, the Eclipse view shows thread status, semaphores, timers, and queues to see how the application is using them and whether it’s all working as intended.
Code can be “downloaded” to a simulator running on the host machine or actually downloaded to real target hardware. Double-clicking the left margin of the source-code window sets a new breakpoint. When the program hits the breakpoint, all the pertinent register and data views are updated.
Cry Freedom
As with most open-source software, there’s “free” and there’s “free.” Eclipse itself is available for anyone to download and use or extend as they see fit. By the same token, companies and individuals are free to sell commercial plug-in extensions if they choose to do so. And many have so chosen.
A company might offer a specific plug-in (one that helps debug their brand of microcontroller chip, for example) at no cost on the assumption that it helps to sell more microcontroller chips. An RTOS company might give away its RTOS-awareness plug-in. Conversely, these plug-ins might cost a few thousand dollars to license, particularly if they’re complex and don’t help to sell another product. As with most development tools, price and quality vary quite a bit, and one is not necessarily a good indicator of the other. Technical support may or may not be included.
Either way, the Eclipse IDE offers a rare taste of standardization in the embedded-development world that’s often beset by conflicting and incompatible commercial interests. It’s heartening in a way to see so many companies and individuals working together for the benefit of embedded developers everywhere.
