Peter's Blog

I've been looking into why the make facilities in my Eclipse/CDT install are not working (I try a make and nothing happens). I found a log file in my workspace folder called /.metadata/.log and the log file contains this:

!ENTRY org.eclipse.core.resources 4 2 2007-11-28 11:13:09.401
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
!STACK 0
java.lang.NullPointerException
  at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:520)
  at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:506)
  at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:624)
  at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
  at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:166)
  at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:273)
  at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:354)
  at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:494)

So the java is hitting some runtime error and the architecture is so poor that the error is not reported to me, I have to sit there wondering why nothing is happening.

I searched through the eclipse plugin directory and found zip files that contained the source code. The error in the log pointed me to this line:

IConfiguration activeCfg = info.getDefaultConfiguration();

so my guess was that getDefaultConfiguration was returning a null. This tied in with an observation I made that the "Build Configurations" menu in Eclipse/CDT had all it's items greyed out, including 'Manage..'. I decided that it was probably all because I hadn't set up my CDT project properly. I created a new CDT project, imported my source into it, deleted the old project, renamed the new project to match the old and tried it out. Voila, make ran and the output was in the console.

Lessons learnt:

• Projects may work with a number of perspectives (e.g. C/C++, Ruby etc) and each perspective wants it's configuration data within the project set up properly. At the same time, they seem only to set these configurations up when you create new projects, adding configuration data to an existing project when you use a new perspective appears to be up to the individual plugins: RDT, the ruby development plugin has an 'add ruby nature' option in the project menu to do this.
• Because Eclipse is written in java it comes with all the source code. This means that even if some of it is a bit flaky one stands a good chance of working around the problems.

Ok, I'm an Eclipse noob and didn't set my project up correctly but the environment really ought to have handled this better.

Decided to try getting the Ruby Debugger working in my Eclipse install. I installed the ruby-debug-ide gem as stated in the debugger setup page but the debugger would not work: it kept coming up with an error about not being able to find rdebug-ide.

Googling gave mention of a bug where the path to the rdebug-ide had too many 'bin's in it: instead of looking in c:\ruby\bin it was looking in c:\ruby\bin\bin. I fixed the problem by creating a copy of c:\ruby\bin\rdebug-ide.cmd and placing it in c:\ruby\bin\bin.

I'm not sure if this problem has been fixed properly: the guy who wrote RDT is now working for Aptana and Aptana seem to be trying to set up a paid business model and their update site doesn't have RDT in it. I don't know if my RDT is the latest version or if it is available or from where.

Anyway, the debugger is running. It looks ok but no interactive prompt Also seems to baulk at routine exception handlers inside code you want to skip over. It has some usability issues:

Not a wonderful debugger, thank heavens for print statements.

I have been working on my new project, using Eclipse as an IDE and ruby as a scripting language. Eclipse itself has it's quirks (such as having to create workspaces and projects before you can do anything) but once these are set up it is quite nice to use. I have discovered that the "Bitstream Vera Sans Mono" font is a very nice programming font to use in it, very crisp and clean and it doesn't have weird problems so I can use bold in syntax highlighting. I am also now, for the first time ever, sold on editors that display line numbers on each line, saves a lot of time when going through build/run errors. Then again, I am using a 22" Widescreen monitor with horizontal screen real-estate aplenty. UPDATE: on my 24" monitor at home in 1920x1200 mode Bitstream Vera Sans Mono looked very fuzzy until I enabled cleartype. That PC is running XP, maybe cleartype is on by default in Vista?

I have installed the RDT (Ruby Development Tools) eclipse plugin and I have found some very nice features:

• "Run as Ruby" or "Run as Test::Unit Test" options. I am creating Unit Tests in my new project and it is very easy to run the tests from inside eclipse. Eclipse includes a browser than displays the test results.
• RI documentation browser. A bit like fxri but it works a lot faster, although it raises an nasty looking error if it cannot find any search matches.

Since my Eclipse has both C development tools and Ruby development tools I am able to work nicely on both, which is useful since I had to write a ruby extension to handle serial communications. The extension is written in C++ but Eclipse is able to run a makefile to build it and then I can run Ruby Unit Tests to test the extension.

Eclipse has a wizard that is supposed to allow me to create new unit test files but it is totally confusing to use, always puts the file in the wrong directory and doesn't seem to give any huge advantages over simple 'New File' and 'Save As': it stills gives me the 'Run as Ruby' option.

SWIG and Ruby

I had tried using the ruby-serialport extension module for my serial comms but it was very painful to try building, requiring installation of Visual C++ version 6 (cygwin gpp wouldn't do) and Microsoft nmake rather than gnu make which in it's latest version doesn't work with extconf.rb: the makefiles it generates give syntax errors. Once I did get it to build it gave obscure gem errors when I tried to use it. It seems that it doesn't support the latest ruby libraries or something.

I decided to write my own simple ruby extension to handle rs232 so I went back to swig and this did it's usual great job of generating ugly boilerplate interface code for me. The biggest problem I found here was getting my module to generate ruby exceptions on errors but I solved that thusly. In my cpp code I put this:

   1  void RaiseError( const char *strFormat, ...)
   2  {
   3    static char strErrorBuffer[255];
   4    va_list args;
   5  
   6    va_start( args, strFormat);
   7    vsprintf( strErrorBuffer, strFormat, args);
   8    va_end( args);
   9  
  10    throw strErrorBuffer;
  11  }
Toggle Line Numbers

This formats up an error message and throws a C++ exception. It doesn't support __FILE__ and __LINE__ information but my extension is very simple and doesn't need it. This function is called wherever in the extension I want to raise errors, e.g.

   1  *
   2   * Read a byte from a serial port. Returns either the integer value of the byte received or -1
   3   * if no bytes are available.
   4   */
   5  int ReadByte( int nPort)
   6  {
   7    int nData = 0;
   8    ULONG nRxLength;
   9  
  10    HANDLE hPort = (HANDLE)nPort;
  11  
  12    if( ReadFile(hPort,  				// handle of file to read
  13    	&nData,               			// handle of file to read
  14        1,              				// number of bytes to read
  15        &nRxLength,                 	// pointer to number of bytes read
  16        NULL) == 0)              		// pointer to structure for data
  17    {
  18    	RaiseError("Read Serial port failed: 0x%08x", GetLastError());
  19    }
  20  
  21    if( nRxLength > 1) {
  22    	RaiseError("Read too many bytes?");
  23    }
  24  
  25    if( nRxLength > 0) {
  26    	return nData;
  27    } else {
  28    	return -1;
  29    }
  30  }
Toggle Line Numbers

In the swig interface definition file I put this which wraps each interface function with an exception handler that will catch the C++ expection and raise a ruby exception from it:

   1  %include exception.i
   2  
   3  %exception {
   4   try {
   5     $action
   6   }
   7   catch (char *strErr) {
   8     SWIG_exception( SWIG_RuntimeError, strErr);
   9   }
  10  }
Toggle Line Numbers

These exceptions can be caught just beautifully in Ruby Unit Tests so I know my error handling is working:

  #
  # Make sure an error is generated when attempting to read from a port that is not open.
  #
  def test_read_port_not_open
    oException = assert_raise RuntimeError do
      Rs232.ReadByte( 123)
    end
    assert_match( oException.message, 'Read Serial port failed: 0x00000006')
  end

Documentation Woes

In an ideal world I would be using either Doxygen or ruby's own RDoc to document my code. Both are designed to scan my source code and generate copious documentation for me. However, while Doxygen would do a great job with my C/C++ source it does yet handle Ruby. Conversely, RDoc does a great job on ruby source but it's support for C only extends as far as the C source for extension modules and this isn't working for my SWIG generated project. It seems as if the Rdoc C support has been written ONLY for C ruby extensions with little thought given to making it general purpose C documentation tool.

The ruby stuff I am writing will ultimately provide a programming API and the kind of documentation either of these tools would generate would be lovely. I don't really want to have to use two tools with different capabilities and output formats but it is looking like I will have to. Fortunately the C stuff should be pretty much embedded, the Ruby stuff is what other people must be able to use.

I'm doing some Embedded Systems work on a new project and rather than splurge £2500 on the Keil ARM development tools I'm trying to run with gnu gpp and various open source options. The Keil stuff is very nice and includes emulators, debuggers and suchlike but these aren't must-haves. Also the £2500 gives you a single developer license. With the gnu tools we will have much more development flexibility.

As a toolchain I'm using gnuarm and I'm also trying the freertos embedded operating system. I managed to put together something that builds with the ST STR7 Standard Library which is effectively a set of device drivers for the on-chip peripherals. Freertos comes with many permutations of Arm7 derivatives, target development boards and development environments but not one that suited my setup so I had to munge one together myself.

Aptana has given me a taste for Eclipse based systems so I'm trying Eclipse itself as a general purpose IDE. I installed a version of Eclipse tailored to C development (CDE) and soon got it to launch a make file and build my project. The IDE is able to parse most (not all) of the error output from the build tools and give me a list of errors I can click on to go to the source line... all good basic IDE stuff I had in Turbo C twenty years ago (argh is it that long?).

Having got my Embedded code compiled the next step is to download it to the microcontroller. To do this I need to knock up a ruby script to read an intel hex file and download it via rs232 to the bootstrap loader built into the microcontroller (damn cool modern microcontrollers). I have a Keil development board with a cool JTAG widget that plugs into the USB and is effectively an in-circuit emulator but cost under £200. Unfortunately it is locked to the Keil tools so I can't use it...

I managed to add an RDT perspective for developing Ruby applications to my Eclipse setup. This means I can run and debug my ruby scripts from within my C development environment.. totally cool.

I came a cross a weird problem with a non-obvious solution that I'll record here to help other unfortunates. When I tried to run my ruby script I was getting the error:

"the specified jre installation does not exist"

which had me puzzled as eclipse was running fine with the JRE I knew about.

On a hunch I went through the ruby runtime options and discovered I didn't have a ruby VM set up. I created one, pointed it at my ruby installation and, joy of joys, the problem went away and I can run ruby from within Eclipse.

Similarly the RI Ruby Documentation viewer kept timing out with a 'Invalid thread access' error until I went into the ruby settings and pointed the rdoc and ri handlers at the 'c:\ruby\bin\rdoc.bat' and 'c:\ruby\bin\ri.bat' files.

Eclipse bullet point review:

• lots of features/over overcomplex, whichever way you look at it
• menu's with so many options you have to search for what you want every time you open one.
• there isn't a simple 'run' button, you have a menu full of run options to choose from
• I like the way you can install plugins for new features and there are 973 to choose from. I've mentioned Subclipse before but I've now got plugins to play with regular expressions and 'Wicked Shell' which gives me an integrated line command prompt where I can also run my makefile and see all the output.
• Misleading error messages

There's a lot to learn here, lots of workarounds and things I am discovering.

Fun times.