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
Aug 3, 2021
Picking up from where we left off in the previous post , let's look at some more new and interesting changes made in Hotfix 019. As you might already know, Allegro ® System Capture is available... [[ Click on the title to access the full blog on the Cadence Community si...
Aug 2, 2021
Can you envision intelligent machines creating a 'work of art' involving biological implementations of human legs being used to power some sort of mechanism?...
Jul 30, 2021
You can't attack what you can't see, and cloaking technology for devices on Ethernet LANs is merely one of many protection layers implemented in Q-Net Security's Q-Box to protect networked devices and transaction between these devices from cyberattacks. Other security technol...
Jul 29, 2021
Learn why SoC emulation is the next frontier for power system optimization, helping chip designers shift power verification left in the SoC design flow. The post Why Wait Days for Results? The Next Frontier for Power Verification appeared first on From Silicon To Software....

featured video

Vibrant Super Resolution (SR-GAN) with DesignWare ARC EV Processor IP

Sponsored by Synopsys

Super resolution constructs high-res images from low-res. Neural networks like SR-GAN can generate missing data to achieve impressive results. This demo shows SR-GAN running on ARC EV processor IP from Synopsys to generate beautiful images.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

PrimeLib Next-Gen Library Characterization - Providing Accelerated Access to Advanced Process Nodes

Sponsored by Synopsys

What’s driving the need for a best-in-class solution for library characterization? In the latest Synopsys Designer’s Digest, learn about various SoC design challenges, requirements, and innovative technologies that deliver faster time-to-market with golden signoff quality. Learn how Synopsys’ PrimeLib™ solution addresses the increase in complexity and accuracy needs for advanced nodes and provides designers and foundries accelerated turn-around time and compute resource optimization.

Click to read the latest issue of Designer's Digest

featured chalk talk

IsoMOV

Sponsored by Mouser Electronics and Bourns

Today, your circuit protection device needs to be versatile, handling a wide range of conditions with long-life low capacitance, low leakage, and state-of-the-art energy handling density. In this episode of Chalk Talk, Amelia Dalton chats with Paul Smith from Bourns about IsoMOV - a new integrated circuit protection that brings together the most important circuit protection capabilities in one efficient package.

Click here for more information about Bourns IsoMOV™ Series Hybrid Protection Component