Eclipse is becoming a very widely used platform for embedded systems development tools, offering both a common user interface and the potential for true interoperability between tools offered by different vendors.

It also offers the opportunity for extendibility by the embedded systems developers themselves allowing for very specific development tools to be easily developed, integrated and deployed within an embedded systems project team. The title of this paper is very apt, as the structure of Eclipse can be analogous to a car.

The Eclipse platform can be seen as the framework of a car, and everything else is plugged-in to that framework, with the resulting product being a complete running development environment. The plug-ins are provided either from the Eclipse.org open-source, by commercial vendors, or plug-ins written by the user. These plug-ins can be essential to the environment (analogous to the engine of the car) or more cosmetic (rather like the internal and external décor options in a car).

Returning to the car analogy, this paper will take you through all the component parts that make a car work, show you some different models of car, open the hood and show you all the parts of the engine. It is not designed to make you a car mechanic.

Eclipse is:
a) An open-source community (Eclipse Foundation)
b) An open framework for the development of software tools (Eclipse Platform)
c) A modern technology written in Java offering portability without sacrificing performance and allowing easy plug in of software tools (Eclipse Plug-ins)
d) A collection of open-source projects that offer solutions for most software development tasks (Eclipse Projects)
e) A unified IDE (Integrated Development Environment) used by the majority of embedded systems vendors from RTOS to Processor companies

The Eclipse Foundation is a not-for-profit corporation formed to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.

The Eclipse Platform is written in the Java language and comes with extensive plug-in construction toolkits and examples. It has been deployed on a range of development workstations used by embedded developers including Linux, HP-UX, Solaris, and Windows based systems. Figure 1 below shows the architecture of the Eclipse platform.

Figure 1 " The Eclipse Platform " an inside look

From its beginnings in 1999, the Eclipse platform today (Figure 1, above) is at version 3.1, and the organization has well over a 100 member companies supporting and developing the Eclipse Platform, Eclipse Projects and their own commercial products utilizing the Eclipse Platform.

Eclipse " Organization
With the change in 2001 to an independent not-for-profit corporation, a full-time Eclipse management organization has been established to engage with commercial developers and consumers, academic and research institutions, standards bodies, tool interoperability groups and individual developers, plus coordinate the open source projects.

To maintain a reliable and accessible development roadmap, a set of councils (Requirements, Architecture and Planning) will guide the development done by Eclipse Open Source projects. With the support of over 115 member companies, Eclipse already hosts 9 major Open Source projects that include a total of over 50 subprojects.

To oversee and staff this new management organization, Eclipse has established a Board of Directors drawn from four classes of membership: Strategic Developers, Strategic Consumers, Add-in Providers and Open Source project leaders. Developers and Strategic Consumers hold seats on this Board, as do representatives elected by Add-in Providers and Open Source project leaders. Strategic Developers, Strategic Consumers and Add-in Providers contribute annual dues.

Eclipse License
In the Eclipse Platform, code access and use is controlled through the Eclipse Public License, which allows individuals to create derivative works with worldwide re-distribution rights that are royalty free. Unlike the GPL, tools developers can keep their own proprietary software and technology out of the Open-Source community even though they have used, and had access to the Eclipse Platform and Eclipse Projects.

This allows commercial tools vendors and the open-source community to work synergistically together, and offers a business model that allows commercial tools vendors to develop and market their core technology competence, while using an open and interoperable architecture.

The mature, portable, interposable and extensible technology (Eclipse Platform) with a non-prohibitive usage license (EPL) has made Eclipse a very obvious choice in the embedded systems world, that has always had very proprietary IDEs, either linked to a specific RTOS or specific processor architecture. Eclipse allows embedded developers to use multiple RTOS offerings across multiple processor architectures without having to change, buy or re-learn a new tools environment.

A spin-off benefit is also the ability for embedded developers to design and develop their own proprietary tools that can plug into the Eclipse environment and co-exist with commercial tools without fear of these proprietary tools being handed back into the open-source and hence potentially into competitors hands.

Eclipse Projects
On top of the Eclipse Platform there are a number of projects and sub-projects that are being developed by the open source community. . These projects are staffed from all different levels of the Eclipse membership; Strategic Developers, Strategic Consumers, Add-in Providers and open source project leaders. Membership of Eclipse is not a required for participation in, or even leadership of, these projects.

These projects meet either general or specific requirements that pertain to the development of software, and are generally managed or led by companies that have expertise in that particular area. These projects can then be used as an example or base for companies to design their own commercial (or free offering) often to complement their core technology.

Figure 2, below, shows the Eclipse architecture including the most significant projects (called top-level projects), and also an indication of future areas and projects that are deemed by the Eclipse foundation and members as being a valuable component in software development that should be offered in the open source community. The Projects highlighted in green are the projects that currently are most relevant to embedded systems development.

Figure 2 " Current and Future Top-level Eclipse Projects

The C/C++ Dev Tools (CDT project) is the basis of many Eclipse-based embedded software development tools. The project uses the Eclipse Platform and corresponding project navigator as it's IDE, and includes a build and make GUI that includes the GNU C/C++ compilers and allows for the easy connection to other embedded cross compilers.

Also included is an Eclipse based debug GUI on top of the GNU GDB debug engine allowing seamless interaction between edit, build and debug of embedded software. Finally a C/C++ context sensitive editor is included in the package.

As this project is utilized as a plug-in perspective to the standard Eclipse platform, it is easy for other tools to be "plugged-in" and make a full embedded systems development environment taking advantage of the benefits of open-source for many of the common build and debug elements.

The Device Software Development Project (DSDP) is a new project that is looking at many of the aspects of debugging an embedded system. Initially, DSDP focuses on building infrastructure for Target Management, Device Debugging, Mobile Java, and Embedded GUI's.

One of the key elements that are being worked on in the initial phase of this project revolve around how a debugger communicates to an embedded target system and trying to bring in some open standards for this communication into this Eclipse project. 

The Test and Performance Tools Platform (TPTP) is not specifically aimed at embedded systems development, but offers some interesting plug-ins and example programs that can help show and utilize embedded test and performance software.

Finally, the embedded rich client platform project (eRCP) is a sub-project (not shown on Figure 2, above) that is allowing the Eclipse Platform to run on an embedded device. This will allow embedded developers to write "on-target" programs that can take advantage of a standard and portable framework (also the same environment that they are using on their development host to build and debug their system).

Some examples of Eclipse based embedded products include:
1) Dev Rocket from Monta Vista
2) Luminosity from LynuxWorks
3) Neutrino from QNX Systems
4) Workbench from Wind River
5) Nucleus EDGE from Accelerated Technology
6) Platform Express from Mentor Graphics
7) Tau from Telelogic

Eclipse look and feel
One of the real benefits that Eclipse brings to the embedded software world is that of consistent user interface. Any products that are built on Eclipse are done so using a set of rules and APIs that while allowing great flexibility in which tools can use Eclipse, they also offer some element of rigidity in how they are implemented. As a software developer this means that you only have to learn one IDE and one tools paradigm, which greatly increases productivity when using different tools over different projects.

The Eclipse platform UI is built around a workbench that provides the overall structure, and offers an extensible UI to a tool vendor to build a commercial product around, or a software developer the ability to add new tools to the Eclipse platform. The workbench API and implementation are built from two Java toolkits (shown in Figure 1 earlier):

1) SWT " a widget set and graphics library for the host platform, but having a host OS independent API
2) JFace " a UI toolkit implemented using SWT that simplifies common programming tasks.

The workbench provides the user interface personality of the Eclipse Platform, and this paradigm is based on editors, views and perspectives. A workbench window consists of views and editors, where a perspective is specific selection and arrangement of views and editors.

Editors allow users to open, edit and save objects (typically C and C++ source files in an embedded system). The Platform supplies a standard text editor, the CDT project offers a more specific C/C++ context version, other commercial products offer their own editors (for example UML editors), and standalone commercial editors also exist (e.g. SlickEdit).

Views are used to provide information on an object that the user is working on. There are standard views provided by the Eclipse platform, such as the Navigation and Outline views for looking at a collection of objects.

Commercial products available under Eclipse generally offer views that are specific to the products that these vendors offer. The high level projects (for example CDT) offer some sample views that can be used as is, or augmented by other views.

Figure 3: Build perspective with project, outline, editor and build views

A workbench window can have multiple perspectives available, but can only have one visible at any one time. The Platform provides standard perspectives that combine some of the standard views. The high level projects also provide some example perspectives, which can also be used and augmented by commercial software vendors.

In the embedded software world, some example perspectives are:

1) build - which offers views of the source files, a c/c++ specific editor, and a view of the build process and progress (Figure 3, above)
2) debug - which gives host/target connections, code debugging, data debugging, RTOS awareness (Figure 4, below)
3) profiling - giving a more detailed view of the performance of a system, looking at memory, tasks and timing
4) design - if a high level design tool is used, then this perspective shows the relevant design charts " often shown in a modeling language like UML

Figure 4 -Standard CDT debug perspective

Moving from one perspective to another is as simple as one button click. The arrangement of the views or windows in a perspective is customizable by each user.

Eclipse Architecture
The Eclipse platform is divided up into core and UI. Anything classified as "UI" needs a host windows system, whereas things classified as "Core" can run "headless" (without a windowing system).

The UI portion or the Eclipse platform is known as the workbench (see previous section). The core portion is simply called the Platform core. The core contains the platform runtime and plug-in management, workspaces and resource management, and version and configuration management (for Eclipse).

As described earlier, the workbench uses the SWT and JFace to build graphical applications and then sits on the Platform core to enable execution.

Standard Widget Toolkit (SWT). SWT is a small, fast widget toolkit with a portable API across host operating systems. It is implemented in such a way as to allow tight integration with the underlying native window system. The Entire Eclipse Platform UI, and the tools that plug into it, use SWT for presenting information to the user.

Unlike Java AWT, which uses low-level widgets tightly coupled to the native windowing system, and Java Swing, which uses emulation layers to attempt to make applications look like the native windowing system, the SWT implementation uses native widgets wherever possible, and provides a suitable emulation when no native widget exists.

Common low-level widgets such as lists, text fields and buttons are implemented natively everywhere, but some generally useful higher-level widgets might be to be emulated on some windows systems. This strategy allows SWT to maintain a consistent programming model in all environments, while allowing the applications to utilize the underlying window systems native look and feel, and optimize the performance of the applications UI.

SWT also exposes the native windows API where a particular windows system has a significant feature that can be well utilized by an application. This is inherently non-portable across windows systems, and this non portability is highlighted in the package.

For each native windows system there is a separate implementation of SWT. Each implementation is expressed as Java code, and exposes the underlying APIs for the specific windows system. This makes the programming experience easier for C programmers who are moving to Eclipse, as although it's written in Java, it is very easy to recognize the native windows API that they are used to calling from C programs.

JFace User Interface Framework. Jface is useful for building complex UI pieces. It works in conjunction with SWT without hiding it. It has a number of frameworks including dialogues, preferences, wizards and also progress reporting dialogues for time consuming operations. It has two interesting features called actions and viewers.

The action mechanism allows user commands to be defined independently from where they are in the UI, and represent a command that can be triggered by the user when using a button, menu item or tool bar. This separation means that the same action can be used in several places in the UI, and is easy to change where the action is used without having to change the action code itself.

Viewers give a high level of abstraction for certain SWT widgets. They are used to help the developer present OO data by providing highly object-oriented wrappers around their associated SWT widgets. There are two basic types of viewer offered in the JFace library, list viewers and text viewers.

List viewers provide lists, tables and trees that work directly with your data objects, and also offer adapter interfaces for working with and accessing that data, such as retrieving an item's label, accessing it's children, selecting items from a list, and sorting and filtering items in a list. Text viewers are used to help take text documents that require more complex styling and presentation, including foreground and background colors, and bold. Eclipse Downloads

To actually start using Eclipse, and looking at ways to extend it with plug-ins, the Eclipse environment and associated development tools must be downloaded and installed.

For tool development, there is an Eclipse SDK available for download. This includes the Eclipse platform, plus the Java Development tools (JDT) and the Plug-in development environment (PDE). For development using CDT as the base tools project, an additional download of CDT is required. Both the SDK and CDT are available for download at www.eclipse.org. 

To run the Eclipse development environment a suitable Java Run-time environment is required. If a suitable JRE is not already installed on the development workstation, it can be downloaded from http://java.sun.com Once those have been downloaded and installed on a suitable workstation, Eclipse can be fired up, explored and new projects (including writing a new plug-in project) can be started. The interface quickly becomes intuitive, and the project and navigation views help to build and manage both embedded and host resident projects.

Developing an Eclipse plug-in
Unlike traditional embedded and host development systems, the same Eclipse environment is used to build both your embedded systems tools and your embedded systems themselves. The difference is the toolset that plugs into the Eclipse framework.

To develop a plug-in (even one that will be used in the context of the embedded tools view) uses the native Java Development Toolkit, along with the SWT and JFace toolkits and libraries. So Eclipse becomes a self-hosting environment. To build an Eclipse plug-in takes a number of steps, all documented and aided by wizards in the Eclipse environment.

Step 1 is to create a plug-in project, using the new project wizard in Eclipse, and selecting the "plug-in project" option in the menu. The wizard then allows the definition of where the plug-in will reside, the plug-in's structure and content, followed by the option of using a template to generate a fully functioning plug-in. In addition to a Hello World demo, these templates allow creation of plugs ins with, respectively, a multi-page editor; an editor; a pop-up menu; a property page; a view(to create a workbench view as described earlier); and one with perspective extensions.

After one of these is selected, other wizard pages ask for specific features that are available as options in these templates. When the finish button is pressed on the wizard, Eclipse will generate the code associated with the options specified in the wizard process.

Step 2 is to use the Eclipse development environment to review and change the generated code. The first step of this process is to examine the plug-in manifest using the plug-in manifest editor.

The plug-in manifest shows how the plug-in being developed relates to all other plug-ins in the system. This is particularly significant, as all other parts of the Eclipse product are realized as plug-ins. After the manifest has been checked, either in the visual editor, or by looking at the XML source to this plug-in's manifest (also available in the editor), the code for the view created by the template can be viewed and edited.

This allows for the addition of new features into the view specific to the plug-in. At this point the view will be working on sample data created in the template, and serves as a good basis to run the plug-in for the first time.

Step 3 is to build the plug-in. This can be done manually by exporting the code for building by the resident host operating systems batch script (Windows batch file or UNIX shell script), or constructing a flexible build script using Apache Ant. The latter takes a little more work up-front, but provides a more robust method for repeatable builds.

Step 4 is to install and run the plug-in. Installation is as simple as unzipping the file created from the build in step 3, restarting Eclipse, and then selecting the plug-in file from a pull down menu in the Eclipse environment.

Debugging of the plug-in is achieved by launching the runtime workbench available in Eclipse, and selecting the debug option. This allows Eclipse to act as a plug-in debugger and runtime execution checker.

The plug-in development environment (PDE) also offers several views for inspecting various aspects of plug-ins while running in the runtime workbench. These include the plug-in registry view and the plug-ins view (both allowing a view of plug-ins that exist in the current workspace), a plug-in dependencies view (showing a hierarchy of the plug-ins dependencies) and finally a plug-in test utility (called PDE JUnit).

Next steps
To go to the next step of the detailed coding required to create a user defined plug-in is beyond the scope of this paper. The presentation of this paper at the Embedded Systems conference will step through an example plug-in so that the audience can understand the steps and component parts of creating a plug in.

A good source for more detailed information and a step-by-step guide to writing an Eclipse plug-in can be found in the book "Eclipse " Building Commercial-Quality Plug-ins" by Eric Clayberg and Dan Rubel (ISBN 0-321-22847-2).

Robert Day is Vice President, Marketing, at LynuxWorks, Inc.

This article is excerpted from a paper of the same name presented at the Embedded Systems Conference Silicon Valley 2006. Used with permission of the Embedded Systems Conference. For more information, please visit www.embedded.com/esc/sv.

Other Eclipse resources on Embedded.com:

1) Embedded design needs open IDEs
2) Eclipse concepts yield reliable software
3) Tuning Eclipse CDT for remote debug
4) Choosing a standard for IDEs
5) Eclipse platform eases SoC development
6) Extensible platform integrates tools