The Eclipse project, well known as an excellent Java and C/C++ IDE, contains a wealth of features for the embedded developer. With the creation of the Device Software Development Platform (DSDP), the adaptation of Eclipse for embedded developers has a formal place in the Eclipse development community, allowing for continued feature growth in the embedded domain.
In the past, embedded developers who wanted an integrated development environment had no choice but to take what was offered to them by the OS vendor for their project. Even if the IDE itself was of the highest quality, the relatively small user base of any one IDE prevented a third-party ecosystem from developing the often-critical peripheral development tools. The lack of tools integration for embedded IDEs meant that embedded engineers didn’t enjoy the same productivity boost as users of IDEs targeted toward traditional development projects.
(story continues below sponsor)
When embedded OS vendors began migrating their tools to the Eclipse platform, users of their products gained access to the same third-party add-ins available to the Eclipse user base at large. This increased access to tools allowed embedded engineers using Eclipse to enjoy the productivity boost once reserved for users of large-scale, commercial IDEs.
Just like any other active, successful open-source project, Eclipse has continued to evolve. For example, several vendors offer different products for embedded development, and those solutions are being united into a single open-source project for Eclipse. Read on to understand how Eclipse fits into the embedded developer’s suite of tools today and what improvements are on tap for the future.
Eclipse and embedded development
One industry that quickly coalesced around Eclipse included the embedded OS vendors. Most embedded OS vendors worked with customers that expected both an OS and an IDE to boost developer productivity. Before the advent of Eclipse, each embedded company maintained their own IDE containing the specialized features necessary for embedded development: cross-compilation, remote debugging/execution, and target system configuration.
With Eclipse providing the base IDE functionality – such as project management, editing, code-completion, and syntax highlighting – embedded OS vendors were able to concentrate their efforts on just the portions of the IDE of most value to embedded engineers. TimeSys, a pioneer in embedded Linux, was the first company to introduce a commercial product based on Eclipse, catering to the embedded Linux market. Other vendors followed suit with similar products, and in short order, Eclipse became the standard upon which other embedded companies built their OS development environments.
These companies found that they were often working on the same problems, and, under the leadership of WindRiver Systems, formed the DSDP project in June 2005. The goal of this project was to consolidate the efforts of making Eclipse ready for the embedded software market. The DSDP project consists of four subprojects as shown in Table 1.
Device Software Development Platform (DSDP) goals
Target Management
Provides the framework and data models for embedded targets, which may reside on multiple boards with multiple core processors, allowing fine user control over each device. Includes the ability to compile and download code to the target. Downloading code to the target may involve sending data via ZModem over a serial connection, using TFTP over Ethernet, or even a JTAG port.
Device Debugging
Improvements and extensions to the existing Eclipse debugging model to accommodate the remote and multi-target aspects of embedded debugging. The subproject aims to support debugging during board bring-up, system development, and application development.
Mobile Tools for the Java Platform
Extensions to Eclipse for developing Java applications on mobile devices.
Native Application Builder
This project’s goal is to bring a unified GUI development toolkit to embedded developers. Derived from the WideStudio/MWT project, which allows engineers to target multiple operating systems, both desktop and embedded, from a single code base.
Table 1
Being a project in its early stages, the DSDP does not have software currently in release. However, a flurry of development activity surrounds this project. A first release of the software has been scheduled for June 2006 and will contain the following features:
Internal data structures and framework for communicating with remote devices
Target definition and communication
Remote execution and debugging
All of these features lay the foundation for further development by the DSDP team and other vendors in the embedded development field.
Using Eclipse today
While the DSDP project is under development, you can still use Eclipse and CDT for embedded development. With Eclipse and CDT, you will be able to work on C and C++ development but will not yet have the features necessary to interact with your target from within Eclipse. Once compiled, you can download your code to the target board via a terminal and remotely debug using one of several tools.
Eclipse requires a JRE (Java Runtime Environment). If your computer does not have a JRE installed, visit java.sun.com and follow the instructions for downloading and installing Java for your platform. The Java 1.4 SDK works great with Eclipse; the download page is located at java.sun.com/j2ee/1.4/download.html.
To obtain Eclipse with the CDT extensions, visit www.eclipse.org\downloads and click on the Download Now link; you will be directed to a list of mirrors where you can download the latest release of the Eclipse platform. Those using BitTorrent will find a link for their BT client adjacent to the link.
After downloading Eclipse, uncompress it into a folder and launch Eclipse. The Eclipse download page will detect the OS of your computer, and the download link will be a zip file for windows users or a gzip tar for Linux users.
CDT project can be installed by using the Update Wizard. Select Help | Software Updates | Find and Install. In the wizard, select the Search for New Features to Install and click Next. In the Update Sites to Visit page, click on the New Remote Site button. A small dialog will appear, in the name field, which is just informational; enter CDT and in the URL field type in download.eclipse.org/tools/cdt/releases/eclipse3.1. Click on OK to save your changes. The CDT site will appear in the list of sites. Click on the checkbox next to CDT and click Finish. The Update wizard will help you locate a mirror and then present you with a license agreement before installing. Eclipse will ask you to restart after completing the installation.
(story continues below sponsor)
Workspaces, projects, and cross-compilation
When the Eclipse project started, you were asked to select a workspace, the key organizing element in Eclipse. Workspaces can contain several projects, and each project then contains resources, which may be files, folders, or links to other files or folders. Workspaces contain the meta-information about projects therein such as build order, how you’ve configured your Eclipse settings, and other information such as your code management system’s connection information. The project within the workspace contains the information about how to build the resources contained therein.
To create a project, select the File | New | Managed Make C Project, supply a name (let’s be creative and use “test”), and press the Finish button. You can then create a file within the test project via File | New | File. We’ll be creative here and call the file main.c and populate it with the classic:
When you save the file, Eclipse will automatically compile it with the gcc compiler on your path. For most users, this is exactly the right thing; however, embedded users will want to invoke a cross-compiler for the target system. CDT makes it easy to compile your project with a cross-compiler. Right click on the project, select Properties, click on C/C++ Build. The Tool Settings panel on the right will have the tools settings used for project build. You can update the tool used by changing the value in the Command field to your compiler; for example Linux users targeting a 74xx board would enter something like:
If your cross-compiler is on your system path, you can just enter the name of the tool. You’ll need to change the tool name for the Linker and Assembler as well.
Congratulations, you’re now cross-compiling with CDT! The next time your project needs to be compiled, CDT will use the cross-tools. Since most folks in the embedded space use a gcc-based compiler, the tool output parsers will work with the cross-compiler, so CDT will be able to match-up build-time errors and warnings to the right lines in your source code.
Before continuing to debugging, it’s worth talking about the differences between a managed versus nonmanaged project. A nonmanaged project relies on the user to create and maintain the project’s make file. For projects already under development or with tricky make environments, using this option allows you to use the existing make files for the projects.
Execution and debugging
To execute or debug your application, you need to leave the comforts of Eclipse and download the binaries produced by the build to your target platform. Depending on the development environment and target board, downloading the code can be as simple as copying them to an exported directory or writing a script to download via FTP or scp. Most users create a simple shell script that gathers the binaries and places them on the target system using the preferred method.
Eclipse resources on the Web
The home of the Eclipse project. Articles and whitepapers covering different aspects of the project posted daily. If you want to learn more about Eclipse or get a download, start here.
This site aggregates Eclipse plug-ins, both free and commercial. Users can rate and comment on the plug-ins. Provides great search\categorization functionality to help you find the plug-in you’re looking for quickly.
Once downloaded, debugging occurs with the tools supplied with the tool chain. Embedded Linux vendors will supply a build of gdb with their tool chain for debugging code on the target and a program called gdbserver used for communication between the target and the host. Gdb can be used as a stand-alone program for command-line debugging or combined with DDD (Data Display Debugger), part of most default Linux installations, for a graphical debugging experience.
As the DSDP matures, execution and debugging on a remote target will become a feature of Eclipse, and users will be deprived of the joys of writing a script for downloading files and manually setting up remote debugging sessions. In the meantime, however, developers will need to rely on these tried-and-true methods for this part of the development cycle.
Summing it all up
As you’ve seen, Eclipse is a powerful, extensible IDE that is rapidly gaining the features expected by embedded developers. Just by downloading the base Eclipse framework and the CDT plug-ins, Eclipse can provide a first-rate code editing and cross-compilation environment, off the shelf. Furthermore, as the DSDP project advances, it will provide the remaining tools so that an embedded engineer can perform all major development tasks from within Eclipse.
Because Eclipse is an open platform, extensions for embedded development represent just a small sampling of the extensions available for Eclipse users. The Eclipse site lists nine top-level projects and more than 25 subprojects addressing developer needs ranging from support for testing tools to graphical modeling frameworks. Other sites abound, such as Eclipse Plug-ins at eclipse-plugins. 2y.net site, which lists more than 1,000 different plug-ins; if you have the need for a particular bit of functionality, chances are you’ll find what you need.
Gene Sally is a product manager with TimeSys. He has been involved with embedded Linux for the past five years and has been an Eclipse user since beta.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)%3B%2B__utmv%3D24122940.mil-embedded.com%3B)
