feature article
Subscribe Now

The March of IDEs

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.

Leave a Reply

featured blogs
May 5, 2021
New 5G infrastructure is powering smart city projects worldwide; explore the importance of IoT security for smart city solutions in public safety & logistics. The post How 5G Networks Will Accelerate Development of Smart Cities appeared first on From Silicon To Software...
May 4, 2021
What a difference a year can make! Oh, we're not referring to that virus that… The post Realize Live + U2U: Side by Side appeared first on Design with Calibre....
May 3, 2021
As a NASA flight enthusiast, the idea of unmanned aerial vehicle systems (also known as drones) sounds like a lot of fun. A good example of how fun drones can be is through drone racing'¦yes you read that right'¦ drone racing! However, apart from how fun they can be, drones...
May 2, 2021
https://youtu.be/1HEd6JCriCQ Made in Groveland CA (camera Carey Guo) Monday: Package Assembly Design Kits Tuesday: Rapid Adoption of the Arm Server-Class Processors Wednesday: Arm V9A Thursday:... [[ Click on the title to access the full blog on the Cadence Community site. ]...

featured video

The Verification World We Know is About to be Revolutionized

Sponsored by Cadence Design Systems

Designs and software are growing in complexity. With verification, you need the right tool at the right time. Cadence® Palladium® Z2 emulation and Protium™ X2 prototyping dynamic duo address challenges of advanced applications from mobile to consumer and hyperscale computing. With a seamlessly integrated flow, unified debug, common interfaces, and testbench content across the systems, the dynamic duo offers rapid design migration and testing from emulation to prototyping. See them in action.

Click here for more information

featured paper

Keys to quick success using high-speed data converters

Sponsored by Texas Instruments

Hardware designers using modern high-speed data converters face tough challenges. Issues might include connecting with your field-programmable gate array (FPGAs), being confident that your first design pass will work, or determining how to best model the system before building it. In this article, Texas Instruments takes a closer look at each of these challenges.

Click to read more

featured chalk talk

TI Robotics System Learning Kit

Sponsored by Mouser Electronics and Texas Instruments

Robotics projects can get complicated quickly, and finding a set of components, controllers, networking, and software that plays nicely together is a real headache. In this episode of Chalk Talk, Amelia Dalton chats with Mark Easley of Texas Instruments about the TI-RSLK Robotics Kit, which will get you up and running on your next robotics project in no time.

Click here for more information about the Texas Instruments TIRSLK-EVM Robotics System Lab Kit