How to set up Eclipse with the gcc C++ compiler and GoogleTest on Windows7, from scratch

With no other requirement than Windows 7 and an internet connection, this tutorial walks you through all the steps leading up to a free development environment where you can code, build and unit test your C++ programs on Windows 7.

The steps and links were valid as of January 2013, but the internet is not a fixed environmnt ;-) For the most up to date information, consult the tool's own home pages.

1. Download and install the 64-bit version of Java from
    (If you will be using a 32-bit version of Eclipse, you should be able to get away with 32-bit Java)
2. Download  and install 'Eclipse for C/C++ Developers' from
    (This tutorial is based on the 64-bit Juno version, but 32-bit should also work fine)

3. Download and run the latest MinGW installer from

  When asked by the installer, check "MSYS Basic System" and the C++ compiler (Optionally uncheck the C compiler).
  IMPORTANT: Yes, you need MSYS, because it contains rm, which is used by mingw32-make when cleaning builds.
    IMPORTANT: You must manually add MSYS and GCC to your Windows PATH, the MinGW installer intentionally does not do this for you !!    (Since I installed MinGW into C:\Apps\MinGw, I added  C:\Apps\MinGw\bin\ and C:\Apps\MinGw\1.0\bin to my PATH)

4. Download GoogleTest from
   and extract the zip file contents into a local directory.
   Rename the directory to C:\Apps\googletest, so e.g. the file README ends up in that directory.
    To build the googletest library I did as the googletest README says:

        A.  Open a DOS window
        B.  cd C:\Apps\googletest\make
        C.  mingw32-make
                 (This compiles the library)
        D.  ar -rv libgtest.a gtest-all.o
                 (This create the library libgtest.a out of the file gtest-all.o)
At this point, all the tools are installed.
The remaining steps will all be carried out in Eclipse, so start up Eclipse.

5. In Eclipse, create a brand new project for our C++ code:  
              Click File | New | C++ Project
              Project name: my_fist_tdd_project
              Project type  : Executable, Hello World C++ Project
              Toolchains    : MinGw
    The project Eclipse creates is empty, except for 6 include patchs for MinGw.

6.  Change the project's builder to MinGw's builder:
               Click Project | Properties | C++ Build | Tool Chain Editor
               Select 'GNU Make Builder' in the 'Current builder' pull-down list.
               Click Apply

7.  Change the project's build command:
               Click Project | Properties | C++ Build
               Select '[All configurations]' in the 'Configuration' pull-down list.
               Uncheck 'Use default build command'
               Enter 'mingw32-make' in 'Build Command'.
               Click Apply

8. You should now be able to test your build settings:
               Click Project | Build project
               The message "Info: Nothing to build for " appears in Eclipse's console.
9.  Add the path of googletest's header files to the project's include paths:
               Click Project | Properties | C++ Build
               Make sure the selected build configuration is Debug (It is by default)
               Click Settings | Tool Settings | GCC C++ Compiler | Includes
               For the 'Include paths (-I)' list, click the green plus sign, then the File system.. button.
               Browse to googletest's 'include' directory, and select it. (C:\Apps\googletest\include)
               The absolute path now appears in the list box.
               Click Apply

10.  Add the path of the googletest library to the project's linker paths:
               Click Project | Properties | C++ Build
               Make sure the selected build configuration is Debug (It is by default)
               Click Settings | Tool Settings | MinGW C++ Linker | Libraries
               For the 'Libraries (-l)' list, click the green plus sign.
               Enter 'gtest' in the pop-up window.   (Note: not 'libgtest.a')
               This library name now appears in the list box.
               For the 'Library search path (-L)' list, click the green plus sign, 

                  then the File system.. button.
               Browse to libgtest.a's directory, and select the dir. (C:\Apps\googletest\make)
               The absolute path of the directory now appears in the list box.
               Click Apply
11.  Add a source folder:
              Click File | New | Source folder
              Folder name: src    (Or whatever you prefer)

Now, in the final step, let's test our environment for completeness:

12. In the new src source folder, click File | New | Source file
      Name it Counter.h and fill it with:

        class Counter {
                int counter_;
                Counter() : counter_(0) {}
                int Increment();

    Add a second file Counter.cpp in the src folder, and fill it with:

       #include <stdio.h>
       #include "Counter.h"
       int Counter::Increment() {
           return counter_++;

    Add a third file Counter_tests.cpp to the src folder, and fill it with:

       #include <iostream>
       using namespace std;
       #include "gtest/gtest.h"
       #include "Counter.h"

       TEST(Counter, Increment) {
          Counter c;

          EXPECT_EQ(0, c.Increment());
          EXPECT_EQ(1, c.Increment());
          EXPECT_EQ(2, c.Increment());

          cout << "Congratulations, you have just run a test :-)" << endl;

       int main(int argc, char **argv) {
           ::testing::InitGoogleTest(&argc, argv);
          return RUN_ALL_TESTS();

    Click Project | Run
    and expect to see the output from Counter_tests.cpp in Eclipse's Console window:

      [==========] Running 1 test from 1 test case.
      [----------] Global test environment set-up.
      [----------] 1 test from Counter
      [ RUN      ] Counter.Increment
      Congratulations, you have just run a test :-)
      [       OK ] Counter.Increment (0 ms)
      [----------] 1 test from Counter (0 ms total)

      [----------] Global test environment tear-down
      [==========] 1 test from 1 test case ran. (0 ms total)
      [  PASSED  ] 1 test.

The set-up is complete, you can now start coding awsome C++ applications, and unit test them with GoogleTest, in Eclipse.  Happy coding!


Hint: You will get the error message

          undefined reference to `WinMain@16'
from Eclipse if you forget the main() function in Counter_tests.cpp. Just copy the above Counter_tests.cpp and you should be fine.

Small script integrates DesignSpark and VeeCAD

For various reasons, I often use stripboard and through-hole components for my one-off prototypes. After trying different tools for laying out the stripbard, I've settled on a great, free niché product called VeeCAD.

Unlike most layout tools, VeeCAD is optimized for stripboards, i.e. producing a stripboard layout is pretty fast. Since VeeCAD relies on external schematic editors, so you need to import your completed netlist into VeeCAD before the fun can begin. In fact, every time you make a change to the netlist you must tell VeeCAD about it, by importing the new, improved netlist.

Now, if you're like me, your schematics drawings evolve over time. You tweak them, fix a netlist bug, replace a component, etc. And with VeeCAD, every time the netlist changes, you must click through a series of windows to get VeeCAD onto the same page as your schematic editor. ..... Hmmm......this quickly gets old.
There must be a less boring way to keep VeeCAD on top of my changes?

If your schematic editor is DesignSpark PCB (a free tool from RS Components), and you don't mind installing yet another great, free tool (AutoIt (see Wikipedia), the answer is now Yes!

Below is a small AutoIt script I made, which will click its way through DesignSparks' menus to export your (currently open) DesignSpark schematic to a temporary file, and then click its way through VeeCAD's menus to import the temp file as a netlist. Taks approximately 2 seconds.

All in one go, and without any setup or configuration :-)

The script assumes DesignSpark and VeeCAD are both running on your PC when the script starts.
Simply copy the script below into a text editor, and save it with the file extension "au3". Run it by double-clicking it.

And as always with scripts: Remember to save your work before running the script.

#cs --------------------------------------------------------------------------------------

    Are you tired of the repetetive mouse clicking required to export a DesignSpark netlist
    into VeeCad?
    This AutoIt script exports the currently open DesingSpark schematics (in Generic Netlist
    format) to a file on your hard disk. The script then imports this file into the current
    board in VeeCad (in Easy-PC format).

    (The file will be created in the same directory as this script runs from).
    The script assumes you have DesignSpark running and displaying a schematic,
    and VeeCad displaying the board you want to import the netlist into.
    Tested with Windows XP, AutoIt version, SparkDesign PCB 3.0, and VeeCAD 2.26
    Should be compatible with most versions, if not you can easily adapt it. Have fun :-)
    Standard disclaimer: Comes with no guarantee of fitness for any purpose.
    Copyright:        License: GPL version 3.0
#ce ---------------------------------------------------------------------------------------

AutoItSetOption("MustDeclareVars", 1)       ; To avoid spelling mistakes in variable names.

; ----------------------------- Define some useful variables ------------------------------

Dim $netlist_filename          = ""        ; Filetype must be .net
Dim $full_path_name_to_netlist = @ScriptDir & "\" & $netlist_filename  ; Same dir as this script

Dim $timeout_period             = 3   ;  The longest this script is willing to wait. In seconds.

Dim $veecad_window_title_start      = "VeeCAD :"     ; Try changing this if the two programs are not found,  
Dim $designspark_window_title_start = "DesignSpark"  ; but don't make the titles longer than necessary! 

Dim $veecad_windows, $designspark_windows

; --------------------- Define a handy functions we are going to need ----------------------

Func ExitIfWindowNeverAppears($window_title)
    If (0 = WinWait($window_title, "", $timeout_period)) Then
        MsgBox(48, "Script terminated.", _
            "Lost my patience waiting for the " & $window_title & " window to appear.")
    WinActivate($window_title)    ; Just in case, probably not necessary.

; ---------- Verify that DesignSpakr and VeeCAD are running, and in the correct state ------

$designspark_windows = WinList($designspark_window_title_start) ; Count the number of open DesignSpark windows

If $designspark_windows[0][0] <> 1 Then
    MsgBox (48, "Script terminated.", _
            "There must be one (and only one) open DesignSpark window!. I found " & $designspark_windows[0][0]  & ".")

If WinExists("Reports") Then
    MsgBox (48, "Script terminated.", "Can't run when DesignSpark's Reports window is open.")

If WinExists("Output Netlist") Then
    MsgBox (48, "Script terminated.", "Can't run when DesignSpark's Output Netlist window is open.")

$veecad_windows = WinList($veecad_window_title_start)   ; Count the number of open VeeCAD windows

If $veecad_windows[0][0] <> 1 Then
    MsgBox (48, "Script terminated.", "There must be one (and only one) open VeeCAD window! I found " &     $veecad_windows[0][0] & ".")

If WinExists("Import Netlist") Then
    MsgBox (48, "Script terminated.", "Can't run when VeeCAD's Import Netlist window is open.")

; ----------------- Export a netlist from the current DesignSpark window --------------------

ExitIfWindowNeverAppears( $designspark_window_title_start )
Send( "!o" )   ; "Output"
Send( "r" )    ; "Reports ..."

;   Work in the Reports window

ExitIfWindowNeverAppears ( "Reports")
ControlFocus  ( "Reports", "", 1100)

; I could not make ControlCommand work consitently when trying to
; select 'Generic Netlist' in the Reports' listbox:
;       ControlCommand( "Reports", "", "ListBox1" , "SelectString", 'Generic')
; ,so the next two lines are a work-around:
ControlSend ("Reports", "", 1100, "{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}{UP}")
ControlSend ("Reports", "", 1100, "{DOWN}{DOWN}{DOWN}{DOWN}")  ; 4th item from the top.

Send( "!r" )    ; "Run" button

;   Work in the Output Netlist window

ExitIfWindowNeverAppears( "Output Netlist" )
ControlCommand( "Output Netlist", "", 1030 , "Check")     ; Include components
ControlCommand( "Output Netlist", "", 1031 , "Check")     ; Include nets
ControlCommand( "Output Netlist", "", 1033 , "UnCheck")   ; Don't want to view netlist file   
ControlSetText( "Output Netlist", "", 1035 , $full_path_name_to_netlist )  ; Where to save file.

WinWaitActive ( "Output Netlist" )                      ; Since we have been focused on panels
ControlClick  ( "Output Netlist", "", 1)                ; Click "Generate". This also closes window.

; Close the Reports window

WinActivate ( "Reports")
ControlClick( "Reports", "", 2)                         ; Click "Close"   

; ----------------------------- Import netlist into VeeCad -----------------------

ExitIfWindowNeverAppears( $veecad_window_title_start )
Send( "!n" )   ; "Netlist"
Send( "i" )    ; "Import"

ExitIfWindowNeverAppears( "Import Netlist")
ControlCommand( "Import Netlist", "", "TComboBox1" , "SelectString", 'Easy-PC')  ; Netlist Format
ControlSetText( "Import Netlist", "", "TEdit1" , $full_path_name_to_netlist )    ; Netlist Filename

WinActivate( "Import Netlist")                    ; Focus on window, since we have been focused on panels
ControlClick( "Import Netlist", "", "TButton5")   ; Click "Import"   

; ------------------ Good, we're all done with the export and import -------------

MsgBox(0, "Done!", "Netlist export and import finished.")  ; Comment out this line to skip confirmation.


The above script works by pretending to be a human operator clicking a mouse and selecting menu items by name reference. Should the developers behind DesignSpark or VeeCAD in the future decide to rename the controls in their GUIs, the script may stop working. In that case, have a look inside AutoIt's excellent Help function and I'm sure you'll figure out how to tweak my script to make it run again :-) 

Have fun!

Beautify your legacy C code layout for "free"

When I read code, it often strikes me how an unexpected code layout can slow me down and waste my time. I quickly develop a rash when I come across C code formatted like this:

void command_Ping(Transaction_t* RequestIn,
    Transaction_t* RequestOut)

    SomeStruct_t *Input;
    VeryDifferrentStruct_t* Output   ;
    DataIn_t DataInput;
    MyData_t* DataTest;
   int SampleLoop=1, OuterLoop, InnerLoop;
    static Bit16_t  SampleNumber  =0;
    Output = (VeryDifferrentStruct_t*) &RequestOut->Param;
   if ((RequestIn->Param2 & HIGH)== HIGH)
#ifdef SIM /* Applicable for simulator */
    } else {
   if ((RequestIn->Param2 & LOW) ==LOW)

But if you work with a legacy system, you can't improve the above code, because *any* code change in a system without automated tests comes with a severe penalty: extensive, manual regression testing.
So we don't fix it, and the ugly code stays in the system forever, awaiting the next unsuspecting developer that comes along.  Over time, both you and the system become increasingly miserable.

But wait, there is hope!! The reason we don't change ugly code layout by hand is the risk of introducing new bugs, right? What if there was a guaranteed bug-proof way to change source code layout? Then we could safely drop the expensive manual regression test, and legacy systems would see a brighter future :-) Yeah!

As you may have guessed by now, the secret is to let an automated "indenter" tool make the layout changes, through whitespace removal/adding. Assuming that the tool itself is bug-free, the code that comes out of the tool will look unchanged to the C compiler, i.e. containing exactly the same bugs as the original code, and no new ones. But to you and me, the code will look much more in line with our expectations for cleanly written C code:

void command_Ping(Transaction_t *RequestIn,
                  Transaction_t *RequestOut){

    SomeStruct_t           *Input;
    VeryDifferrentStruct_t *Output;
    DataIn_t               DataInput;
    MyData_t               *DataTest;
    int                    SampleLoop   = 1, OuterLoop, InnerLoop;
    static Bit16_t         SampleNumber = 0;

    Input  = (SomeStruct_t *) &RequestIn->Param;
    Output = (VeryDifferrentStruct_t *) &RequestOut->Param;

    if ((RequestIn->Param2 & HIGH) == HIGH) {
#ifdef SIM /* Applicable for simulator */
        CallSim(&RequestIn->Param, &OuterLoop, LOOP & 8);
        memcpy(Output, Input, PACKET_PARAM_SIZE / 2);
    else {
        if ((RequestIn->Param2 & LOW) == LOW) {

    RequestOut->Length = RequestIn->Length - 6;

(OK,  maybe your expectations are different from mine, but the code is easier to read now)

Spoiler: The above code transformation was produced by the open-source tool Uncrustify, using a settings file I generated after some hours of tweaking 350+ Uncrustify settings in UniversalIndentGUI. (Wikipedia)

The beautifier tools I've looked into typically spend a fraction of a second on improving a large C program. So basically, if you point the tool to your large C/C++ system, all .c, .cpp, .hh and .h files will be beautified in less time than it takes you to finish lunch. All that is left for you is to check the improved sources back into your CVS. No regression testing required!

And it gets better: regardless of your platform (Linux, Mac,Windows), you will find high-quality open-source C/C++ beautifiers on the www. To cut your chase short, I strongly recommend you to download and install the "meta tool" UniversalIndentGUI, as it will enable you to try out the 20+  different beautifiers it comes bundled with (e.g. Uncrustify, GreatCode, BCPP, GNU Indent, and others).
And most importantly, UniversalIndentGUI will allow you to see the immediate effect on source code layout as you tweak the numerous settings offered by the different tools. The interactive process UniversalIndentGUI offers for exploring settings will save you hours, as you work on the settings for your preferred layout.

When you are happy with the results in UniversalIndentGUI, simply export the settings file, and point your selected beautifier to it. (Or you can freely grab my Uncrustify settings file here. Tested with Uncrustify 0.53)

No code layout or style will please everyone in a team of developers, but with an automated beautifier, you can significantly improve source code readabilty in legacy systems, (almost) for free.

Happy beautifying!

Continuous Integration trades fear for instant gratification

Automated build and test (a.k.a. Continuous Integration) has rapidly become the way to develop IT systems. There are many reasons for this (a maturing IT industry, availability of C.I. tools, etc), but I think the most powerful driver is the sheer enjoyment a developer can derive from the C.I. process, in particular:
  • Instant feedback on how good you code is (as measured by unit tests), determined in a risk-free environment
  • The ability to fix a bug (found by unit testing or other automated testing methods) while the program flow, class structures, etc are fresh in your mind.
In short, Continuous integration is a perfect match for a world where instant gratification is the default expectation.

Now, contrast this to the working environment for anyone maintaining a complex IT system built 10-15 years ago, i.e. a legacy system without automated testing facilities:
  • Every code change is associated with fear ("Will this change have any unwanted side effects?", "Will I lose my job if a destructive side effect sneaks past the fallible, manual testing stages into Production?")
  • A high percentage of the bugs reported from Production will be of the "Duh! How could we have missed this bug before deployment?" category, quite simply because a completely manual test regime is bound to have incomplete coverage. And that's exactly the category of bugs which make the poor maintainer look incompetent.
If you've tried both worlds, you are not going back. Continuous integration is here to stay.

Why I use Perltidy, or Why coding style matters

There are Few.
areas of programming that-are more likely to, cause religious wars than! coding: standards some developer's

       consider. coding style? to be an area where personal freeDom should reign supreme unrestricted by team project; or company standards but as
text hopefully    demonstrate punctuation-indentation-etc is important WheN conveying ideas and thou'ghts in a written form.

OK, if you made it this far down into my post, I promise to stick to the standard rules for punctuation and capitalization of English. By now you probably agree that reading speed and comprehension is affected when the writer ignores commonly accepted practices. Only when the text format matches your expectations can you focus your attention fully on the message, instead of the format. Of course, the same principle applies to reading source code.

One of many, many gems the Perl community has produced is Perltidy, a great source code formatter for Perl code. The details are here:

Simply by using this as my .perltidyrc parameter file:

#----------------  PBP options, as listed on page 35 of PBP  ----------------
-l=78   # Max line width is 78 cols
-i=4    # Indent level is 4 cols
-ci=4   # Continuation indent is 4 cols
-vt=2   # Maximal vertical tightness
-cti=0  # No extra indentation for closing brackets
-pt=1   # Medium parenthesis tightness
-sbt=1  # Medium square bracket tightness
-bt=1   # Medium brace tightness (for non-code blocks)
-bbt=1  # Medium block brace tightness (for code blocks)
-nsfs   # No space before semicolons
-nolq   # Don't outdent long quoted strings
        # Break before all operators:
-wbb="% + - * / x != == >= <= =~ < > | & **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
# Note that the PBP book has a typo on page 35 when defining the above -wbb
# option, see
# The above string is correct.

#----------  Perltidy default options (i.e. in line with PBP)  --------------
-asc    # Add any missing optional semicolon at the end of a line
-aws    # Add certain whitespace to improve code readability
-tqw    # Default handling of multi-line 'qw' quotes
-ibc    # Indent block comments to same level as the code
-msc=4  # Minimum 4 spaces between code and same-line comments
-fpsc=0 # Don't try to line up all comments to a fixed column
-hsc    # Align hanging side comments
-sbc    # Enable static block comments
-nssc   # No special handling for static side comments
-dnl    # Delete old newlines
-bbc    # Ensure a blank line before every full-line comment
-bbs    # Ensure a blank line before every sub definition (except one-liners)
-bbb    # Ensure a blank line before code blocks (for, while, if, ....)
-lbl=8  # Minimum number of lines between each -bbb inserted blank line

#-------------  Additional options, based on PBP recommendations  ------------
-bar    # K&R style code braces
-nolc   # Long comments indented, even when this make the total line length "too long"
-noll   # Long lines indented, even when this make the total line length "too long"
-nola   # Don't treat labels as special cases when indenting

#----------  Options concerning Perltidy's input and ouput files  -----------
-nst    # Do NOT output to STDOUT (since we want to use -b)
-b      # Backup the input file to .bak and perform all tidying in the original file
-se     # Write errors to STDERR
-ple    # Preserve the EOL character(s). E.g. in case Perltidy runs
        # on Windows, but processes a Perl file for Unix (and vice versa)

#-----------  Some other Perltidy options, intentionally not used   ----------
# The following Perltidy options are NOT consistent with PBP and should NOT be used:
# -lp, -icb, -fws, -nwls, -nwrs, -sfp, -sak/-nsak, -csc/dcsc, -fnl,
# -ce, -bl, -sbl, -bli, -blil, -bbvt, -otr, -sct, -boc, -kis,
# -pbp (because the -wbb list typo in the PBP book carried over to Perltidy (!))
# The following Perltidy options are not used, for other reasons:
# -sot, -mft, -cab, -bol, -bok/-nbok, -bot/-nbot, -iob, -isbc

I am free to sputter butt ugly code like this:

   sub  manipulate_some_data{

my $self   =  shift; my $data = shift;
# Sometimes add to the data we received
if($data  eq 'good data'  ){
$data.= ' is now even better.'
;}return $data;}

via my keyboard, and have it instantly transformed to this:

sub manipulate_some_data {

    my $self = shift;
    my $data = shift;

    # Sometimes add to the data we received
    if ( $data eq 'good data' ) {
        $data .= ' is now even better.';
    return $data;

by Perltidy. Without wasting a single of my overworked brain cells.
(I have configured my IDE to run Perltidy every time I save my source file to disk)

(Click here to download the above .perltidyrc file, if your're too lazy for a copy&paste operation)

Perltidy cleans up my code while I develop, which is great, but the true benefit of Perltidy becomes apparent when you or someone else tries to understand your code 4 weeks later: Since all code you and your teammates produce have the same layout, everyone reads code a little faster and get a quicker understanding of what is intended.

This positive effect is particularly evident when fixing a bug or adding some small feature to existing code, because in these situations you typically spend most of your time skimming code, and only a small portion of your time on the few, new lines.

Perl has crossed oceans and climbed mountains to make hard things possible, don't sacrifice this hard-earned property by leaving messy, sloppy, ugly code behind. Clean it up as you go along, by running perltidy from your IDE, and/or as part of your versioning system's commit process.

Free lunches are hard to come by. Perltidy is one of very few I've come across.

C++0x learns some tricks from Perl

Perl 6 has been in the making for some time, but so has also the long awaited upgrade of C++, aka C++0x (Wikipedia). Now the Working Committee for C++0x has released their 1310 pages draft, i.e. the proposal for the new C++ standard (Download the .pdf here).

The list of proposed changes to the core language and its libraries is extensive, but some of the changes are particularly interesting for us Perl developers: C++0x is about to embrace some old-time favorite features from Perl! Assuming the proposed changes are voted into the new standard, C++ developers will in a few years be able to take advantage of these cool features:
  1. The for_each keyword becomes part of the core language, to allow easy iteration over a function, of all elements of a sequence (see page 855). OK, not as cool as Perl's iteration over all elements of a list, but still quite useful.
  2. The Perl workhorse associative arrays, better known as hashes, become part of the C++ standard library (see page 794). The proposal goes further than Perl 5's hashes, by defining 4 different hash types. The 'unordered set' hash type looks an awfully lot like a Perl list.
  3. Regular expressions get their own, standardized library (see pages 1060-1095), where the well-known Perl functions s/// and m// find their equivalents in regex_replace, regex_search and regex_match .
The 1300 pages draft is a brick, but when the votes have been counted and the C++ compilers have been upgraded in 2-3 years time, C++ will be a more powerful language.

Installing Eclipse and the EPIC plugin for Perl

I prefer Eclipse for my Perl development. Just in case you've been living under a rock the last 5 years (or have been stuck in the MS Visual Studio sphere), here is the link to the Eclipse community, where you will find instruction for downloading the Eclipse IDE.  Be warned, the Eclipse community comprises tens of projects, and the web site is not completely intuitive....
For Linux users you are probably better off installing through your distributions package manager. Faster and safer.

Important: Get the Eclipse IDE for Java, since it comes bundled with ant, which you will need for EPIC. (Alternatively, install the Eclipse Platform version, then install ant). On Ubuntu you also need to install the eclipse-pde package (the Eclipse Plug-in Development Environment), it only takes a few seconds in Synaptic.
EPIC's installation instructions claim you only need the Eclipse Platform version, I have found this to be incorrect.

So what is this EPIC thing, you say? Well, for Perl development the EPIC plug-in is what makes the whole difference: A Perl perspective, syntax coloring, variable name completion, error messages next to the troublesome statements in your source, Perl Critic integration, perltidy, single stepping with variable watch, etc, etc.  In short, you don't want to develop Perl in Eclipse without it.

Installing the EPIC plug-in in Eclipse is really simple, similar to other plug-in installs. Just add the right URL under Eclipse's Help | Install software .... menu option, and off you go! To learn more about this great plug-in, head over to the official EPIC web site, where you will installation instructions and other useful info.

The Eclipse/EPIC combination makes for a great IDE for Perl development. I use it regularly on both Windows and Linux machines.

Still in love

Ever since I first got exposed to Perl, the beauty and fluidness of the language continues to impress me. Just like C++, Perl has a steep learning curve, but as your abilities mature you start to appreciate the finer details of the language, and its culture. is an excellent example of the pure joy Perl programmers share; Jos Bouman's talks about the inner secrets of Perl and perl at Nordic Perl Workshop 2006.

The video was published by Oslo Perl Mongers, click their logo to see other videos they've made available.

CodeWarrior meets Eclipse, download Beta now

Having used Eclipse for some years I was relieved to hear that Freescale was merging CodeWarrior with Eclipse. Finally, a Freescale IDE for grown-ups!

To me, Freescale's CodeWarrior IDE for microcontrollers always looked a little outdated. The drab color scheme, the quaint icons, and the tiny window for error messages gave a less than sophisticated impression.
Don’t get me wrong; you could edit and build source code quickly, and to program your microcontroller target was a no-brainer. Single-stepping your target was equally easy, so in essence CodeWarrior IDE did exactly what it promised. But just like other microcontroller IDEs I’ve used, CodeWarrior felt confined.

So how does the Eclipse-based Beta version do? Here are some of my initial observations:
  • Yes!! It looks and feels like Eclipse!
    To someone who’s never tried Eclipse before the concepts of views, perspectives, launch configurations, etc. may be confusing at first. But this flexibility comes at a modest prize: Spend some time in the IDE, and the initial frustration will melt away.
  • Importing  your existing CodeWarrior projects into CodeWarrior for MCU v10.0 is a breeze, just start the Import Wizard from File | Import …. and browse to the CodeWarrior Project file (*.mcp).
  • Where the difference between previous versions of CW and the Eclipse-based version becomes very obvious, is when you attempt to program the microcontroller’s flash for the first time. Where you before could simply click an icon, you now have to create a launch configuration. (Freescale’s site has a nice little video showing you how to get this right the first time, don't worry).
    Once over this hurdle, programming your target’s flash is only a couple of mouse clicks away.
  •  I had the DEMO9S08QD4 demo board from P+E Micro lying around, and after plugging it into the USB port, CodeWarrior updated the demo board’s firmware. Not sure if this was really required, but it doesn’t matter, because the board still works fine under the previous CW version.
  • Yes, CodeWarrior is now available for Linux! But there is a major snag: You need to compile the USB driver for your programmer/development board.......! Linux header files, gcc and the whole shebang! This is just not acceptable, and has to become easier in the official release.
Thumbs up, Freescale.

Booting the blog !!

printf  'Hello World\n';

printf("Hello World");

PRINT "Hello World"

serial_out("Hello World");