How-to: Launchpad programming with Linux
posted Aug 11th 2010 1:00pm by Mike Szczysfiled under: how-to, Microcontrollers
When TI released their Launchpad development board at the end of June it generated a lot of Buzz. Here’s a package that delivered a programmer, debugger, two microcontrollers, and some accessories for less than five bucks (including shipping). They even provided a choice of two software suites but only for users running Windows who don’t mind proprietary software. If you’re looking to go another way you should consider trying out the open source alternative MSPGCC. After the break we’ll take a look at getting the tool-chain up and running in a Linux environment.
We’ll be working with Ubuntu 10.04 Lucid Lynx. When the Launchpad is connected to USB it is identified and mounted to /dev/ttyACM0. It’s not immediately apparent how to use the device but fortunately it can be done. To talk to the hardware for programming and debugging we’ll need to use MSPDebugger. For compiling our code we’ll be using the MSPGCC open source compiler package.
Compiling and Installing MSPGCC
The first thing we’ll need to do is satisfy our build dependencies.
sudo apt-get install subversion gcc-4.4 texinfo patch \ libncurses5-dev zlibc zlib1g-dev libx11-dev libusb-dev \ libreadline6-dev
Now we’ll checkout the source code from the subversion repository:
svn checkout https://mspgcc4.svn.sourceforge.net/svnroot/mspgcc4
Next we enter the directory and start compiling:
cd mspgcc4 sudo sh buildgcc.sh
This will take some time so go read some posts and come back in 20-45 minutes.
To add the tools we just installed to the path, we need to edit the /etc/profile file:
sudo nano /etc/profile
Add this line to the end of the file (CTRL-X to exit once you’re done):
export PATH=${PATH}:/opt/msp430-gcc-4.4.3/bin
Now reload the profile you just edited for this to take effect:
source /etc/profile
Great, now you have the tools necessary to compile your C code into an .elf file that the microprocessor will understand. Next we’ll need a way to get that file onto the chip.
Compiling MSPDebug
We’ll use the MSPDebug instructions for downloading and compiling. First you need to go to the download page and get the latest version. We downloaded version 0.9 and will use that in the filename for the following commands. Now go to the directory where you saved that download and unpack the archive, compile, and install the package using the following set of commands:
tar xvfz mspdebug-0.9.tar.gz cd mspdebug-0.9 make sudo make install
That should take just a few seconds and it’s the last of the tools that we need. Next we can use our new software to connect with the device.
The code
It’s best to try out some proven code the first time around. Download our simple code package to test out the compiler and use the debugger for programming. This is much simpler than the temperature demo found on Ramblings and Broken Code be we are using their Makefile and once you’re comfortable with the process there’s a lot of great code examples in that package.
Unpack the code, open a terminal window, and navigate to the directory where the files are located. Compile the file by typing:
make
If that went well, great. If you get an error like “msp430-gcc: command not found” there’s something wrong with your path to the MSPGCC tools.
Connecting to the chip
MSPDebug is what we use to connect to the chip. The following command will most likely NOT work for you:
mspdebug rf2500
Spitting out the error message:
Trying to open interface 1 on 033 rf2500: warning: can't detach kernel driver: Operation not permitted rf2500: can't claim interface: Operation not permitted rf2500: failed to open RF2500 device
This is most likely caused by a permission problem. This will work if you add ‘sudo’ to the beginning but that’s not ideal. Let’s add a UDEV rule to take care of the Launchpad every time we plug it in. We need to create a rule file that has this line of code in it:
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f432", MODE="0660", GROUP="plugdev"
Use nano to open and edit this file. Press CTRL-X to exit when you’re finished, then reload UDEV:
sudo nano /etc/udev/rules.d/46-TI_launchpad.rules sudo restart udev
*** If you need more help with this, take a look at our guide to writing udev rules ***
Unplug the Launchpad and plug it back in. Make sure you’re in the same directory as the ‘main.elf’ file created by the compiler earlier. Now give MSPDebug another try:
mspdebug rf2500
Now you will be greeted with the (mspdebug) prompt. It’s just a matter of programming the chip and running that program:
prog main.elf run
Both LEDs will start blinking at about 1 Hz. Congratulations, you’ve compiled and loaded a program using open source tools.
A look into how the code works:
Let’s take a quick look into how this simple program works in an effort to get you comfortable with learning to code with MSPGCC. The keywords used in the code are defined in the include files from MSPGCC. You need to spend some time in the /opt/msp430-gcc-4.4.3/msp430/include/msp430 directory until you get used to the keywords. Once you get the hang of it you can probably guess new keywords based on what you read in the datasheets for the microprocessors.
Our code blinks two LEDs. Blinking means we need to use some method of tracking time. First let’s investigate the system clock:
Download a copy of the MSP430x2xx family datasheet (we’re using Rev. E) and follow along. This is a more useful document than the chip-specific datasheet as it lists the operating information for all of the peripherals.
Review the various system clock features in Section 5.1 paying attention to LFXT1CLK, VLOCLK, and ACLK. Next read Section 5.2 on page 289 which tells us that after power-up the system clock will be running at 1.1 MHz. If we used the system clock for timing we’re going to have trouble counting high enough with a 16-bit timer for a meaningful delay. Be we can use the auxiliary clock instead. The same page of the datasheet tells us that the ACLK is sourced from LFXT1CLK (an external crystal or clock source) but let’s change that. The VLOCLK can be used as a source for the auxiliary clock and it runs at 12 kHz, so 1-second timing is well within the range of a 16-bit counter. Let’s set up the clock source. Section 5.2.2 clearly tells us “VLOCLK source is selected by setting LFXT1Sx = 10 when XTS = 0.”. Now we just check the register description until we find that LFXT1S is set on register BCSCTL3 and then write code to implement this setting:
BCSCTL3 |= LFXT1S_2;
Next we want to set up an interrupt based on the auxiliary clock. In Section 12 you can read about TimerA. We’ll configure it to run in UP mode. On page 410 the configuration of the timer control register TACTL is covered. We need TASSELx to be set to use ACLK and MCx configured for UP mode. Notice that the settings for each portion of the register are listed in binary next to the description. We can use these to select the proper bits. Setting the MC bits to 1 (binary 01) and TASSEL bits to 1 (binary 01) with the following code:
TACTL |= TASSEL_1 | MC_1;
Now we must enable the capture/compare interrupt for TimerA compare/capture register 0:
TACCTL0 = CCIE;
Now we can start the timer by writing a value to it. Because we are using the internal very low oscillator at 12 kHz, we can count up to 11999 to keep track of about 1 second passing (0 is counted and that’s why we set the compare match for one cycle less than the clock speed):
TACCR0 = 12000;
And finally we enable global interrupts:
eint();
Now we just need some code in an Interrupt Service Routine that will toggle the LEDs:
interrupt(TIMERA0_VECTOR) TIMERA0_ISR(void) {
LED_OUT ^= (LED0 + LED1); //Toggle both LEDs
}
We pulled all of this together to make the example file. Take some to trying to understand what the datasheet is telling you. Although they can be confusing, everything you need to know is there.
Resources:
Still waiting for mine I ordered it 1 day after it came out and it was back ordered until September 13 at mouser