At EclipseCon 2005, several companies building or considering buildingdevice software development tools in Eclipse met and discussed the needfor more Eclipse extensibility for the embedded space. The primaryfocus of this initial discussion surrounded the technical challenges ofwriting embedded software debuggers in Eclipse, but there was also ageneral desire for more device software extensions in several areas ofEclipse.
Shortly after and in response to this meeting, the DeviceSoftware Development Platform (DSDP ) project was conceived as a way to drive standardization and enhancementof Eclipse for the Device Software space. Wind River Systems officiallyproposed the DSDP project and joined Eclipse as a Strategic Developerin March of 2005. The details of this new proposed top-level projectwere then fleshed out over the next two months, and after a communityreview period, DSDP was officially accepted by the Eclipse Board onJune 8, 2005.
The need for DSDP in embeddeddesign
Engineers in the embedded space know that device software is softwarethat runs on an embedded operating system inside a larger physicalproduct. Device software applications are typically cross-compiled anddeployed on a custom hardware target that is based on a differentconfiguration than the development host.
These custom targets are often constrained by processor type, processorspeed, available memory, and hard real-time responsiveness. Theembedded operating system is usually optimized for these constraintsand is also designed to deal with on-chip peripherals such ascommunication modules, high-resolution timers, memory controllers, etc.
Device software development typically involves three distinctphases:
1) Hardware Bring-up – Inthis phase developers test prototype hardware by verifying basicfunctionality of the target processor(s), memory, and peripherals. Theyrun hardware-oriented diagnostics and confirm the ability to run simplesoftware applications. They provide Platform developers with a stabletarget.
2) Platform Software Development – In this phase developers create the software foundation that sitsclosest to the hardware, including device drivers and board supportpackages. They configure the target operating system and servicesproviding connectivity, management, and security. They provideApplication developers with a stable platform.
3) Application Software Development- In this phase developers create the applications for thecombination of hardware and software that comprise the end product.These developers build, download, and debug applications running on atarget system.
The purpose of DSDP is to provide extensible frameworks andexemplary tools to support activities in each of these developmentphases. The goal is to build upon and extend existing technologies likethe Eclipse Platform, JDT, and CDT, and also to provide assistance toother projects that wish to become more applicable for embeddeddevelopment.
By way of example, the sweet-spot for embedded and device softwareapplications are medical devices (blood-test machines, EKG's), networkequipment (routers, switches), consumer electronics (digital cameras,mobile phones), automotive applications (car infotainment, enginecontrollers), military applications (cruise missiles, combat systems)and industrial devices (manufacturing robots, process instrumentation).
It should be noted that the needs and requirements for theapplication software development phase above are an extension of therequirements for enterprise software development.
We envision that the Device Software Development Platform willprovide a home for embedded extensions across a wide range of existingand future Eclipse projects. Projects like CDT, JDT, and TPTP providegeneral-purpose functionality that appeals to a large audience, whereasthe scope of DSDP is to create complementary extensions to increase theusefulness of these projects for embedded development.
Finally, given the breadth of vertical markets in the devicesoftware space, DSDP strives to be a container for a large collectionof loosely-related subprojects, much like the Tools or Technologytop-level projects in Eclipse.
We envision that some subprojects will be correlated and willrelease together as a platform for a specific set of functionality, butwe also envision other subprojects that may exist to implement aspecific piece of embedded tooling. Other top-level projects, like theEclipse Platform and BIRT, represent a single platform where allsub-projects are coordinated.
Community Participation. Representatives from several companies are involved in one or more ofthe subprojects described in the next section. Given that DSDP is stilla relatively young project and is in the “Incubation” state as definedby the Eclipse Development Process, most of the community participationup to this point has focused on use case definition and architecturediscussions. However, at the time of this writing, several of thesubprojects are now moving to the prototyping and implementation phase.
Participating companies include Accelerated Technologies (MentorGraphics), 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 opensource projects are also participating.
DSDP was initially proposed with two Wind River sponsoredsub-projects, Device Debugging (DD) and Target Management (TM) . A few months after projectcreation, 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 anddebugger views from which several debuggers are derived, most notablythe Java Debugger (JDT) and the C/C++ Debugger (CDT). However, theseAPI's and views are geared towards developing a single application on afast workstation with a simple hierarchical debug model (processor,thread, stack frame).
Debugging software running on embedded devices or remote systemsdiffers from debugging host applications in several ways. First, thehardware model is usually different, with embedded devices oftenemploying multiple processors in multi-core and/or processor + DSPconfigurations.
Second, the memory models are more complex and varied. Memory isusually very limited, often shared between multiple cores, often ofvariable width, and often used in multiple MMU configurations dependingon the target operating system and the device configuration.
Third, debugging device software requires a deeper visibility intothe target, including access to on-chip peripherals, visibility intoon-chip and off-chip processor cache, ability to program target flash,ability to trace instruction flow using on-chip trace buffers, andability to perform low-level target hardware diagnostics.
Fourth, embedded devices often have specialized means for debugaccess that usually require additional hardware and/or target software.This debug access can be slower than typical host application debuggingand can therefore put a premium on overall debugger performance and theamount of interaction the debugger has with the target. Many of theserequirements cannot be well covered today using only the Platform debugAPI's and views or the CDI interface in CDT.
The mission of the Device Debugging (DD) project is to buildenhanced debug models, API's, and views that augment the Eclipse DebugPlatform in order to address the added complexities of device softwaredebugging described above.
As shown in Figure 1, below ,in the current architecture of the Eclipse Debug Platform (Eclipse 3.1and earlier), the debug interfaces enforce a rigid debug elementhierarchy (Target ” Process ” Thread ” Stack Frame):
A debug model provides implementations of specific interfacesrepresenting this hierarchy, e.g. IDebugTarget, and fires debug eventsthat 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 torespond to these selection changes. The Debug view also providesrun-control actions such as run, step and stop, and must be open todrive the debugger.
Participants in the Device Debugging project have found the rigidityof this functionality to be inadequate for their commercial developmentproduct needs. Specifically, the following features are needed:
1) A flexible debug elementhierarchy
2) Model driven view updates
3) Asynchronous interactionsbetween UI and debug model
4) Flexible view wiring (e.g.input to variables view)
5) The ability to debugmultiple sessions simultaneously
In response to these needs, the Eclipse Debug Platform intends tosupport arbitrary debugger implementations, thereby allowing it tointeract with a wide variety of embedded targets and operating systems.Representatives from the Debug Platform team have proposed a solutioninvolving a layer of adaptable interfaces that enable:
1) Customization of view andlabel content
2) Model driven updates
3) Retargettable debuggeractions.
Under this proposal, the Debug Platform will provide defaultimplementations for backward compatibility with the old debug hierarchyand behavior, but users of the platform can also override the structureand behavior of the debugger and its views for custom debuggerimplementations. Below we describe the three areas of customization inmore detail.
Customized view and label content. In Eclipse 3.1, view context isfixed according to the standard debug model. With the proposedarchitecture, debugger views can be populated with customized contentbased on the needs of the debug model. This is handled by a ContentAdapter, as show in the block diagram in Figure 2, below.
For each debugger view, the Content Adapter is responsible forpopulating the nodes in the tree based on the representation that debugmodel would like to present. Similarly, each node has a correspondinglabel adapter used to generate its text. In the case of the Debug View,for example, the view could be customized to contain a new hierarchythat represents a multi-core embedded target:
Other views can be customized in a similar manner by the ContentAdapter. This proposed design also introduces a Request Monitor toasynchronously process the retrieval of data from the model. TheRequest Monitor is a simplification of the Deferred Content Manager inEclipse 3.1.
Model driven view updates. In Eclipse 3.1, view updates were fixedand locked to events from the standard debug model. For example, acontext stopped event updates all debug views.
The proposed implementation (Figure3, below ) supports customized view updates, allowing the modelto dictate how and what it wants to be updated using a model proxy.This also allows the user to select different update modes fordifferent views, e.g. manual update, update only on stopped events andnot when stepping, etc.
This flexibility is important because in an embedded system, thereis often a performance cost associated with updating data in debuggerviews. Model proxies interface a model with a view by firing deltasdescribing what elements have changed in the model and how they shouldbe updated. Model proxies can be implemented on a per-element basis asshown below.
In Eclipse 3.1, the Debug View (Figure 4, below, is solelyresponsible 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 theability to debug without the debug view open, to debug multiplesessions simultaneously, and to retarget debugger actions based on thecustom implementation of the debug model.
The proposed solution moves control of debugging from the Debug Viewitself to a Debug Context Manager. This manager can be driven byselection changes from the Debug View or can be drivenprogrammatically, and the various debugger actions target the activecontext.
In summary this new architecture provides:
1) Flexible elementhierarchies/content per element, per view
2) Customized labels perelement, per view
3) Pluggable model proxies perelement, per view
4) Extensible update policiesper view
5) Pluggable source lookup
6) Retargettable debug actions
7) Flexible view wiring
8) Debugging without the debugview
9) Debugging simultaneoussessions in different views
The Eclipse Debug Platform changes are currently in development andwill be released as experimental API's in Release 3.2 of the EclipsePlatform.
One of the central philosophies of Eclipse is to build good API's, havethe community verify their correctness, lock them down, and thenguarantee their compatibility from release to release. So the rationalefor keeping these new debug API's experimental in Eclipse 3.2 is toallow the broader Eclipse community to prototype against the interfacesfor 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 DeviceDebugging project intends to pursue additional enhancements in debuggerview capabilities, such as:
1) Context-specific views
2) Customized view content
3) Virtual table tree supportand lazy loading
4) Additional hardware-centricdebugger views
Context-specific views are multiple instances of views of the sametype, each one tied to a particular debug context. For example, in adebug scenario where multiple processes on a real-time operating systemare under debug at the same time, Eclipse could have multiple copies ofthe variables view, with each view tied to a different process.
Customized view content refers to additional content adapterimplementations that take a generic Eclipse Debug Platform view andextend its capabilities for device software debugging, e.g. a Registerview that displays and allows direct modification of bit fields.
Virtual table tree support and lazy loading refer to the ability ofa view to only update what is visible in the view and not the entireview content. This enhancement reduces the amount of data retrievalrequired from the embedded target.
Finally, additional views will augment basic debug capabilities withhardware-centric functionality such as flash programming, hardwarediagnostics, processor hardware cache access, etc.
This article is excerpted from apaper of the same name presented at the Embedded Systems ConferenceSilicon Valley 2006. Used with permission of the Embedded SystemsConference. For more information, please visit www.embedded.com/esc/sv.