原创 Eclipse & the transition to a common embedded IDE

What a difference several years make. In 1999, every embedded systems tool provider who had an RTOS and a set of tools supported them with a proprietary integrated development environment (IDE), tying everything into a neat tightly connected tool chain.

Now, one of the last holdouts—Texas Instruments—has abandoned its proprietary IDE in favor of one based on open source Eclipse. The transition is complete, with virtually every major embedded software vendor to varying degrees supporting their own implementation of Eclipse or providing links to it from their own proprietary IDEs, including Express Logic, Wind River, Green Hills, QNX, Lynux Works, and Mentor Graphics, among others.

But it was not always that way. In 1999, in addition to the variety of IDEs jerry-rigged out of a combination of command line interfaces and various Microsoft and Unix windowing kludges, three offered the potential of becoming the defacto industry IDE: Integrated System's Prisim+, Wind River's Tornado and IBM's VisualAge Micro Edition.

What all three had in common was an easy to use "software backplane" into which developers with a minimum of programming effort could plug the various tools needed to do code development quickly and efficiently on each vendor's RTOS.

ISI used the Common Object Request Broker Architecture (CORBA) as its common API. Wind River used an object module format built around the very C-like Tool Command Language (TCL). Somewhere in the middle in terms of complexity and ease of use was IBM's VisualAge which used a Java-based object-oriented software backplane.

All three also allowed third party vendors and even customers and users of the various IDEs to add in their own tools with varying degrees of coupling.

By 2004, everything had changed. IBM open-sourced Visual Age Micro Edition as Eclipse, Wind River acquired ISI and abandoned further development its TCL backplane in favor of Eclipse.

What is next for Eclipse? Just a few years ago, Eclipse was used to integrate model-centric systems development with the traditional code-centric approach, allowing developers to move code back and forth between the two environments. What are some of the other things we can look forward to?

What are the drawbacks to Eclipse? To complicated? Too open? Not open enough? What areas of improvement would you like to see? New plug-ins?

Are, as Mike McCullough suggests in one of his articles, many implementations of Eclipse offered by software vendors "open" in name only?