Eclipse Summit Europe Day One: Device Software Symposium
Day one at ESE brought the symposiums, and thanks to a flurry of last-minute position papers, the Systems Engineering in Device Software Development symposium got off to a good start. We has 12 attendees from a variety of eclipse backgrounds, including OSGi for embedded, CDT, eRCP, DD, simulation, automotive, mobile Java runtimes, and commercial embedded tooling.
Certainly one of the characteristics of the embedded and mobile space is the diversity of both the underlying technologies and their applications. Following the symposia format, we broke the discussion up into six different sessions:
- Hardware Debugging
- System Simulation and Modeling
- Embedded System Tracing and Profiling
- Fostering Internal Eclipse Adoption
- Commercialization of Eclipse for Embedded and Mobile Tools Vendors
I will post detailed notes from the symposium soon, but let me provide a short summary of the sessions. In each case, we tried to come away with action items.
Hardware Debugging. Community demand is increasing for a CDT-based JTAG debug solution for board bring-up and bare-metal debugging. While Zylin Embedded CDT exists today, it is a fork of CDT. The group discussed the need to bring JTAG vendors together to build a solution that still retains the ability for hardware vendors to differentiate their products. As debugging is the most critical facet of a JTAG solution, the group recommended a follow up discussion between the Zylin contributors and the Debugger Services Framework (DSF) authors from the DD project.
System Simulation and Modeling. Many complex embedded systems are simulated using tools such as Matlab/Simulink, Qemu, or other commercial, open, or in-house tools. There needs to be a standard set of API's for both visualizing and controlling simulators in order to enable Eclipse integration with multiple simulation choices. Matlab use was cited by a couple of the attendees, and the group recommended a follow up discussion with engineers from the Mathworks.
Embedded System Tracing and Profiling. The focus on the TPTP project has thus-far been Java tracing and profiling for enterprise applications. The device software tools space is heavily fragmented with many proprietary tracing and profiling solutions for C/C++ embedded applications, none of which use TPTP to any great extent. Ericsson announced that they intend to create a subproject in TPTP to produce a framework for tracing and profiling C/C++ code. A reference implementation will be provided for LTTng on Linux, but the framework will also be designed for building commercial tracing and profiling tools. Ericsson is organizing a separate meeting to survey the current state of the art and begin a project plan.
Devices. Both eRCP and OSGi are used for Java on devices (JME). For eRCP, the group discussed the need for broader platform support, especially for Linux devices. We also discussed the need for bit-mapped (e.g. P3ML) and flash-based graphics as an alternative to the SWT widgets, as many users prefer a customized and domain-specific UI instead of desktop experience on their embedded device. For OSGi, we discussed startup time limitations, size constraints of devices, needs for better models, and needs for better inter-device messaging solutions. A follow up discussion will dive into the UI and startup time issues in more detail.
Fostering Internal Eclipse Adoption. This discussion was initiated by an engineer responsible for Eclipse deployment across a large engineering organization, and he echoed the problems that most of us face when trying to migrate internal embedded developers off of their old tools and onto Eclipse. We discussed the need for internal evangelists, killer apps that can only be provided in Eclipse, simplified workflows, and the need for better solutions to migrate the often complex legacy configuration and build environments in place at most companies. Finally, we discussed the need for better training for internal groups needing to learn Eclipse plug-in development.
Commercialization of Eclipse for Embedded and Mobile Tools Vendors. We discussed the typical yet frustrating challenges taking Eclipse technology from the various projects and commercializing it into a device software development tools solution. A couple of themes emerged. First, forking Eclipse technology is bad, and companies must foster a culture of contributing patches back to the respective projects. Second, projects need to be more inviting for non-committers to offer changes. In some cases, projects' elitist mentality or lack of interest in vendor-specific use cases prevent patches from being applied to core technology. The group also discussed the need for some sort of marketplace (e.g. bidding system) for bugs that would allow consumers of Eclipse projects to put money on bugs they need addressed.