You want an audio system to provide you with very high quality sound, and also perhaps to take sound from your TV/video system. You can buy a complete integrated package; it is easiest but, depending on your requirements, it may not meet your expectations for quality. Also, when a new source appears, like MP3 for example, you may have difficulty integrating it.
Instead, you research the different components: tuner, amplifier, CD player, speakers, even cables and connectors, and assemble your own system with what may be best of breed units. Some years ago one of the interesting problems you faced was physically connecting the units together, as they often used different connector formats. Today most of them use phono plugs, so that is one less issue (although over the next few years HDMI may begin to make inroads).
Now think about assembling your embedded tool chain. A lot of companies whose core competence is expressed in a specific tool also offer a complete integrated chain. This makes life easier – one supplier, one contract, one point for support. But does each of the elements of the chain provide exactly what you want? Is the supplier of an RTOS also the best source for a debugger?
Instead you may choose different point tools, evaluating each link in the tool chain to get the best of breed. But then you have a new problem: the tools often don’t plug together. To return to the audio analogy, it is as though each manufacturer of equipment had its own specialist connector technology. Also each tool link runs in its own environment with its own user interface; after working with, say, the debugger, you have to open another tool to edit the code to remove the bugs and then open the compiler to recompile before running through the debugger again. And each user interface is different, sometimes in subtle ways.
Some point tool providers get round this by entering formal or informal alliances with other tool makers, so that their tools work together. This is fine at the time the alliance is formed, but it can be challenging for both the tool suppliers and the user over time. A mutual interface has to be developed for each alliance the tool maker enters. As a tool is upgraded, each of the partners may have to modify their interface. The user has the problem that when he wants to add another element of the chain, a static code analyser for example, the choice is between one that fits with the existing tool investment and adding another interface to the existing proliferation.
This, the Eclipse proponents will argue, is why the embedded world needs Eclipse, which provides a standard user interface and a standard interface for the tool developer. Applications just plug in to the Eclipse framework (with one set of connectors) and the users move from compiler to debugger to code editor in a single environment. They can choose the tools that they want to use, and when a new tool is added they only have to learn the tool, not how to manage a new interface.
Eclipse started in the enterprise environment, when IBM created an integrated development environment. This they donated to the open source community in 2001, and the Eclipse Foundation is responsible for maintaining and developing what is the now well-established standard.
On top of the basic Eclipse infrastructure are the core IDEs – JDT (Java Development Tools) for Java (Eclipse is written in Java) and CDT for C/C++. These are supported by a range of platforms, such as the Data Tools platform and different application frameworks, such as graphical modelling. To quote the Eclipse Foundation: “Eclipse provides extensible tools and frameworks that span the software development lifecycle, including support for modeling, language development environments for Java, C/C++ and others, testing and performance, business intelligence, rich client applications, and embedded development.”
Eclipse is very firmly entrenched in the enterprise space, and while some large projects in the embedded industry were Eclipse users from the start, its relevance to the industry really began when Wind River moved from Eclipse membership to being a Strategic Developer in 2005 and kicked-off of work on the Device Software Development Platform (DSDP). “DSDP provides an extensible, standards-based platform to support all phases of the device software (embedded) development process, including hardware bring-up, platform software development, and embedded application software development.” This now has six major project areas underway, including: General embedded support, which covers Device Debugging and Target Management; Mobile Java includes Mobile Tools for the Java Platform and Embedded Rich Client Platform; Mobile C/C++ includes Native Application Builder and Tools for Mobile Linux (TmL); and System Level Design includes the Virtual Prototyping Platform.
The companies most deeply involved include Accelerated Technology, Arm, Ericsson, Freescale, Fujitsu, IBM, Motorola, Nokia, Palmsource, Symbian, TI, and Wind River, while Curtiss-Wright, Intel, QNX, AMI Semiconductor, MontaVista, SonyEricsson, Sybase, ShareME Technologies, and others are also involved.
And, before we leave Eclipse for a moment, there is nothing to stop a company developing its own plug-ins internally or adding Eclipse interfacing to their existing tools, to use alongside commercially supplied products.
So what about Ada? Just to remind you, Ada is a language developed when the US Department of Defense realized that projects under its funding were using no less than 470 different high level languages. (In the 1970s everyone was writing a high-level language.) DoD set up a High level language working group and, to cut a long story short, in 1979 it chose Ada, developed by a team at CII-Honeywell Bull lead by Jean Ichbiah (make a note of that name) as its preferred high level language.
Since then, Ada has become very widely used in defense and aerospace applications, although the move to COTS (Commercial Off The Shelf) products means that using Ada for defense applications is no longer mandatory. The current version, Ada 2005, is defined by ISO-8652:1995, combined with major Amendment ISO/IEC 8652:1995/Amd 1:2007. (Quite how a base standard dated 1995 with an amendment dated 2007 becomes Ada 2005 I leave up to you to work out.)
Ada proponents argue that the language is ideal for embedded systems, since it was designed to be reliable and maintainable, with the compilers carrying out checks such as ensuring that the programmer has used a data object in a way that is consistent with its type, and with compiler generated checks for buffer overflows. Also, with the increasing use of multiple processors, Ada, its fans argue, has a built-in concurrency model, which was enhanced in Ada 2005, that makes it attractive.
Large military and aerospace contractors have recognized Eclipse as providing them with a significant benefit, and, at the same time, they wanted to use Ada, either on its own or as part of a mixed language environment , in their projects. Ada suppliers were developing elements of the tool chain themselves, with some of them such as Aonix and Green Hills having extensive offerings.
Now Eclipse has started the ADT – Ada Development Tools – project, also called Hibachi. Aonix, a descendent of a company formed by Ada architect, Jean Ichbiah, to commercialise aspects of Ada, has donated AonixADT to Eclipse. AonixADT was a commercial Eclipse plug-in that supports Aonix’s own ObjectAda as well as GNAT tool chains, with a design based on JDT and CDT, which – if you are still awake you will remember – are the Eclipse Java and C Development Tools. A range of organizations was involved in the proposal to create Eclipse ADT, including DDC-I, CohesionForce and AdaCore. In November 2007 the ADT Proposal became a Project (in Eclipse-speak) and other organizations are beginning to join.
Eclipse has a rigorous development process and a vocabulary that can sometimes seem arcane, but it is intended to produce a product that is robust and useable. The Hibachi group is drawing on the experience of the other Development Tools projects, and this is formalized by appointing mentors from those projects to the Hibachi working team. What seems odd at first sight is that companies are willingly donating people, which also means money and products, which means forgoing future sales, to create a level playing field for their competitors. These companies normally say that they are confident that their link in the chain is strong enough to stand the competition and that their customers will benefit from the integrated and unified environment. In particular both Aonix and DDC?I point out that in many large projects, great chunks are developed in C with Ada being used for critical sections. The ability to carry out multi-language development in a single development environment is a significant advantage for the user. It seems likely that this capability may be attractive to developers who would have liked to use Ada or mixed Ada/C/Java but were put off by the complexities of many different and incompatible tools and the difficulty of achieving integration.
There is now a significant number of tool companies producing Eclipse plug-in versions of their products across the breadth of the embedded market place, and even some of those who do not currently have their own Eclipse products are believed to be developing them. It makes sense for anyone extending their tool chain or starting a project with a clean sheet (is there ever a completely clean sheet?) to consider Eclipse very seriously.
Trivia note 1: The name Ada was chosen to honor Ada, Countess of Lovelace. While it is debatable as to whether she really was the first computer programmer, she certainly had a deep involvement with Charles Babbage’s attempts to build mechanical computing engines in the 1840s.
Trivia note 2: While technically the Eclipse Ada project is Eclipse ADT, the name Hibachi (a Japanese barbecue) is used by the participants in honor of the leader of the original Ada development team, Jean Ichbiah. Tom Grossman, who is the leader of the Hibachi project, said that he wanted a code name that paid tribute to the early work on Ada, and after discarding a whole shed load of options, such as Beaujolais, (after the Beaujolais Effect – check wikipedia,) “Green”, Jedi, Kermit, and other even more obscure references, he “came up with one complete anagram for Ichbiah – Hibachi.”
www.eclipse.org for the formal story
http://hibachitom.blogspot.com for a more informal view
