January 01, 2007
Eclipse Unites the Embedded, Enterprise EnvironmentsRobert Day
Operating in a "standard" environment lets tool developers support a common set of users and vice-versa.
Operating in a "standard" environment lets tool developers support a common set of users and vice-versa.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 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
Eclipse Public License
Seven pillars of Eclipse 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.
Eclipse plug-ins 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 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.
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 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.
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 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.
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
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,
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
|
 |
|
|||||||||||||||||||||||||||
|
|
|
