This project proposal is in the Proposal Phase and is posted here to solicit community feedback, additional project participation, and ways the project can be leveraged from the Eclipse membership-at-large. You are invited to comment on and/or join the project. Please send all feedback to the eclipse.dsdp newsgroup.
The Device Software Development Platform is a proposed open source Top Level Project of eclipse.org. The Charter describes the organization of the project, roles and responsibilities of the participants, and top-level development process for the project.
In the Enterprise , applications are typically developed and executed on the same host platform, typically Windows, Linux, or a Unix variant. These applications may also be run on a virtual machine or a web browser. Device software development is vastly more complicated for a number of reasons. First, applications must be cross-compiled and deployed on a target or “embedded system,” which is usually based on a different hardware configuration and operating system. Because of this, device software development heavily relies on a stable custom hardware and software platform and is therefore closely tied with hardware bring-up and the configuration of real-time operating systems.
Second, the device or target system is often constrained by processor type, speed and available memory and must respond to external inputs within a guaranteed period of time, typically 10 ms or less. Third, depending on the industry and type of application, devices may have many peripherals, may be headless (without display), may run none or multiple operating systems, and may have one or many connection interfaces. The sweet-spot for 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).
Among the key principles on which this project has been initiated, and will be run, are the following:
Leverage Eclipse Ecosystem - A major goal of this project is to apply the application development strengths of the Eclipse Project to the device software development domain. The project will work closely with other Eclipse project areas whenever possible to leverage the capabilities being developed in those areas.
Vendor Neutral - We aim to encourage Eclipse participation and drive Eclipse market acceptance by providing vendor-neutral capabilities and to encourage participation for complementary capabilities through additional projects.
Open, Standards-based Development - Where market adopted standards exist that meet the design goals, our aim is to leverage and adhere to them. Where market adopted standards do not exist, we will develop and publish any new capabilities in the Eclipse open forum.
Incremental Delivery - In order to meet the pent-up demand for a standardized framework for device software development tools, we aim to deliver functionality to the market as rapidly as possible via an incremental delivery model.
Device software development typically involves three distinct phases.
The Device Software Development Platform (DSDP) will provide frameworks and exemplary tools to support activities in each of these phases.
The needs and requirements for the Application Software Development step above can often be viewed as a superset 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 DSDP will create complimentary extensions, thereby increasing the usefulness and applicability of these projects for embedded development. For example, DSDP relies on CDT for generic IDE capabilities for C/C++, but by extending CDT with Target Management and Device Debugging capabilities, device software developers will find much greater value in the overall tools platform for their applications.
The DSDP project will also act as an advisor and resource provider for other Eclipse projects that wish to become more applicable for embedded development. For example, the DSDP project relies on the build system provided by CDT and can help drive requirements and contribute code to support multiple tool chains for different processor variants. We envision that in addition to providing code and infrastructure to Eclipse, part of our role is to ensure a coherent feature set across all top-level projects.
Finally, the DSDP project will focus exclusively on tools for device software development, including embedded rich client applications. It will not focus on additions to operating systems
Wind River Systems, as the submitter of this proposal, welcomes interested parties to post to the eclipse.dsdp newsgroup and ask to be added to the list as interested parties or to suggest changes to this document. The proposed PMC members include:
Project Management Committee
A number of companies that have expressed interest in the project and/or its components thus far. This list will be updated periodically to reflect the growing interest in the Device Software Development Platform.Interested Companies
We see a need for projects to support the device software phases outlined above in the following areas. Please note that this list is far from complete since device software development is a vast domain driven by advancements in both software and hardware design.
Initially, we'll focus on Target Management and Device Debugging. We encourage and intend to recruit participation from other vendors and developers to lead projects that will focus on areas mentioned above and any other related technologies.
A lot of software is developed that needs to be run on a remote system. Developers have to connect to these systems to download software and data, start and stop programs, debug programs and more. The goal of the Target Management project is to provide data models and frameworks to manage remote systems, their connections and their services. Although Target Management is a fundamental requirement in the embedded world, it could also be used in the Enterprise for remote development to manage connections between clients and servers to build and debug applications remotely.
There are many different processors, boards, operating systems, connection protocols (e.g. TCP/IP, serial, JTAG, proprietary) and services (console, query, run control, ping, download, events, debug) used. Often many of these interfaces are present at the same time, so developers need to manage the different devices and their configurations. The Target Management project will provide plug-ins to simplify configuration and management of a wide range of connection mechanisms.
A first attempt for a “Remote System (Target) Definition” has been made in the CDT. The proposal discusses a framework that provides an abstraction of connections and services on a remote target. Such an abstraction will allow for the creation of tools that unify the access to remote targets and simplify the creation of launch configurations. For details, see Bugzilla entry: Bug 65471
We propose to extend this work in the following steps:
The target manager plugin created in this project will provide general-purpose capabilities to manage connection configurations, monitor status, transfer data, and launch and debug programs on remote devices based on gdb. Vendors can extend the target manager with connection mechanisms specific to their environment and operating system.
Debugging software running on embedded devices or a remote system can be quite different from debugging host applications. 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 the Platform debug API's and views or the CDI interface in CDT.
This project will focus on addressing the specific needs of device debugging and include the following activities:
The overriding goal of the Device Debugging Project is to create a framework that enables other Eclipse plug-ins to communicate with and control a device through a common API, regardless of the underlying target connection. The API needs to be powerful enough to support debugging engines for conventional processors, DSPs, network and I/O processors.
The focal point for this effort will be changes and extensions of the platform debug model that is the core API between debug engines and debug views today. The goal is to make the platform debug model work also for device debugging and to create API's and views that work well with the many different capabilities of current and future debug engines. These different capabilities need also be reflected in the view implementations, e.g. through the usage of well chosen extension points.
However, it may turn out that this is not possible and that a new API for device debugging is needed. The success of this project will depend on the amount of help and support received from the team currently working on the platform debug API's.
Back to the top