Skip to main content
Jump to: navigation, search


DSDP Packaging Effort

Towards an Integrated Open "Eclipse for Embedded" Package

With commercial vendors, Eclipse has become a de-facto standard for integrated tooling for embedded software development. Much of these commercial solutions is based on the DSDP projects. But while the DSDP projects provide an impressive collection of features, it's hard to assemble them to a complete, working environment.

A single, integrated Open Source package for device software development built on top of the DSDP projects is still missing. What's holding us off from creating a DSDP package similar to what the EPP Project already provides for Java Development, C/C++ Development, JEE Development and Reporting?

We've had a discussion about this with lots of people from the Community at the EclipseCon 2008 DSDP BoF Session, and some of the more interesting results of this discussion were (Raw Notes):

What is the target audience?

  • Everybody dealing with embedded technology, who doesn't want or cannot purchase a commercial solution:
    • Silicon vendors who'd like to give access to their stuff for free; they might actually help out with personnel, money, hardware or IT infrastructure, but we should remain Open and Vendor Neutral, not engage too much with one vendor
      • Still, even a Vendor Neutral Eclipse for Embedded Distribution could be a very interesting vehicle for Silicon Vendors to base their own stuff on, to simplify evaluation packages for them
      • A popular website from the Packaging Effort could be a very interesting vehicle for vendors to announce add-on services (e.g. provide cheap hardware boards for students)
    • Universities - offering courses for Embedded, they need some free tooling. The FIRST US Robotics competition is a similar example.
    • Students - getting them acquainted with embedded technology easily
    • Embedded Runtime Component vendors - who need an embedded host and tooling for their specific components to run, demo and evaluate on
  • Do we need to fear negative reactions from Embedded Vendors?
    • Unlikely in the beginning, because the target audience wouldn't spend money anyways
    • Probably even positive, because package would be building foundation for embedded vendors to base on more easily
    • If plain Open Source becomes "too good", vendors might start losing some customers, but that is normal as the commoditization bar is constantly rising anyways -- vendors need to stay on top of technology and offer competitive end-to-end solutions

Interested Parties, who could help out?

What components could go into Eclipse for Embedded packages?

  • Embedded Development can be separated in two, mostly mutually exclusive, areas and some generally interesting related technology:
    • Embedded Java - MTJ, eRCP, Equinox, Eclipse Runtime Project
    • Embedded Native (C/C++) - CDT, Target Management, Device Debugging, NAB, TmL, RTSC, VPP, Orbit projects
    • Related Tooling Technologies
      • GNU tooling is a perceived standard (gcc, gdb, QEMU). But the license is incompatible with the EPL, how to handle that?
      • General editing support like Columns4Eclipse, see also bug 19771; Mylyn, Subversive
      • Emulations like QEMU, VirtualBox, VMWare, XEN and the like. TmL is working on a framework for these.
      • UI Toolkits - NAB and the MWT Libraries to be pre-installed on an Emulator; eRCP for Java
      • Multicore and connectivity - the Target Management project and especially the TCF Component are targeting these
      • System-on-a-chip, ESD Level simulation - the VPP project proposal is targeting these
      • Profiling, Performance monitoring - the TPTP project should be the foundation for this in Open Source, is it really applicable? Also has a runtime aspect, could TM TCF probably help?
      • Modeling - An increasing amount of embedded software is created with the help of Modeling tools like OpenArchitectureWare, UML, State Machines etc
    • Related Runtime Technologies
      • Pre-configured libraries or Kernels with Sources, pre-built, CDT indexer pre-build: For instance Linux Kernel; Embedded Linux from Code Sourcery, ACE+TAO, Free RTOS's?
      • UI Libraries - MWT for use with NAB, GTK, to be pre-installed on an Emulator; eRCP for Java
      • Networking emulations, middleware and the like -- again, TmL is investigating end-to-end simulation solutions.

  • Embedded tooling typically needs to be highly configurable -- different configurations based on desired target architecture and runtime components. We'd ultimately need an installer that can select and download the desired stuff only, packed in a nice UI. Could P2 be an option?

  • We should offer a simple basic self-contained package first. Out-of-the-box experience (OOBE) is more important than configurability here, since the OOBE is what we need to tackle with this effort.

What's the minimum requirement in an initial Eclipse for Embedded package?

  • CDT Tools (Runtime) including the GNU and GDB/JTAG support
  • A preinstalled GNU toolchain for edit-compile-debug (target architecture: x86, ppc or arm)
  • QEMU preconfigured with a runtime OS e.g. embedded Linux
  • TM-TCF for communicating with the QEMU
  • TM preconfigured for downloading and launching on the QEMU, as well as browsing remote processes
  • TmL for startup and shutdown of the QEMU
  • DD-DSF for launching and debugging, along with the Memory Renderer
  • Some preconfigured embedded specific example projects that run out of the box - e.g. a Linux Kernel Module, some Threading stuff
  • Some additional contents / tutorial specific for the package. Perhaps also help pointing users to relevant online resources, and telling them how to modify the initial package (i.e. switch target architecture, ...)

Anything else? - Please edit the Wiki and add your ideas!

  • Mylyn? Subversive?
  • NAB? (With MWT for GTK preinstalled on the QEMU)?
  • Can we provide preconfigured kgdb support for Linux Kernel Debugging, or are we restricted to usermode?
  • Could we make the QEMU emulate some sexy device e.g. a Phone? Should we think about other emulators e.g. Android?

Licensing and Distribution Questions

  • Embedded Development needs compilers and debuggers, which are typically in Open Source under GPL. The licensing incompatibility with the EPL forbids a single package like EPP hosted from -- what are the alternatives?
    • Creating a package like Wascana (CDT for Windows) on SourceForge, probably with P2 technology
    • Other packagers - Cloudsmith has been discussed as an alternative

Concrete Planning

  • A concrete plan should start with two, or even one simple self-contained package(s):
    • DSDP for Java package - MTJ, eRCP and related stuff, probably Android as Emulator
    • DSDP for Native package - CDT, TM, DD, NAB, TML, QEMU, gcc, gdb - preconfigured for one specific target platform that comes pre-installed in QEMU
  • From that point on, we can gather more Community and work on more configurable packages or improved installers
  • The native package is probably the more interesting to start with, because that's harder to get set up with for end-users
  • Get in touch with Distribution builders like Cloudsmith, Yoxos, Pulse - they could help out with the packaging technology

Requirements and Constraints

  • The DSDP Package must be self-contained: After downloading and installing the package, end-users must be able to perform a full embedded Edit-Compile-Debug cycle for C programs running on an Emulator.
  • The First DSDP Package must be as small as possible to avoid unnecessary stuff that's just confusing.
  • The DSDP Package must be vendor-neutral and Open Source. We should start building a Community around the package(s).
  • The DSDP Package must run at least on Linux (since that's likely the Platform on which it's easier to get cross compilers). Windows and MacOS are desirable too, but could be avoided by preparing a pre-installed VMWare virtual appliance that holds a Linux host install together with Eclipse and the DSDP package (not too desirable).

Work Items

1. Gather Community, interested parties. Ask Silicon Vendors for interest and support.
2. Find / Decide on an Emulator to use (Likely QEMU).
3. Find / Decide on a target architecture and target OS (Likely x86 and Linux since most well known).
4. Find / Decide on a Cross Toolchain (compiler, debugger). Is there anything freely available on Windows too?
5. Get the target and cross toolchain set up. Find/Decide on additional runtime libraries (e.g. MWT).
5.1. If necessary, create an automated build process that prepares the cross toolchain and target image automatically based on packages that are freely available for download -- an Open Source Build System clarifies copyright / provenience and thus helps with Legal
6. Integrate the Cross build/debug with CDT, TM, DD, TmL, NAB.
7. Implement the Packaging and installer (ZIP, P2, ... ?)

We'll need YOUR ideas and input for points (2) - (4) especially. Where do we find good Open Source toolchains, free Open Source target OS, Libraries, Emulator?

Time Plan

  • Summer 2008 - Gather Community, Clarify requirements, work on first steps
  • Fall 2008 - Have a single first package defined on a single host OS
  • Winter 2008 - Clarify Distribution and installer, have the first package available (likely on Sourceforge), gather input for more packages
  • Spring 2009 - Present package(s) at EclipseCon, think about more configuration options, more interesting things from the Community

Other open questions

  • How is Android related?
  • Edit the Wiki and post your question here:
    •  ??

Back to the top