The Eclipse open-development platform

An open-source collection of extensible frameworks, tools, and runtimes for building, deploying, and managing software

BY ROBERT DAY
LynuxWorks, San Jose, CA
http://www.lynuxworks.com
rday@lnxw.com

The embedded world has traditionally struggled to provide a common and open development interface for software and systems engineers. Tools have traditionally been tied either to the RTOS or the processor, and the specifics of either have dictated proprietary environments to support them, making it difficult to change the environments to meet the changing needs of designs without steep learning curves and expenditures on extra tools.

By using the Eclipse open development platform, the embedded software developer has an opportunity to standardize on an environment that will offer a new level of consistency across different tools.

Get acquainted

For embedded developers who are used to a very debug-centric tools environment, Eclipse may seem a little alien at first, as the environment starts up around code development and project management.

A general rule of thumb for new Eclipse users is that it takes about half a day to get acquainted with the environment. After that, the developer rapidly becomes more productive than with more traditional tools and starts to use the real power of a fully integrated development environment. This rule of thumb has been obtained by talking to many embedded developers who have made the move and are now very satisfied with the freedom and flexibility Eclipse-based products provided.

A platform

Eclipse is not an embedded environment, but a platform born from the enterprise development world, which allows companies to plug-in their own tools using a standard mechanism and offers a standard user interface. How the tool works and what the tool does may well vary from processor to processor or RTOS to RTOS, but the integrated development environment (IDE) stays the same, and the general look and feel will be very similar. This has major benefits for both vendors and users.

Vendors no longer have to develop and maintain IDE technology that is not specific to the embedded domain. They can take advantage of third-party plug-ins to allow their users to build a best-in-class software development environment tailored to their specific needs. These can be either embedded or enterprise, with commercial or open-source licenses.

A common interface

Embedded developers now have a common user interface from which to launch their tools. The look and feel of the IDE will not change regardless of the tools.

Provided they are a little careful with choice of tools vendors, developers should be able to use a wide selection of tools and real-time operating systems without compromise. The choice of an open-standard IDE also takes away the “lock-in” to tools and IDE that has traditionally been a necessary part of selecting an RTOS. Users can now select the RTOS of their choice with an Eclipse-based IDE and know that if that RTOS doesn’t meet their needs for the next project, they can simply “plug-in” a new one.

Plug-ins

The Eclipse framework can accept any number of plug-ins, which can be full environments, standalone applications, or just additional windows in an existing plug-in. There are strict guidelines to writing the plug-in via an API, which ensures consistency across applications, but there is also a lot of help in the form of wizards, templates, menus, and examples to make the actual API part relatively straightforward.

The Eclipse framework and the GUI part of the plug-ins are all written in Java (for easy programming and portability), and the Eclipse development environment (for creating Eclipse plug-ins) comes with a couple of useful toolkits. Something called the Standard Widget Toolkit (SWT) is used to create low-level functions such as buttons and dialogues, and the higher-level JFace provides a toolkit to help create views, lists, and trees (see Fig. 1 ).

Fig. 1. The architecture of the Eclipse platform provides for the plug-in methodology.

The whole plug-in does not have to be written in Java, only the GUI part. So legacy C or C++ applications can be ported as Eclipse plug-ins without involving total code rewrites. This is good for embedded vendors, and helps developers who have proprietary tools. These can all now run under the same environment.

Projects and subprojects

On top of the Eclipse platform there are a number of projects and subprojects being developed by the open-source community. These projects are staffed from different levels of the Eclipse membership: strategic developers, strategic consumers, add-in providers, and open-source project leaders. Membership is not required for participation in, or even leadership of, these projects.

Projects meet either general or specific requirements that affect 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) products, often to complement their core technology.

Two projects CDT and DSDP are either directly related to embedded development, or are very commonly used by embedded vendors. Many embedded companies (often competitors) are involved with and contribute to these 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 the 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. A C and C++ context-sensitive editor is included, and for embedded debug there is an Eclipse-based GUI on top of the GNU GDB debug engine allowing seamless interaction between edit, build, and debug of the software (see Fig. 2 ).

As CDT itself is a plug-in to the standard Eclipse platform, and offers both a build and debug perspective, it is easy for other tools to be “plugged-in.” This then makes for a full embedded-systems development environment.

Fig. 2. An example of a debug perspective based on the CDT project shows additional windows displayed for RTOS and system awareness.

The Device Software Development Project (DSDP) is a relatively 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 GUIs. It encompasses eRCP, which is a project that is porting a stripped-down version of Eclipse suitable for actually running on an embedded system, providing a Java-based platform under which to run embedded applications. Other elements of this project revolve around both how a debugger communicates to an embedded target system and attempts to introduce some open standards for this communication into this Eclipse project.

Lifecycle

Looking at the embedded software design lifecycle, Eclipse adds an additional benefit for developers in that tools commonly used for embedded development, but not designed specifically for that task, generally have an Eclipse integration and can seamlessly plug-in next to embedded specific tools. So moving from design to deployment, the embedded developers can start with requirements and high-level design tools, which are not specific to embedded, and then generate code that can be used in the build perspective with embedded compilers and linkers.

Once the code is built, the developers click a single button to move to the debug perspective, connect to their target, download their code, and debug their application. For more detailed testing and analysis, other Eclipse perspectives can be brought up, offering profiling, analysis, and testing tools to really take the code through a thorough workout before deployment.

Truly integrated tools integrate directly into the Eclipse framework or plug-in to one of the projects. For example, tools that plug straight into the Eclipse framework have the advantage that they can generally work with any other plug-in providing that plug-in has no dependence on an Eclipse project, but for a close integration additional work will need to be done by the tools vendor. Tools that integrate with one of the projects (such as CDT) have the advantage that they will often have a tighter integration with CDT-based tools, and will require less (if any) integration work. ■

For more on Eclipse, visit http://www.eclipse.org and http://www.eclipseplugincentral.com