Eclipse & the transition to a common embedded IDE -

Eclipse & the transition to a common embedded IDE


What a difference a decade makes. In 1999, every embedded systemstool provider who had an RTOS and a set of tools supported them with aproprietary integrated development environment (IDE), tying everythinginto a neat tightly connected tool chain.

Now, one of the last holdouts – Texas Instruments – hasabandoned itsproprietary IDE in favor of one based on open sourceEclipse.The transition is complete, with virtually every major embeddedsoftware 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 varietyof IDEs jerry-rigged out of a combination of command line interfacesand various Microsoft and Unix windowing kludges, three offered thepotential of becoming the defacto industry IDE: Integrated System'sPrisim+, 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 ofprogramming effort could plug the various tools needed to do codedevelopment quickly and efficiently on each vendor's RTOS.

ISI used the Common Object Request BrokerArchitecture (CORBA) as its common API. WindRiver 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 aJava-based object-oriented software backplane.

All three alsoallowed third party vendors and even customers and users of the variousIDEs to add in their own tools with varying degrees of coupling.

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

On we have tracked theEclipse's evolution closely with articles on such topics as Eclipse under the hood, using Eclipse for C/C++development, extending the Eclipse CDT managed buildsystem, Target Management,Device Debug, Mobile Java,multicore softwaredevelopment and using an Eclipse-based IDE.

What is next for Eclipse? Recently, Eclipse was used to integrate model-centricsystems development with the traditional code-centric approach,allowing developers to move code  back and forth between the twoenvironments. What are some of the other things we can look forward to?

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

Are, as Mike McCullough suggests in “Closedfor business: how open is Eclipse open source?” manyimplementations of Eclipse offered by software vendors “open” in nameonly? ( EditorBernard Cole, )

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.