Eclipse GSOC Projects

[Daron Chabot]

Alan Cudmore wrote:
> Here is my take on the Eclipse integration and configuration GUI  
> projects:
>   
I've been using Eclipse for both Java and C/C++ applications for about a 
year and a half and I think it's a very useful tool ( I can feel Eric 
"real men use vi" Norum rolling his eyes at me from here... :-) ). On 
the side, I also like to dabble in building Eclipse RCP (rich client 
platform) projects. The Eclipse IDE is itself just a very sophisticated 
RCP application.

Lately, I have also been thinking about creating some Eclipse support 
for RTEMS projects.

> Eclipse Integration can include a lot of sub-projects. Some require  
> no real work, just using existing tools and plug-ins. Others require  
> a development effort and a pretty good knowledge of developing plug- 
> ins. Some of the sub-projects include:
>
> 1. Basic cross development integration. This can be accomplished  
> using Eclipse and the CDT ( C/C++ development toolkit ). There are at  
> least a few on this list who have accomplished that. The possible  
> work here is just documenting the process of setting it up, and  
> deciding how the RTEMS applications will be built: Do you want to use  
> the makefiles from the examples ( RTEMS_MAKEFILE_PATH ) or go with  
> Chris Johns autoconf/automake based examples?
>   
I know that the *.leaf make-system is unpopular with at least Ralf, but 
what are the alternatives? I was somewhat surprised that the RTEMS 
application build-system didn't make the list of GSOC projects... maybe 
next year ?

At any rate, once the developer provides a Makefile, an Eclipse 
C-project must be told as to where to find the cross-compiler, RTEMS 
headers and libraries. To make this process more painless, an 
Eclipse-RTEMS plugin could be constructed. For those who didn't know, 
plugins are bundles of code that contribute new functionality to the 
Eclipse IDE.

One requirement an RTEMS plugin would contribute is an RTEMS "nature" to 
a C/C++ project: this "nature" would inform Eclipse where to find RTEMS 
headers and libs, a cross-build toolchain, etc.

Accompanying the RTEMS "nature" could be a set of one or more 
"preference pages" where a developer would configure fairly static items 
such as RTEMS install and source locations, PATH additions, etc.

Finally, an RTEMS new-project "wizard" could be built. Among other 
duties, this wizard would prompt the user to select from a choice of 
available BSPs, modify or accept default application configuration 
parameters such as which RTEMS Managers and filesystems to include, 
RTEMS_TICKS_PER_MICROSECOND, etc. This sort of implies that a userConf.h 
template be created (which may be useful elsewhere)...

The new-project wizard would require the most work, but may well be 
worth it: How nice would it be for new users to click a few buttons and 
POOF, an RTEMS "Hello World" application is instantiated from templates 
and ready to be loaded onto hardware or simulator ???
> 2. GNU debugger integration. This can be accomplished using the Zylin  
> Embedded CDT plugin:
> http://www.zylin.com/embeddedcdt.html
> I'm not sure if there are any other RTEMS specific things that could  
> enhance the debugger interface in Eclipse. Perhaps when using CEXP  
> and the RTEMS GDB stub, you can build a module and click a button to  
> download it to the target?
>   

I didn't try very hard, but I could not get Till's GDB stub + Cexp to 
work within Eclipse. Regular serial and networking gdb-sessions work 
quite nicely, however.
> 3. Terminal program: There are Eclipse plug-ins that provide serial  
> terminal emulation. This would provide an integrated terminal program  
> ( or even telnet if you want to use a target shell over the network ).
>   

Yes. The Eclipse Remote Systems Explorer (RSE) plugin provides 
integrated telnet and ftp interfaces.

> 5. Configuration GUI. If we are talking about a complete Eclipse  
> integration, then I think it makes sense to build an eclipse plugin  
> for an RTEMS configuration editor and perhaps a new project wizard.  
> At GSFC, we developed similar eclipse plug-ins for our higher level  
> application software configuration, so we ( not me personally ) have  
> some experience in developing these. Our plug-in used XML to store  
> the configuration parameters, and then could generate the C header  
> file for compilation.
>   
see above comments.
> Of course if the goal is not Eclipse integration, then any other  
> cross platform GUI might work:
> GTK+, QT, wx, or even Java
>   

It would be great if such a GUI-based configuration tool used 
components/technology that could be leveraged from Eclipse (i.e. XML).
> Once some or all of these things are done, then how is it  
> distributed? Can we package up a custom RTEMS eclipse, or just  
> provide an easy way to take an eclipse release and install the  
> necessary plug-ins? In other words, how can it be made a nice easy  
> out of the box experience?
>   
Distribution/packaging may be the "easy" part of any Eclipse-RTEMS 
tooling: It's a simple matter to create an "update site" where Eclipse 
users can point their IDE at to obtain plugins (e.g. 
http://www.rtems.com/updates).


I am willing to help get this going.

-- dc