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
Jan 17, 2022
Today's interview features Dajana Danilovic, an application engineer based near Munich, Germany. In this video, Dajana shares about her pathway to becoming an engineer, as well as the importance of... [[ Click on the title to access the full blog on the Cadence Community sit...
Jan 13, 2022
See what's behind the boom in AI applications and explore the advanced AI chip design tools and strategies enabling AI SoCs for HPC, healthcare, and more. The post The Ins and Outs of AI Chip Design appeared first on From Silicon To Software....
Jan 12, 2022
In addition to sporting a powerful processor and supporting Bluetooth wireless communications, Seeed's XIAO BLE Sense also boasts a microphone and a 6DOF IMU....

featured video

Synopsys & Samtec: Successful 112G PAM-4 System Interoperability

Sponsored by Synopsys

This Supercomputing Conference demo shows a seamless interoperability between Synopsys' DesignWare 112G Ethernet PHY IP and Samtec's NovaRay IO and cable assembly. The demo shows excellent performance, BER at 1e-08 and total insertion loss of 37dB. Synopsys and Samtec are enabling the industry with a complete 112G PAM-4 system, which is essential for high-performance computing.

Click here for more information about DesignWare Ethernet IP Solutions

featured paper

How to Fast-Charge Your Supercapacitor

Sponsored by Analog Devices

Supercapacitors (or ultracapacitors) are suited for short charge and discharge cycles. They require high currents for fast charge as well as a high voltage with a high number in series as shown in two usage cases: an automatic pallet shuttle and a fail-safe backup system. In these and many other cases, the fast charge is provided by a flexible, high-efficiency, high-voltage, and high-current charger based on a synchronous, step-down, supercapacitor charger controller.

Click to read more

featured chalk talk

Tackling Automotive Software Cost and Complexity

Sponsored by Mouser Electronics and NXP Semiconductors

With the sheer amount of automotive software cost and complexity today, we need a way to maximize software reuse across our process platforms. In this episode of Chalk Talk, Amelia Dalton and Daniel Balser from NXP take a closer look at the software ecosystem for NXP’s S32K3 MCU. They investigate how real-time drivers, a comprehensive safety software platform, and high performance security system will help you tackle the cost and complexity of automotive software development.

Click here for more information about NXP Semiconductors S32K3 Automotive General Purpose MCUs