Eclipse: Under The hood - Embedded.com

Eclipse: Under The hood

Eclipse is becoming a very widely used platform for embedded systemsdevelopment tools, offering both a common user interface and thepotential for true interoperability between tools offered by differentvendors.

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

The Eclipse platform can be seen as the framework of a car, andeverything else is plugged-in to that framework, with the resultingproduct being a complete running development environment. The plug-insare provided either from the Eclipse.org open-source, by commercialvendors, or plug-ins written by the user. These plug-ins can beessential to the environment (analogous to the engine of the car) ormore cosmetic (rather like the internal and external décoroptions in a car).

Returning to the car analogy, this paper will take you through allthe component parts that make a car work, show you some differentmodels 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 (EclipsePlatform)
c) A modern technology written in Java offering portability withoutsacrificing performance and allowing easy plug in of software tools(Eclipse Plug-ins)
d) A collection of open-source projects that offer solutions for mostsoftware development tasks (Eclipse Projects)
e) A unified IDE (Integrated Development Environment) used by themajority of embedded systems vendors from RTOS to Processor companies

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

The Eclipse Platform is written in the Java language and comes withextensive plug-in construction toolkits and examples. It has beendeployed on a range of development workstations used by embeddeddevelopers including Linux, HP-UX, Solaris, and Windows based systems. Figure 1 below shows thearchitecture of the Eclipse platform.

Figure1 ” 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 supportingand developing the Eclipse Platform, Eclipse Projects and their owncommercial products utilizing the Eclipse Platform.

Eclipse ” Organization
With the change in 2001 to an independent not-for-profit corporation, afull-time Eclipse management organization has been established toengage with commercial developers and consumers, academic and researchinstitutions, standards bodies, tool interoperability groups andindividual developers, plus coordinate the open source projects.

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

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

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

This allows commercial tools vendors and the open-source communityto work synergistically together, and offers a business model thatallows commercial tools vendors to develop and market their coretechnology competence, while using an open and interoperablearchitecture.

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

A spin-off benefit is also the ability for embedded developers todesign and develop their own proprietary tools that can plug into theEclipse environment and co-exist with commercial tools without fear ofthese proprietary tools being handed back into the open-source andhence potentially into competitors hands.

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

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

Figure 2, below, shows the Eclipse architecture including the mostsignificant projects (called top-level projects), and also anindication of future areas and projects that are deemed by the Eclipsefoundation and members as being a valuable component in softwaredevelopment that should be offered in the open source community. TheProjects highlighted in green are the projects that currently are mostrelevant to embedded systems development.

Figure2 ” Current and Future Top-level Eclipse Projects

The C/C++ DevTools (CDT project) is the basis of many Eclipse-based embeddedsoftware development tools. The project uses the Eclipse Platform andcorresponding project navigator as it's IDE, and includes a build andmake GUI that includes the GNU C/C++ compilers and allows for the easyconnection to other embedded cross compilers.

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

As this project is utilized as a plug-in perspective to the standardEclipse platform, it is easy for other tools to be “plugged-in” andmake a full embedded systems development environment taking advantageof the benefits of open-source for many of the common build and debugelements.

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

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

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

Finally, the embeddedrich client platform project (eRCP) is a sub-project (not shownon Figure 2, above) that is allowing the Eclipse Platform to run on anembedded device. This will allow embedded developers to write”on-target” programs that can take advantage of a standard and portableframework (also the same environment that they are using on theirdevelopment 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 fromAccelerated Technology
6) Platform Express fromMentor Graphics
7) Tau from Telelogic

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

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

1) SWT ” a widget set andgraphics library for the host platform, but having a host OSindependent API
2) JFace ” a UI toolkitimplemented using SWT that simplifies common programming tasks.

The workbench provides the user interface personality of the EclipsePlatform, and this paradigm is based on editors, views andperspectives. A workbench window consists of views and editors, where aperspective is specific selection and arrangement of views and editors.

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

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

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

Figure3: Build perspective with project, outline, editor and build views

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

In the embedded software world, some example perspectives are:

1) build – which offersviews of the source files, a c/c++ specific editor, and a view of thebuild process and progress (Figure 3,above)
2) debug – which giveshost/target connections, code debugging, data debugging, RTOS awareness(Figure 4, below )
3) profiling – giving a moredetailed view of the performance of a system, looking at memory, tasksand timing
4) design – if a high leveldesign tool is used, then this perspective shows the relevant designcharts ” often shown in a modeling language like UML

Figure4 -Standard CDT debug perspective

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

Eclipse Architecture
The Eclipse platform is divided up into core and UI. Anythingclassified as “UI” needs a host windows system, whereas thingsclassified 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 Platformcore. The core contains the platform runtime and plug-in management,workspaces and resource management, and version and configurationmanagement (for Eclipse).

As described earlier, the workbench uses the SWT and JFace to buildgraphical applications and then sits on the Platform core to enableexecution.

Standard WidgetToolkit (SWT). SWT is a small, fast widget toolkit with aportable API across host operating systems. It is implemented in such away as to allow tight integration with the underlying native windowsystem. The Entire Eclipse Platform UI, and the tools that plug intoit, use SWT for presenting information to the user.

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

Common low-level widgets such as lists, text fields and buttons areimplemented natively everywhere, but some generally useful higher-levelwidgets might be to be emulated on some windows systems. This strategyallows SWT to maintain a consistent programming model in allenvironments, while allowing the applications to utilize the underlyingwindow systems native look and feel, and optimize the performance ofthe applications UI.

SWT also exposes the native windows API where a particular windowssystem has a significant feature that can be well utilized by anapplication. 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 ofSWT. Each implementation is expressed as Java code, and exposes theunderlying APIs for the specific windows system. This makes theprogramming experience easier for C programmers who are moving toEclipse, as although it's written in Java, it is very easy to recognizethe native windows API that they are used to calling from C programs.

JFace UserInterface Framework. Jface is useful for building complex UIpieces. It works in conjunction with SWT without hiding it. It has anumber of frameworks including dialogues, preferences, wizards and alsoprogress reporting dialogues for time consuming operations. It has twointeresting features called actions and viewers.

The action mechanism allows user commands to be definedindependently from where they are in the UI, and represent a commandthat can be triggered by the user when using a button, menu item ortool bar. This separation means that the same action can be used inseveral places in the UI, and is easy to change where the action isused 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 highlyobject-oriented wrappers around their associated SWT widgets. There aretwo basic types of viewer offered in the JFace library, list viewersand text viewers.

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

To actually start using Eclipse, and looking at ways to extend itwith plug-ins, the Eclipse environment and associated development toolsmust be downloaded and installed.

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

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

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

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

Step 1 is to create aplug-in project, using the new project wizard in Eclipse, and selectingthe “plug-in project” option in the menu. The wizard then allows thedefinition of where the plug-in will reside, the plug-in's structureand content, followed by the option of using a template to generate afully functioning plug-in. In addition to a Hello World demo, thesetemplates allow creation of plugs ins with, respectively, a multi-pageeditor; an editor; a pop-up menu; a property page; a view(to create aworkbench view as described earlier); and one with perspectiveextensions.

After one of these is selected, other wizard pages ask for specificfeatures that are available as options in these templates. When thefinish button is pressed on the wizard, Eclipse will generate the codeassociated with the options specified in the wizard process.

Step 2 is to use the Eclipsedevelopment environment to review and change the generated code. Thefirst step of this process is to examine the plug-in manifest using theplug-in manifest editor.

The plug-in manifest shows how the plug-in being developed relatesto 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 bylooking at the XML source to this plug-in's manifest (also available inthe editor), the code for the view created by the template can beviewed and edited.

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

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

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

Debugging of the plug-in is achieved by launching the runtimeworkbench available in Eclipse, and selecting the debug option. Thisallows Eclipse to act as a plug-in debugger and runtime executionchecker.

The plug-in development environment (PDE) also offers several viewsfor inspecting various aspects of plug-ins while running in the runtimeworkbench. These include the plug-in registry view and the plug-insview (both allowing a view of plug-ins that exist in the currentworkspace), a plug-in dependencies view (showing a hierarchy of theplug-ins dependencies) and finally a plug-in test utility (called PDEJUnit).

Next steps
To go to the next step of the detailed coding required to create a userdefined plug-in is beyond the scope of this paper. The presentation ofthis paper at the Embedded Systems conference will step through anexample plug-in so that the audience can understand the steps andcomponent parts of creating a plug in.

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

RobertDay is Vice President, Marketing, at LynuxWorks, Inc.

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

Other Eclipse resources onEmbedded.com:

1) Embeddeddesign needs open IDEs
2)Eclipse concepts yield reliable software
3)Tuning Eclipse CDT for remote debug
4) Choosinga standard for IDEs
5) Eclipseplatform eases SoC development
6) Extensibleplatform integrates tools

Leave a Reply

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