Design Article
PRODUCT HOW-TO: Doing embedded design with an Eclipse-based IDE
John Carbone
12/16/2008 12:30 AM EST
Thanks to the broad provisions of the Eclipse framework, it is possible to create an optimized-for-embedded Eclipse IDE at a price point in line with the open-source philosophy.
By combining Eclipse, the GNU C/C++ toolchain, and a host-target debug probe in a complete, integrated, and commercially supported package, Express Logic has delivered BenchX, an enhanced, embedded-optimized, Eclipse-based IDE, which can be licensed for only $1,000 per developer seat.
As shown in Figure 1 below, this IDE combines an embedded optimized Eclipse IDE, GNU C/C++ compiler and toolchain, and a host-target debug probe in a complete, integrated, and commercially supported package.
 |
| Figure 1. Combining Eclipse with GNU and a host debug probe |
To simplify the multiple perspectives found in Eclipse/CDT, a single "Embedded Perspective" provides all the necessary view windows relevant to embedded system development. This greatly reduces the complexity of using Eclipse for embedded systems.
The BenchX Perspective
The BenchX perspective provides access to all the views and tools necessary to create, edit, assemble, compile, link, locate, execute, and debug an embedded application. Figure 2 below shows the BenchX Embedded Perspective.
 |
| Figure 2. Eclipse for the Bemch X perspective |
In this example, the Eclipse build process has been simplified to reflect the requirements of embedded development and the preferences of embedded developers. Many build buttons, menus, dialogs and other options that are not used in embedded development have been eliminated, deactivated ("grayed-out"), or relegated to lower-level menus to keep them from complicating the more typical use modes of an embedded IDE.
Also, the Eclipse debugger interface has been modified to make it more suitable for embedded development, where a remote target connection will normally be made when debugging a program under development. Figure 3 below shows the debugger in action.
 |
| Figure 3. The Eclipse debugger in action |
Express Logic also modified the Eclipse debugger GUI to remove menus, buttons, and options not used in embedded development. The resulting user experience is similar to that of a proprietary IDE designed from the ground up for embedded use.
In addition to modifying the debugger GUI, the BenchX tools include a capability critical for embedded development " RTOS kernel awareness. With no real counterpart in the enterprise world, it's not surprising that Eclipse does not have the ability to assist the developer in viewing RTOS kernel objects of interest.
Embedded development, in contrast to enterprise work, requires the developer to frequently monitor the status of RTOS kernel objects such as threads, semaphores, and queues, to see how the application is using them and whether that use is as intended.
Even with the many changes made to make it more suitable for embedded development, because it still adheres strictly to the Eclipse interface standards, this IDE may be enhanced through the addition of Eclipse plug-in tools components such as compilers, text editors, and static analysis tools.
Users can take full advantage of the over one-thousand Eclipse plug-ins available to improve development productivity (Go to Eclipse Plugin Central http://www.eclipseplugincentral.com/ for a complete list of available plug-ins). As a result, BenchX provides a simple yet fully modular foundation that is open for upgrade and expansion thanks to its Eclipse heritage.
Building and Debugging an Embedded App
With an understanding of its Eclipse origins and the embedded extensions that have been added, let's look at how a developer would use an embedded-enhanced Eclipse-based IDE such as BenchX to put together a simple application program.
Users initially will use the Workspace Launcher dialog. An Eclipse "workspace" is simply a subdirectory that contains the files related to a number of projects. The "hello_world.c" file is selected and its contents are displayed in the "hello_world.c" source code window, which is where all editing of the source code takes place.
At this point, the Simple_Hello_World workspace is open and ready for a program to be built. In the BenchX Perspective, this is accomplished simply by selecting the "Build Project" button as shown in Figure 4 below.
 |
| Figure 4. Starting a project |
Selecting the "Build Project" button causes the assembly and C files that are part of the "hello_world_demo" project to be built. Default compiler and linker settings will be used, unless the developer selects custom settings prior to the build.
This one-click project build is common in embedded development and is repeated after each iteration involving a coding change to the program. Thus, it's important to make it as simple as possible with a single click.
At this point, the standard hello world demonstration is built and an executable file is created, ready to be run and debugged.
|
|
|
|
|
jaranguren
12/22/2008 11:21 AM EST
Besides the RTOS awareness of the product described in the article, why would one want to pay (even as "low" as US$ 1000) for something that is already for free? It is available for ARM processors (Yagarto, for instance) Xilinx's Microbalze and PPC EDK, Altera's Nios-II, and many more ??
Sign in to Reply
ericshufro
12/22/2008 2:00 PM EST
Eclipse grossly misses the boat as far source file organization and project paths are concerned. In fact, Eclipse is MUCH harder to use than some of the retail IDE's and in some ways, fails to provide a smooth experience.
For example, suppose you have 2 products that you maintain :
\CompanyRoot\Software\Product_01\
\CompanyRoot\Software\Product_02\
Now suppose you have 100's of projects using various evaluation boards and are dependent on these two source branches.
\CompanyRoot\Software\Examples\Board\Compiler\Example_01
\CompanyRoot\Software\Examples\Board\Compiler\Example_02
Keep in mind the source branches above are version controlled and new revisions are checked in and labeled periodically. The example projects are NOT subdirectories of the products or vice versa.
Would you prefer to :
1) Copy the product source files into each project directory?
2) Keep the product sources in their relative paths on the hard disk and ensure you are building the correct version of a product for a particular example?
If you choose #1, then you end up with MANY copies of the same product source files for each example. Each of these copies may require maintenance.
If you choose #2, then you have to update only 1 source location to update all projects.
Eclipse fails for option #2. If you link projects into the source tree, then all subdirectories are also linked. What if a particular product has a subdirectory called ports containing 100's of processor ports? Surely you dont want all of them included in the project too!
If you add files one at a time, then there is no source file organization in the project tree.
I much prefer the drag and drop capabilities of modern, paid for IDE's where i choose where files are located on the disk and how the files appear in the project soure tree.
As an aside, it would be nice if Eclipse added a path to files added to the tree automatically.
--Eric Shufro
Sign in to Reply