Eclipse Europa: An implementation guide for embedded geeks - Embedded.com

Eclipse Europa: An implementation guide for embedded geeks

A few months ago, RoweBots decided to adopt Eclipse as a platform fordelivering new tools to our customers, particularly interested in the Europarelease. We decided to use Eclipse for all the reasons thatyou've likely been thinking of, if you are considering doing the samething:

* open source
* high quality
* broad tools
* many plug in extensions
* great licensing model
* community driven development without one large controlling partner
* many books
* general applicability

Little did we know what we were getting into. The fundamentalproblem with Eclipse is that nobody has had the responsibility – or atleast fulfilled the responsibility – of making it easy for anyone elseto learn about it with a specific domain of knowledge in mind.

It is acommunity of practice where the domain has gotten too broad and it isin the process of developing subdomains but nobody has bothered toorganize the subdomains.

The domain of knowledge that I am interested in is deeply embeddedsystems. When I started my review there were many pieces of Eclipse andEclipse projects that could help us and our customers but there was nocoherence to this information.

For this reason, I'm writing thisarticle as a brief high-level user's guide to embedded Europa projectsso that otherscan make more sense of these projects with far less work than wasrequired on my part.

Our World View
For me, there are two approaches to developing embedded systems andEclipse embraces both of them. This makes Eclipse incrediblyinteresting to me in the long term.

The first approach is to rely upon modelling of the system startingwith high level models .Decomposing a system in this way provides true benefitsin terms of architecture, modularity, and common design patterns.

Thenusing these models, the system can be generated from standardcomponents using additional custom modules where required. This iswhere many of us would like to be, but nobody has achieved this in anybroad sense.

The second approach is what we would typically see in the fieldtoday. Typically we are making additions to existing systems.Developers have mental models and actual documentation of the system insome cases, and they use these models to develop the code.

The development is done via refactoring, from minor to major.Eclipse is great at supporting this type of incremental change andenhancement common in so many programming paridigms today (agile programming, extreme programming, etc .).

In this second approach, testing is done as part of the development.As a matter of fact, most would suggest that the tests should bewritten before the code changes to ensure that the code does the rightthings.

Tools are usually used to automate this testing and the testingframework is version controlled along with the new components to ensurethat retesting and piecewise testing is possible at any time. Therefactoring steps are usually kept small too, ensuring that the systemis operational nearly all the time and that it meets users expectationsnearly all the time.

Why haven't these two approaches converged into one? The real reasonis that the modelling tools and reverse engineering tools are not yetup to the required standards for true component based development. Onthe front end we have a broad set of diverse models for embeddedsystems. A few such common models and approaches are:

* UML 2
* SDF
* Puma
* EntityRelationship Diagrams
* Petri Nets andStochastic Petri Nets
* FEMA
* FaultTree Analysis

Different industries will want different models and a broad set ofmodels will exist. The automotive industry is working on its own set ofmodels for describing deeply embedded systems in transportationvehicles.

Many also feel that there will be domain specific models such as SDF or Petri nets , which will onlywork for very narrow domains ” maybe even one family of products withina company. All these models will have to work together to offer acoherent view to the developers. Eclipse is ideal for supporting suchmodel development and evolution.

A second major factor inhibiting modelling based programmingutilization is that users have to be trained on a unified set of modelswhich can completely describe their system, and only then to the modelsstop getting in the way and really help the development team.

Don't forget the team is always under time pressure and anymodelling tool which cannot fully address the team's needs falls by thewayside quickly. With out of date models, reverse engineering becomescritical, but this feature is generally not as strong as it needs to beto achieve high productivity. In particular, all the comments aredropped off the diagrams in reverse engineering which limits theusefulness of these diagrams.

Eclipse Projects
From this perspective of the evolution of embedded software developmentand maintenance, we can look at the ways that the Eclipse projects cancontribute to the overall framework that presumably will exist by 2020.We can also look at how Eclipse can tribute in the short, medium andlonger term.

Now, as we look at the Eclipse projects and frameworks, the power ofEclipse become all the more apparent. It does offer a great deal todevelopers in terms of refactoring and pattern design methods fordeveloping systems and the support for refactoring approaches and codedevelopment are growing.

Clearly the momentum is building for a more model based programmingapproach, and Eclipse provides a framework for both appraoches as theyconverge. The basic approach of the various projects are indicated in Table 1, below.

Table1. Eclipse Europa Projects Release

The Europa Release content relevant to main stream embedded systemdevelopers is shown in Table 1 .This is what Eclipse offers in theshort term. This collection of projects offers a broad set of supportfor refactoring and model based development but lacks the completenessrequired for full model based development of embedded systems. Theobvious limitations are as follows:

* Testing support for C/C++ is not provided.
* Although support for UML 2 is offered, support for other models likePUMA, SDF, and many others are not supported. In addition to support,they require integration at the model level.
* Buckminster is in its infancy and unlikely to be useful.
* Performance modelling, measurement and display are major holes.

In summary, Eclipse now offers a very good environment for C/C++embedded development including integration into the target side , but lacks many ofthe higher level pieces and integration necessary for a full modellingtoolset.

In the medium term, expect Eclipse to improve dramatically in thearea of modelling of embedded software systems and in the area ofubiquitous support for embedded targets. The framework development forany type of model development, storage, display, update and connectionto other models has already been provided.

As the model sets become richer and the models become integrated,our ability to use these tools will improve. Also extension of thetesting and measurement tools into the embedded domain are expected andwill make a major contribution to the framework.

In the long term, consider the tools and models developed over thepast 25 or 30 years for embedded software development and how quicklythey evolved and changed.

In fact, few revolutionary enhancements havebeen made over this time. Look at the new technologies on the horizonand how they might change the world ” in particular the growth incomputing power and software which deals with uncertain outcomes.

It is highly likely that the tools and models that we have todaywill be the framework for software development for the next ten ortwenty years with the process of transformation and compilation usinghigh level models becoming more dominate over time. Eclipse has theframework that is needed to support this.

Kim Rowe has spent over 29 years developing real-time andembedded signal processing systems for defense, communications, medicaland other applications. His company, RoweBotsResearch Inc. was founded in 1987 and offers DSP Real-TimeOperating Systems, DSP Libraries and Eclipse based IDEs for C/C++ aswell as consultancy. Kim has a blogRoweBits that focusses oncurrent issues in multicore processors, multicore DSP implementation,FPGA DSP algorithm implementation, digital signal processors anddigital signal controllers, parallel algorithms, heterogeneousarchitectures and modelling tools for DSP applications.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.