At EclipseCon 2005, several companies building or considering building device software development tools in Eclipse met and discussed the need for more Eclipse extensibility for the embedded space. The primary focus of this initial discussion surrounded the technical challenges of writing embedded software debuggers in Eclipse, but there was also a general desire for more device software extensions in several areas of Eclipse.

Shortly after and in response to this meeting, the Device Software Development Platform (DSDP) project was conceived as a way to drive standardization and enhancement of Eclipse for the Device Software space. Wind River Systems officially proposed the DSDP project and joined Eclipse as a Strategic Developer in March of 2005. The details of this new proposed top-level project were then fleshed out over the next two months, and after a community review period, DSDP was officially accepted by the Eclipse Board on June 8, 2005.

The need for DSDP in embedded design
Engineers in the embedded space know that device software is software that runs on an embedded operating system inside a larger physical product. Device software applications are typically cross-compiled and deployed on a custom hardware target that is based on a different configuration than the development host.

These custom targets are often constrained by processor type, processor speed, available memory, and hard real-time responsiveness. The embedded operating system is usually optimized for these constraints and is also designed to deal with on-chip peripherals such as communication modules, high-resolution timers, memory controllers, etc.

Device software development typically involves three distinct phases:

1) Hardware Bring-up - In this phase developers test prototype hardware by verifying basic functionality of the target processor(s), memory, and peripherals. They run hardware-oriented diagnostics and confirm the ability to run simple software applications. They provide Platform developers with a stable target.

2) Platform Software Development - In this phase developers create the software foundation that sits closest to the hardware, including device drivers and board support packages. They configure the target operating system and services providing connectivity, management, and security. They provide Application developers with a stable platform.

3) Application Software Development - In this phase developers create the applications for the combination of hardware and software that comprise the end product. These developers build, download, and debug applications running on a target system.

The purpose of DSDP is to provide extensible frameworks and exemplary tools to support activities in each of these development phases. The goal is to build upon and extend existing technologies like the Eclipse Platform, JDT, and CDT, and also to provide assistance to other projects that wish to become more applicable for embedded development.

By way of example, the sweet-spot for embedded and device software applications are medical devices (blood-test machines, EKG's), network equipment (routers, switches), consumer electronics (digital cameras, mobile phones), automotive applications (car infotainment, engine controllers), military applications (cruise missiles, combat systems) and industrial devices (manufacturing robots, process instrumentation).

It should be noted that the needs and requirements for the application software development phase above are an extension of the requirements for enterprise software development.

We envision that the Device Software Development Platform will provide a home for embedded extensions across a wide range of existing and future Eclipse projects. Projects like CDT, JDT, and TPTP provide general-purpose functionality that appeals to a large audience, whereas the scope of DSDP is to create complementary extensions to increase the usefulness of these projects for embedded development.

Finally, given the breadth of vertical markets in the device software space, DSDP strives to be a container for a large collection of loosely-related subprojects, much like the Tools or Technology top-level projects in Eclipse.

We envision that some subprojects will be correlated and will release together as a platform for a specific set of functionality, but we also envision other subprojects that may exist to implement a specific piece of embedded tooling. Other top-level projects, like the Eclipse Platform and BIRT, represent a single platform where all sub-projects are coordinated.

Community Participation. Representatives from several companies are involved in one or more of the subprojects described in the next section. Given that DSDP is still a relatively young project and is in the "Incubation" state as defined by the Eclipse Development Process, most of the community participation up to this point has focused on use case definition and architecture discussions. However, at the time of this writing, several of the subprojects are now moving to the prototyping and implementation phase.

Participating companies include Accelerated Technologies (Mentor Graphics), AMI Semiconductor, Apogee Software, Freescale, Digi, HP, IBM, Intel, MontaVista, Nokia, PalmSource, QNX, ShareME Technologies, SonyEricsson, Sybase, Texas Instruments, Timesys, Wind River Systems, and Wirelexsoft. Representatives from the EclipseME and Antenna open source projects are also participating.

DSDP was initially proposed with two Wind River sponsored sub-projects, Device Debugging (DD) and Target Management (TM). A few months after project creation, two additional projects were added, Mobile Tools for the Java Platform (MTJ) and Native Application Builder (NAB).

Device Debugging Mission
The Eclipse Platform project contains a set of debugging API's and debugger views from which several debuggers are derived, most notably the Java Debugger (JDT) and the C/C++ Debugger (CDT). However, these API's and views are geared towards developing a single application on a fast workstation with a simple hierarchical debug model (processor, thread, stack frame).

Debugging software running on embedded devices or remote systems differs from debugging host applications in several ways. First, the hardware model is usually different, with embedded devices often employing multiple processors in multi-core and/or processor + DSP configurations.

Second, the memory models are more complex and varied. Memory is usually very limited, often shared between multiple cores, often of variable width, and often used in multiple MMU configurations depending on the target operating system and the device configuration.

Third, debugging device software requires a deeper visibility into the target, including access to on-chip peripherals, visibility into on-chip and off-chip processor cache, ability to program target flash, ability to trace instruction flow using on-chip trace buffers, and ability to perform low-level target hardware diagnostics.

Fourth, embedded devices often have specialized means for debug access that usually require additional hardware and/or target software. This debug access can be slower than typical host application debugging and can therefore put a premium on overall debugger performance and the amount of interaction the debugger has with the target. Many of these requirements cannot be well covered today using only the Platform debug API's and views or the CDI interface in CDT.

The mission of the Device Debugging (DD) project is to build enhanced debug models, API's, and views that augment the Eclipse Debug Platform in order to address the added complexities of device software debugging described above.

Technical Plans
As shown in Figure 1, below, in the current architecture of the Eclipse Debug Platform (Eclipse 3.1 and earlier), the debug interfaces enforce a rigid debug element hierarchy (Target " Process " Thread " Stack Frame):

Figure 1

A debug model provides implementations of specific interfaces representing this hierarchy, e.g. IDebugTarget, and fires debug events that cause view updates, action updates, and source lookup in the IDE.

Selection changes in the debug view change the active debug context, and the various debugger views, e.g. variables, are hardwired to respond to these selection changes. The Debug view also provides run-control actions such as run, step and stop, and must be open to drive the debugger.

Participants in the Device Debugging project have found the rigidity of this functionality to be inadequate for their commercial development product needs. Specifically, the following features are needed:

1) A flexible debug element hierarchy
2) Model driven view updates
3) Asynchronous interactions between UI and debug model
4) Flexible view wiring (e.g. input to variables view)
5) The ability to debug multiple sessions simultaneously

In response to these needs, the Eclipse Debug Platform intends to support arbitrary debugger implementations, thereby allowing it to interact with a wide variety of embedded targets and operating systems. Representatives from the Debug Platform team have proposed a solution involving a layer of adaptable interfaces that enable:

1) Customization of view and label content
2) Model driven updates
3) Retargettable debugger actions.

Under this proposal, the Debug Platform will provide default implementations for backward compatibility with the old debug hierarchy and behavior, but users of the platform can also override the structure and behavior of the debugger and its views for custom debugger implementations. Below we describe the three areas of customization in more detail.

Customized view and label content. In Eclipse 3.1, view context is fixed according to the standard debug model. With the proposed architecture, debugger views can be populated with customized content based on the needs of the debug model. This is handled by a Content Adapter, as show in the block diagram in Figure 2, below.

Figure 2

For each debugger view, the Content Adapter is responsible for populating the nodes in the tree based on the representation that debug model would like to present. Similarly, each node has a corresponding label adapter used to generate its text. In the case of the Debug View, for example, the view could be customized to contain a new hierarchy that represents a multi-core embedded target:

Target
     Core 1
           Process 1
                Thread 1
                       Stack Frame
                Thread 2
                       Stack Frame
           Process 2
    Core 2

Other views can be customized in a similar manner by the Content Adapter. This proposed design also introduces a Request Monitor to asynchronously process the retrieval of data from the model. The Request Monitor is a simplification of the Deferred Content Manager in Eclipse 3.1.

Model driven view updates. In Eclipse 3.1, view updates were fixed and locked to events from the standard debug model. For example, a context stopped event updates all debug views.

The proposed implementation (Figure 3, below) supports customized view updates, allowing the model to dictate how and what it wants to be updated using a model proxy. This also allows the user to select different update modes for different views, e.g. manual update, update only on stopped events and not when stepping, etc.

Figure 3

This flexibility is important because in an embedded system, there is often a performance cost associated with updating data in debugger views. Model proxies interface a model with a view by firing deltas describing what elements have changed in the model and how they should be updated. Model proxies can be implemented on a per-element basis as shown below.

Debugger Actions
 In Eclipse 3.1, the Debug View (Figure 4, below, is solely responsible for driving the debugger: running, stopping, stepping, initiating source lookup, forcing updates of other Debug Views, etc. This is limiting for several reasons. Debugger implementers want the ability to debug without the debug view open, to debug multiple sessions simultaneously, and to retarget debugger actions based on the custom implementation of the debug model.

Figure 4

The proposed solution moves control of debugging from the Debug View itself to a Debug Context Manager. This manager can be driven by selection changes from the Debug View or can be driven programmatically, and the various debugger actions target the active context.

In summary this new architecture provides:
1) Flexible element hierarchies/content per element, per view
2) Customized labels per element, per view
3) Pluggable model proxies per element, per view
4) Extensible update policies per view
5) Pluggable source lookup
6) Retargettable debug actions
7) Flexible view wiring
8) Debugging without the debug view
9) Debugging simultaneous sessions in different views

Release Plans
The Eclipse Debug Platform changes are currently in development and will be released as experimental API's in Release 3.2 of the Eclipse Platform.

One of the central philosophies of Eclipse is to build good API's, have the community verify their correctness, lock them down, and then guarantee their compatibility from release to release. So the rationale for keeping these new debug API's experimental in Eclipse 3.2 is to allow the broader Eclipse community to prototype against the interfaces for one entire release cycle before the API's become official.

Next Steps for Device Debug
Once these new Eclipse Platform Debug API's are released, the Device Debugging project intends to pursue additional enhancements in debugger view capabilities, such as:

1) Context-specific views
2) Customized view content
3) Virtual table tree support and lazy loading
4) Additional hardware-centric debugger views

Context-specific views are multiple instances of views of the same type, each one tied to a particular debug context. For example, in a debug scenario where multiple processes on a real-time operating system are under debug at the same time, Eclipse could have multiple copies of the variables view, with each view tied to a different process.

Customized view content refers to additional content adapter implementations that take a generic Eclipse Debug Platform view and extend its capabilities for device software debugging, e.g. a Register view that displays and allows direct modification of bit fields.

Virtual table tree support and lazy loading refer to the ability of a view to only update what is visible in the view and not the entire view content. This enhancement reduces the amount of data retrieval required from the embedded target.

Finally, additional views will augment basic debug capabilities with hardware-centric functionality such as flash programming, hardware diagnostics, processor hardware cache access, etc.

Doug Gaff is engineering manager on Wind River's commercial Eclipse-based device software suite and PMC Lead for the Eclipse.org Device Software Development Platform (DSDP). 

This article is excerpted from a paper of the same name presented at the Embedded Systems Conference Silicon Valley 2006. Used with permission of the Embedded Systems Conference. For more information, please visit www.embedded.com/esc/sv.