I have posted an update on G+ about libArduino on Google+ but I have not mentioned lib430 yet. If you were observant, the clues were to be found in the SVN repository and the build instructions. Either way it’s about time to officially tell you about lib430 and what it is. So here goes.

lib430 is not a library per se. It is a collection of libraries to cover all the most common areas. The one that is probably most interesting to anybody who is new to lib430 is libcomm which implements communication routines, both via hardware and software uart including SPI and I²C. The reason I am building it is because I would rather create proper building blocks before I start building stuff.

lib430 is licensed under a GNU GPL license, and is thus an open source project. What is important is that it remains a collection of modular and useful libraries, and as such it will hopefully grow to provide a reliable and efficient foundation for future MSP developers to build on.

How to get it.

Check it out from the Subversion repository:

$ svn checkout mspdev

That part is simple enough. Once the checkout is done you can use the “svn update” command to keep it fresh.

How to build it.

The chef is ready to serve you a freshly compiled library to use. You need, however, first either…

  • Attach your Launchpad to the computer via USB and wait for the device to be ready. This is so that our magical voodoo-induced Makefiles will be able to detect your microcontroller.
  • Define the “MCU” environment variable. In bash you do that by either putting the variable before the command (f.ex. “MCU=msp430g2553 ./chef -b”) or exporting it (f.ex. “export MCU=msp430g2553 && ./chef -m msp430g2553 -b”.)
Once we know what we want, and the chef will serve it up:
$ ./chef -m msp430g2553 -b
== Cooking for: msp430g2553 ==
 :: libair: Installing
 :: libarduino: Installing

The -b switch will tell the script to build the library for the specified mcu (-m mcu). You can also delete old libraries with the -d switch. -p to package it into a tar.gz file or -a descriptive-name to create a patch file that you can contribute to the project if you don’t have write access to the Subversion repository.

How to use it.

If you have played with libraries in C earlier, you probably know this already. If not, I will introduce you gently into the beautiful world of libraries. First of all, libraries are nothing but archives (or compressed folders if you prefer) containing object files (.o). So, when you link with a library, you link with the object files in there.

As such, you can provide the library as an input file to the linker, or you can keep the files in a known location and use the -llib (lowercase “L”)switch to link to the library. Both of these alternatives do require you to use the -Ipath (capital “i”) option to specify the path where the include files can be found. If you have copied the include files and the library files (extension “.a”) into your project, a simple -I. will suffice. Otherwise you need to provide the path to where they are located on your filesystem.

The -l (lowercase”L”) alternative however requires you to provide yet another path, the location to where the library files can be found using the -Lpath argument. Without this the compiler won’t be able to find the libraries much less link them. Also, you strip the “lib” part of the files when specified with -l, so as such “libfoo.a” becomes “-lfoo”.

Making things easier for us are the makefiles that you can find in the skeleton folder. Copy the Makefile to your project folder, and modify the definitions appropriately:

# Source files and target binary, define your source files here to have them
# compiled, and define the target basename. An .elf binary will be created as
# well as a .hex file:
SOURCES = main.c database.c config.c
TARGET = mspov

include ../../skeleton/

LIBS = -L../../lib430/$(MCU)/lib
INCLUDES = -I../../lib430/$(MCU)/include
LIBS += -lair

Take notice to the fact that the include statement is defined before the library definitions. This is because the MCU variable will be in the include, and it is needed to find the appropriate paths for the LIBS and INCLUDES variables.

Now you know how to set up the building. Now how to actually use it. The best way to figure that part out for now is by looking at the include files. Doxygen will eventually be used to automate documentation building. Either way, once the code is in place,  just type “make” to build your project.


You can contribute by providing patches. These patches should be sent to the lib430 list at SVN write access can be arranged for contributors.

More Information.

  • Hyperlinked Markdown: lib430 README
  • Supported Compilers: GCC
  • Supported Microcontrollers: TI msp430 series
  • Language: C (GNU)