The embedded software world has always been a separate entity from the enterprise or desktop worlds. Some say that embedded software tools lag behind what's available to native developers; others point out that the complexity of the requirements for embedded tools means that they are far more advanced than their enterprise equivalents. The truth actually lies somewhere in the middle, where the lack of bit-fiddling complexity in the enterprise world has allowed the tools to become more standard, productive, and user friendly.

Until recently, software development technology in these two domains has remained very different. Some embedded companies have tried to use enterprise solutions such a Visual Studio to give a user-friendly development environment. But requirements like multi-host, multi-target, RTOS awareness, and embedded connection requirements has made these integrations long and painful, and also not something that's supported by the integrated development environment (IDE) developer. Other embedded companies have chosen to write their own or acquire their own IDEs, but this often leads to proprietary interfaces and moves away from the core competency of the embedded vendor, making it a support nightmare.

So what's changed? The answer lies in an open-source IDE that, although born and used in the enterprise world, has the flexibility of technology and licensing that lets embedded vendors build elegant, user-friendly embedded tools that take advantage of their core competencies, rather than compromise them.

This IDE is called Eclipse. Over the last couple of years, a significant number of embedded development environments have moved to Eclipse as the platform of choice. Many RTOS vendors offer an Eclipse environment, and a handful of chip/core companies now provide links to Eclipse for software developers wanting to program to their architecture.

Interestingly enough, the shift from proprietary to open-standard IDE has been driven both by embedded software developers and embedded vendors. The software developers were frustrated by having to change development environments every time they changed a key IC or RTOS, and the embedded vendors were equally frustrated having to build and maintain IDEs. The Eclipse environment offers a standard interface regardless of processor architecture, host platform, or embedded RTOS that makes it straightforward for end users to migrate their application code and for embedded vendors to migrate their tools.

For those of you wondering why this enterprise-based IDE should be any better for embedded developers than other enterprise tools, there are a number of compelling reasons why Eclipse has caught on and is here to stay.

Complete independence
Most enterprise development tools are specific to a certain type of application on a particular platform, usually in a specific language. For example Visual Studio is really targeted at users developing for a Windows host and environment. If you wanted to use it for a Linux host, then life becomes more complicated. Eclipse has been described as an "environment for anything and nothing in particular," and that's one reason why it's suited to embedded development, in that it's not specific to any enterprise development type.

Eclipse achieves this by the notion of plug-ins. The Eclipse platform isn't specific to any language, host, or application development but is enabled by plugging in tools that are specific to a particular requirement. So, if Java development is being used, all the plug-in tools will be specific to Java development. The same applies to embedded development--traditional embedded compilers, debuggers, build environments, and profilers can plug-in to this standard environment, and Eclipse then becomes an embedded development environment.

Example projects
Although the Eclipse framework isn't specific to any type of application development, there are a large number of open source Eclipse projects that are. These projects use the plug-in mechanism in Eclipse, and the Eclipse environment then becomes specific to the type of application development specified by the project. Because these projects are provided using the same open-source license model as the Eclipse platform, they can be downloaded, used as examples, templates, or starting code base for specific application requirements. For embedded development, a few projects provide a basis for a comprehensive embedded development environment that can be tailored to meet specific application, IC, or RTOS needs.

Eclipse Public License
A key factor in providing embedded development tools is that they're generally very complex pieces of software that need to be continuously evolved and maintained to meet the changing needs of embedded developers and match the fast pace at which the embedded industry produces new technology. Hence, open-source business models often don't support embedded vendors' abilities to build commercial products that can be evolved and maintained. The Eclipse Public License is special in this regard and allows commercial companies to sell their development tools integrated with the open-source platform and projects. The benefit to embedded users here is huge. They get a software environment that's enterprise-strength, but with tools that are specific to their requirements--the user does needn't "hack" all these tools together himself, which is often the open-source way, but is presented with a truly integrated open-standards"based embedded development system.

Seven pillars of Eclipse
As noted, because enterprise and embedded are seen as such different worlds, it becomes difficult to get enterprise product companies to support or even acknowledge the embedded needs. As a result, the products move closer to the needs of the enterprise developer, ignoring any special needs that embedded developers have. Not so with Eclipse. The Eclipse Foundation now has over 30 member companies that are either embedded companies or actively serve the embedded industry. These range from RTOS vendors, IC companies, and embedded tools providers.

Recognizing how important the needs of embedded software developers are to the Eclipse foundation, the embedded world is now acknowledged as being one of the seven pillars of the Eclipse foundation (Figure 1). These pillars show the key application types that the Eclipse world is using Eclipse for. And for the embedded world, it's important that it be so visible. Along with some key projects, it ensures that the needs of embedded developers will continue to be met by this technology.

View the full-size image

Eclipse plug-ins
The Eclipse architecture is designed so that the Eclipse framework can accept any number of plug-ins. Plug-ins can be full environments, standalone applications, or just additional windows in an existing plug-in. There are strict guidelines to writing the plug-in with the plug-in API, which helps to ensure consistency across applications. But there's 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 (allowing easy programming and portability), and the Eclipse development environment (for creating Eclipse plug-ins) comes with a couple of useful toolkits. 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.

The whole plug-in doesn't have to be written in Java, just the GUI part, and hence porting legacy C or C++ applications to be an Eclipse plug-ins needn't involve total code rewrites. This is good for embedded vendors, but also embedded developers who often have proprietary tools, which can now be run under the same environment.

When writing a commercial plug-in, it's usually best to look at the Eclipse projects to find one that's best suited to the sort of application development being undertaken. The embedded tools can then use this as a template or example, or actually plug in to the project to offer even more reuse of the open-source technology.

Eclipse projects
On top of the Eclipse platform are a number of projects and sub-projects 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. Eclipse Foundation membership isn't a required for participation in, or even leadership of, these projects.

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

Figure 2 shows the Eclipse architecture, including the most significant projects, called top-level projects. The projects highlighted in yellow are currently most relevant to embedded systems development.

View the full-size image

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 its IDE and includes a build and make GUI that comes with the GNU C/C++ compilers. The GUI allows for an easy connection to other embedded cross compilers. A C and C++ context sensitive editor is included, and for embedded debug, there's an Eclipse-based GUI on top of the GNU GDB debug engine, allowing seamless interaction between edit, build, and debug of embedded software. As this project is used as a plug-in perspective to the standard Eclipse platform, it's easy for other tools to "plug in" and allow a full embedded systems development environment to take advantage of the benefits of open-source for many of the common build and debug elements.

The Device Software Development Project (DSDP) is a relatively new project that looks at many of the aspects of embedded system debugging. Initially, DSDP focuses on building infrastructure for target management, device debugging, mobile Java, and embedded GUIs. It also encompasses eRCP which is a project that ports a stripped down version of the Eclipse platform that's suited for actually running on an embedded system, providing a Java-based platform for running embedded applications under. Another key element being worked on in the initial phase of this project revolves around how a debugger communicates to an embedded target system, trying to bring in some open standards for this communication into Eclipse.

The Test and Performance Tools Platform (TPTP) isn't specifically aimed at embedded systems development, but offers some interesting plug-ins and example programs that can help show and use embedded test and performance software. It even act as an example front-end GUI for these very embedded specific products.

These projects will form the basis for many different embedded software tools, which means that the commonality between different commercial embedded tools isn't just at the framework level. They also share common components from the projects.

Enterprise plug-ins
Where life starts to get interesting is in the crossover between enterprise and embedded development. Now that we've established that we can use the same Eclipse environment (without modification to the platform itself), we can look at development tools and aids that aren't specific to either but that embedded developers can take advantage of. An easy to understand example is source code and version management. A number of well known tools allow code to be tracked, versioned, and managed, and these tools work on source files regardless of what language, target processor, or compilation and build tools are used. Many of these tools now have an Eclipse plug-in as the front end, and hence can be used next to the embedded development tools that also have an Eclipse front-end. Well-known examples are Clearcase, CVS, and Subversion (which has its own proposed Eclipse sub-project, SVN).

Other example plug-ins include editors, requirements management, high-level design tools, code profilers and beautifiers, project planners, documentation tools, and Web design tools (for those projects with embedded Web servers). Each of these tools often has its own perspective, which is an Eclipse term for a collection of windows together in the Eclipse framework. Moving from one perspective to another (such as from a build perspective to debug) is as easy as a single button click, without having to leave the Eclipse environment.

The Eclipse platform and the Eclipse projects can be accessed at www.eclipse.org. To access both commercial and open-source plug-ins, go to the Eclipse plug-in central (EPIC) at www.eclipseplugincentral.com. The screen shot in Figure 3 shows the wide variety of plug-ins currently available for Eclipse.

View the full-size image

Another key feature of using the Eclipse framework is the ability for software developers to create their own plug-ins. These could augment the look and feel of embedded products or be stand-alone plug-ins that co-exist with embedded plug-ins. One issue with embedded development is that the tools used to develop embedded applications generally aren't specific to the application itself, and hence developers find themselves having to write application-specific tools and environments to help develop or test their systems. These tools can now be ported to or written for the Eclipse environment and can take advantage of other plug-ins also in use. For example, an application test tool could take advantage of the embedded debug-connection mechanism to ping the target for information but then display it in its own application-specific window.

The future
There's no doubt that Eclipse is here to stay as the de facto embedded development environment, and what will now start to occur is developers and embedded tools vendors taking advantage of the true plug and play nature of applications to create more productivity examples for embedded development.

Two interesting examples of this coming together are PlugInFests and Mash-Ups. PlugInFests are where different tools providers meet and plug-in each others' Eclipse-based tools. These events let vendors understand how well the tools operate together and spurs opportunities for tighter integration in the future. These events also enable embedded vendors to work more closely together and bridge the gap between enterprise lifecycle tools and embedded development tools.

Mash-ups are normally associated with the music industry and are the coming together of two or more different songs (often different music types or eras) to make a new super song. This concept is now being brought into software applications, where two different applications are brought together to make a super application. Examples of these applications are those that combine with Google maps. Thus, realtor listings can be combined with Google maps to show available houses, or a local police force can link its crime database with Google maps to show where crimes are being committed.

For the embedded software world, we need to start thinking about how we can take enterprise applications and mash them with embedded tools. Examples could combine embedded network data with sophisticated network mapping tools to display an embedded node's performance. Or embedded trace tools can be combined with enterprise code-analysis tools to show graphical displays of the embedded system.

One thing is becoming clear--enterprise systems are being connected to more embedded systems. Hence, an environment that spans both will become very important, and the combination of enterprise and embedded tools and development will become even closer.

Robert Day is the vice president of marketing at LynuxWorks. He can be reached at rday@lnxw.com.

Reader Response

This article suffers from the same Eclipse disease everything else Eclipse has. Even the Eclipse based tool my own company makes has it.

The help file has a breathless description of how great the tool is because it is Eclipse and it is all plug ins. The engineers love it. I DO NOT CARE. Tell me how it makes my work easier. How do I get productive faster. Yes, it is all about me, me, me.

The plug ins make your job easier. I want you as the tool vendor to make my job easier.

-Doug Gibbs
Senior Software Engineer
Xilinx
Longmont, CO

The author responds:

Doug,

Without knowing exactly what sort of software development you are involved in, I will have to give some examples of what embedded developers are facing generally, and how Eclipse (and its plug-ins) could help them and you be more productive.

1) Time to productivity

One of the keys to faster productivity is the time it takes to learn a new product. A problem that embedded engineers have had in the past is the time spent to fully understand the intricacies of a new tool. Because Eclipse is relatively strict with how a plug-in tool interfaces with the Eclipse platform, it means that much of the look and feel of a new tool will be similar to other Eclipse plug-ins. This can be a bit of a pain to tools vendors, who have been used to having free reign with their GUIs, but it allows the users to more quickly get to the complex parts of the plug-ins and hence maximize their productivity using it.

2) Putting the puzzle together

In most embedded designs, products from multiple vendors need to be used. While it shouldn't be your job to make sure they all work together, it has often ended up that way. Eclipse at least offers a common platform that these different tools can plug into, so at least giving some commonality and also GUI guidelines that the vendors need to follow. What is now happening in the Eclipse community, is that the vendors are helping to ensure that these puzzle pieces fit together, taking away the time (and productivity loss) that has often fallen on the users.

3) Utilizing productivity tools

Every software tool that you use should offer a productivity gain and/or making your work easier. One of the strengths of Eclipse is that it opens up a wider set of integrated productivity tools, because you have the whole enterprise development world now available in the same IDE as you use for embedded. Example enterprise products include context sensitive editors, source code and version management tools, code browsers, code checkers and beautifiers, code analysis tools, UML high level design tools. All these types of tool have multiple Eclipse integrated options to choose from, allowing you to pick the most suitable and then use a familiar interface from within your own IDE. Xilinx themselves are using Eclipse to help bridge the gap between software programming and programmable hardware - a place that many software engineers still fear to tread.

4) Changing your scene

Many embedded engineers find themselves working on multiple projects simultaneously (often starting new ones while maintaining old ones). These different projects will often have different characteristics - different processors, different RTOS, different compilers, which usually requires different tools and IDEs and yet another learning curve. With Eclipse based products - the IDE remains the same, the build perspective generally remains the same (obvious compiler changes - but often is hidden by Eclipse in how they are used), the debug perspective gets enhanced to meet the needs of the RTOS or processor, but still has the Eclipse look and feel, but all the productivity tools (shown in 3)) can stay the same and be reused for the new project. This all saves time, makes changing scenes easier, and boosts productivity.

5) Roll your own

Many embedded projects have requirements on tools (especially in testing) that can be very specific, and hence not provided by the open source or commercial tools - so internal tools need to be developed. The same Eclipse environment used for embedded software development can also download the open source Java Development Tools (JDT) and the Plug-in development environment (PDE), that allows users to build their own tools to plug into Eclipse. These plug-ins can have their own perspective, or just offer a new view in an existing perspective. So, the embedded IDE with all the software productivity aids can also be customized to meet very specific project requirements.

If you want to elaborate more on your own development issues, then I could certainly try to offer some Eclipse-based suggestions (either open source or commercial) that could help you. If you can get to the Bay Area in March, then EclipseCon has a track specifically for the embedded developers, and I am hosting a panel that will look at how Eclipse can make your life better (http://www.eclipsecon.org/2007/)

I appreciate the feedback, it's nice to hear what embedded developers think of Eclipse.

Cheers,
Robert
-Robert Day
Vice President, Marketing
LynuxWorks
San Jose, CA

I have thought the same thing about Eclipse that Doug notes many times, and I have to say that Robert's long response makes things no better. Yes, a modular tool environment has lots of potential, is capable of making life easier and better, yada yada yada. No one diagrees with this.

However, I have yet to see anyone step up and say "this is specifically what Eclipse and a specific set of plug-ins allows you to do, which you cannot presently do with other tools as easily or well, and which will make a developer's life easier and better."

I, too, am glad Eclipse developers are so excited about the environment! Maybe some day the rest of us will have a reason to be excited about it also.

-Randall Smith
Senior Staff Engineer
Qualcomm, Inc.
San Diego, CA