Eclipse in Embedded Survey

I recently came across a link to a survey report on Eclipse usage in the embedded space on Chris Lanfear’s blog. The most exciting conclusion of this survey is that Eclipse usage among device software developers has grown from 1% to 17% in the past two years and is expected to be almost 50% two years from now. Clearly this is an excellent rate of adoption. The survey goes on to describe Eclipse usage breakdown by vertical markets, developer opinions of Eclipse tools, developer demographics, vendor integration, purchase decisions, and target operating system support. A few specific items jumped out at me, and I describe them below.

Vertical Markets. Below is a chart made from data in the report. It shows current and 2-year expected usage of Eclipse Tools by vertical market. (Presumably respondents were allowed to select more than one market for their development work.)


While the growth in expected usage for almost all of the markets is great, the mobile phone vertical really jumped out at me because it mirrors the growth in DSDP’s projects. Four of the DSDP projects have specific focus on the mobile space, phones or otherwise – eRCP, MTJ, NAB, and TmL. I am confident that these projects are currently building or have plans to build the underpinnings of this adoption.

Developer Opinion. The report states, “On a case-by-case basis reactions to Eclipse-based tools are quite mixed, with many users reporting decreased levels of satisfaction with their Eclipse-based tools.” The survey respondents average 3.5 out of 5 when rating their Eclipse tools favorably relative to their previous non-Eclipse tools (3 was neutral). I believe this is a reflection of the maturity level of both commercial embedded products based on Eclipse and open source embedded projects. Contrast this with the satisfaction around Eclipse-based Java development tools, which are much more mature. I would expect similar survey results from the other newer technical verticals in Eclipse. Ultimately, though, one can view this as good news because the high Eclipse adoption rates in the space will drive the quality up, both commercially and in open source.

Vendor Integration and Purchase Decisions. The report states that the integration of tools from multiple vendors is not a big driver when developers select Eclipse-based tools. Instead, the primary drivers are 1) that the commercial tool is based on open source technology and 2) that the tool is supplied by the developer’s preferred vendor. Given the plugable nature of Eclipse, I find this survey result surprising, as did the authors. I believe there are two explanations. First, embedded developer adoption has just started, so those developers are just beginning to see the compatible commercial and open source offerings available to them. Second, as I discuss below, the report points out that many commercial solutions are forking and heavily customizing stock Eclipse, which may lead to either real or perceived lack of plugability.

Target Operating System Support. The report states, “Most developers currently using Eclipse-based development tools are developing products that utilize a commercial or open source operating system. Going forward, however, Eclipse-based tools will also be used more commonly in the production of devices using both proprietary operating systems and no formal operating system.” I have some trouble with this conclusion at the technical level because it requires end-users of commercial Eclipse products to staff Eclipse developers in order to build custom support for their in-house proprietary operating systems, especially in the area of debugging. While this is certainly in the spirit of Eclipse extensibility, it runs counter to my experience that customers are actually looking for turn-key solutions rather than solutions that require a heavy amount of customization on their part. Perhaps it’s more accurate to say that companies will experience a partial adoption of Eclipse for their proprietary operating systems, whereby they use some of the IDE capabilities while still relying on their non-Eclipse tools for debugging and analysis of their proprietary operating systems. I will comment on this in future blog entries as I get more data.

Final Thoughts. With respect to device software tool vendors that are avoiding Eclipse, the report states, “Issues such as maturity of technology, vendor customization, fragmentation or forking risks to meet the needs of both the enterprise and embedded segments, and the openness of individual solutions are often raised as risks that have not been suitably addressed.” While there are few major device software companies who haven’t adopted Eclipse at this point, the concerns raised are still important. Some comments:

• The need for openness, collaboration, and common base technology in the device software space is real, and it’s one of the driving factors behind the projects in DSDP and their attempts to bring together multiple vendor solutions.
  
• “Customization, fragmentation, and forking” means modifying dependent Eclipse projects, not keeping up with the latest versions of dependent projects, violating open API’s, or not supplying your product as a plug-in to existing Eclipse installs. Vendors that avoid these pitfalls will be the most successful in their commercial offerings.
  
• Commercial solutions should follow the Eclipse open and extensible API model for their IP: build open, proprietary API’s to allow partner and customer integration with commercial IP built on top of Eclipse. In this case, the API is open, but the implementation is IP. After all, what’s proprietary today may eventually be open tomorrow.
  

Bottom line, I’m glad to see the adoption curve growing so significantly in the device software development space. I’m looking forward to an update on this survey a year or two down the road.

eRCP at EclipseWorld

If you’re attending EclipseWorld in Boston in a couple of weeks, check out Course 507: Eclipse on Cell Phones!? An Introduction to the Embedded Rich Client Platform (eRCP). Chris Aniszczyk and Mark Rogalski will introduce eRCP and provide some coding exercise for the participants.

Open Source DART Buoys?

Continuing on the theme of Corporate Responsibility and open source, I heard a story on NPR a couple of weeks ago about the Tsunami Early Warning System in the Indian ocean. At the heart of this Early Warning System is a piece of technology called a DART Buoy. (DART stands for “Deep-ocean Assessment and Reporting of Tsunamis” – and you thought Eclipse Acronyms were a mouthful!) DART buoys were designed by NOAA and are currently deployed on both coasts of the U.S. The buoys sense pressure changes on the ocean shore and relay real-time data via satellite to warning centers. Strategically placed, they are an effective means of locating and tracking tsunamis as they happen. Check out the real-time observation page to see what the water level is doing near your home.

What caught my attention in this story was what sounded like open source hardware. Apparently the Indian ocean warning system is just a map of buoy location placement right now. There’s no buoy deployment or functioning warning center yet, and the DART buoys that NOAA owns are in short supply. However, according to the NOAA official interviewed in the report, NOAA has offered up the design to the public so that other countries can build their own. He claimed that you can go to the website for this information. Cool…open source hardware!

Well I went to the website, and while there are technical specifications and some block diagrams, there aren’t the open source publications that one might expect: schematics, board layouts, bill of materials, embedded software, etc. Oh well. I don’t doubt NOAA is in fact sharing this information. I guess I had hoped to see something more technical actually in the public domain, though. I emailed NOAA to find out more. I’ll update you on what I learn.

Embedded Intel Articles

Embedded Intel Magazine just recently redesigned their website to provide on-line access to articles in their quarterly publication. Two recent articles were published: a multi-core article related to the Device Debugging project and a CDT / DSDP article describing the progress of Eclipse in the embedded space. I wrote the first article with the help of Darin Wright (Platform Debug Team) and Ted Williams and Pawel Piech (Device Debugging). Thanks guys!

300,000 Lines

Wind River just announced the contribution of 300,000 lines of software to four Eclipse projects. I’d like to take a moment to add some technical detail to the press release by describing where the contributions are coming from and where they will end up.

The code to be contributed comes from Wind River's Eclipse-based device software development suite, Wind River Workbench. The Workbench product supports multiple real-time operating systems, a broad range of microprocessors, several methods of debugging, multiple development languages, and advanced source code build, analysis and testing. At the core of Workbench is technology similar to open source development tool projects like CDT. However, this functionality was developed before CDT became the mature, well-adopted technology that is it today. In order to help advance the technology in open source and to allow Workbench to become more compliant with open source, Wind River is contributing code to CDT, DSDP-TM, and DSDP-DD and the Eclipse Platform (via DD).

I outline these contributions in the table below, most of which have been in progress for several months now. Some of the code is technically independent from existing open source technology and is being contributed to Eclipse as-in. In other cases, developers are refactoring the code to better fit into existing Eclipse projects and technology. Most importantly, Wind River has assigned the same engineers who developed the code in Workbench to the corresponding open source projects in order to develop and enhance the same functionality openly. This approach provides the most value to the open source community and the fastest path for commercial product integration. I’ve included approximate software lines of code (SLOC) counts for the packages as they exist today in Wind River Workbench, as well as a list of assigned engineers and approximate lines of code committed to date. (To track commit data, you can use Dash commit information. Please note that the DD link on Dash isn’t accurate right now. A bug has been filed.)

CDT Contributions

Technology	Details	SLOC in Workbench	SLOC to date	Wind River Engineer
Editor Enhancements	Contribute editor functionality to CDT’s C/C++ editor.	14,800	5,400	Toni Leherbauer (aleherbau)
Common Navigator	Contribute a project navigator implementation on top of the Common Navigator framework to allow project contributions from multiple languages and build systems to exist in the same navigator.	27,200	2,000	Toni Leherbauer (aleherbau)
Include Browser, Type Hierarchy, Call Tree	Add static analysis views from Workbench to CDT.	66,300	7,200	Markus Schorn (mschorn)

See the CDT 4.0 project plan for more detailed information.

DD and Platform Contributions

Technology	Details	SLOC in Workbench	SLOC to date	Wind River Engineer
Debugger Services Framework (DSF)	Contribute a device-centric debug model implementation refactored from Workbench to fit into the new Eclipse 3.2 debug model interfaces.	41,100	3,600	Pawel Piech (ppiech)
Debugger Views	Contribute enhancements from Workbench to the existing Eclipse Platform debug views (Memory, Registers, Expressions, Debug).	79,500	2,900	Ted Williams (tewillia)

Debugging concepts were also contributed to the Platform for the new provisional debug model interfaces in Eclipse 3.2.

TM Contributions

Technology	Details	SLOC in Workbench	SLOC to date	Wind River Engineer
Remote kernel objects model and target wizard framework	Contribute a Secure Shell transport and OS-agnostic frameworks based on Workbench.	62,000	6,250	Martin Oberhuber (moberhuber)
Component based launching	Contribute a Framework for assembling complex Launch actions from contributed components.	14,000	0	Martin Oberhuber (moberhuber)
Network/Serial Terminal View	A simple view that supports serial and tcp/ip communications and provides basic support for the telnet protocol and terminal emulation (VT100, ANSI).	5,200	0	Ted Williams (tewillia)

See the TM project plan for more detailed information.