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
Oct 15, 2021
We will not let today's gray and wet weather in Fort Worth (home of Cadence's Pointwise team) put a damper on the week's CFD news which contains something from the highbrow to the... [[ Click on the title to access the full blog on the Cadence Community site. ...
Oct 13, 2021
How many times do you search the internet each day to track down for a nugget of knowhow or tidbit of trivia? Can you imagine a future without access to knowledge?...
Oct 13, 2021
High-Bandwidth Memory (HBM) interfaces prevent bottlenecks in online games, AI applications, and more; we explore design challenges and IP solutions for HBM3. The post HBM3 Will Feed the Growing Need for Speed appeared first on From Silicon To Software....
Oct 4, 2021
The latest version of Intel® Quartus® Prime software version 21.3 has been released. It introduces many new intuitive features and improvements that make it easier to design with Intel® FPGAs, including the new Intel® Agilex'„¢ FPGAs. These new features and improvements...

featured video

DesignCon 2021 112G Ethernet & PCIe 6.0 IP Demos

Sponsored by Synopsys

This video features Synopsys' silicon-proven DesignWare 112G Ethernet and PCIe 6.0 PHY IP solutions successfully interoperating with Samtec's AI/ML edge connectors and Amphenol's Direct Attach Copper (DAC) cables with superior Bit Error Rates (BERs) at maximum performance.

Click here for more information about DesignWare 112G Ethernet PHY IP

featured paper

Improving Design Robustness and Efficiency for Today’s Advanced Nodes

Sponsored by Synopsys

Learn how designers can take advantage of new ways to efficiently pinpoint voltage bottlenecks, drive voltage margin uniformity, and uncover opportunities to fine-tune operating voltages using PrimeShield design robustness solution.

Click to read the latest issue of Designer's Digest

featured chalk talk

i.MX RT1170

Sponsored by Mouser Electronics and NXP Semiconductors

Dual Core microcontrollers can bring a lot of benefits to today’s modern embedded designs in order to keep all of our design requirements in balance. In this episode of Chalk Talk, Amelia Dalton chats with Patrick Kennedy from NXP about why newer design requirements for today’s connected embedded systems are making this balancing act even harder than ever before and how the i.MX RT1170 can help solve these problems with its heterogeneous dual cores, MIPI interface, multi-core low power strategy and SRAM PUF technology can make all the difference in your next embedded design.

Click here for More information about NXP Semiconductors i.MX RT1170 crossover microcontrollers