I transformed a simple helloworld C program into C++ classes.  I was able to match up one-to-one the C generated assembly to a C++ equivalent.  In this example, the benefit of using C++ code is limited to namespaces.  Hopefully you can see how the usage of C++ namespaces improves readability and assists in minimizing coding errors.  Most of the C code projects end up becoming so sloppy and full of pitfalls.  Using C++ allows your code base to be small and manageable across the spectrum of projects.  The code and makefile for the project are located here.  The project was compiled with the msp430gcc toolchain on a Ubuntu host.

Setting Up

Instructions for building the msp430 gnu toolchain are at hackaday.com.  Many sites claimed to setup the Launchpad for debugging with gdb and eclipse, but none worked for me. I was able to set up debugging in eclipse as follows.  If you don’t already have it, install the Zylin Embedded CDT plugin.  I have v14.15.1 installed in Galileo (Eclipse).  It’s assumed that you have the drivers properly configured for mspdebug and that you can communicate with the Launchpad using the mspdebug command line.

Run-> External Tools–> External Tools Configuration

Select the “Program” in the tree control of the left pane and then click the icon for “New Launch Configuration”

Fill in the dialog as shown.

 

 

 

 

Run->Debug Configurations

Create a new configuration under the tree heading –> Zylin Embedded Debug (Native)

Fill in the ‘main’ tab with the project name and point to the .elf of the application that you are going to debug.

Fill in the ‘debugger’ tab with the location of msp430-gdb.  For me this was “/opt/msp430-gcc-4.4.5/bin/msp430-gdb”.  The command line is empty.

Fill in the ‘commands’ tab with the following in the ‘initial’ section and a “continue” in the ‘run’ section:

set remoteaddresssize 64
set remotetimeout 999999
target remote localhost:2000

Code Differences

So now you have a makefile for C++ projects and a couple of basic MSP430 objects.

Notice the destructors are not virtual functions in the example code.  It’s unlikely you’ll be deleting static objects, so you can eliminate a bunch of unneeded code by declaring them this way. Since they will never be called, more code space is saved by removing them entirely.  My preferred solution would be editing the linker script and discarding the destructors section.

I tried to get as close to the original C generated assembly as I could.  This required some reworking of the timer header.  The functionality of the object is changed, but it’s a closer match to the original C code with only an 8 word difference.  The startup assembly script would need modification to make the code match up entirely.  Here are the listings for the generated assembly, C version and C++ version.

There is a great series on using the gnu tools for bare metal programming and C++ at www.eetimes.com.

 

Links:

http://hackaday.com/2010/08/11/how-to-launchpad-programming-with-linux/

https://github.com/Hack-a-Day/had_launchpad-blink/blob/30c9b4c926ec2dbcca923e75b1345ceb7f16498b/main.c

http://engine12.com/files/hellomsp430/

http://mspgcc4.sourceforge.net/

http://www.ti.com/launchpad

http://www.eetimes.com/design/embedded/4007119/Building-Bare-Metal-ARM-Systems-with-GNU-Part-1–Getting-Started

http://opensource.zylin.com/embeddedcdt.html

http://mspdebug.sourceforge.net/download.html

 

© 2016 engine12