TI MSP430 LaunchPad Temperature Demo Application


When you receive a new Texas Instruments MSP430 LaunchPad, it comes with a small demo application installed so you can easily check its functionality. The interesting thing is that it also interfaces with the PC through a virtual serial interface, but reading the data from a Linux PC appears to be non-trivial. This is partially caused by the fact that the user’s guide states that the demo application can be read with any serial console application, which in practice just doesn’t always work.

Attaching the LaunchPad

When an MSP430 LaunchPad is attached to the system, dmesg logs a few lines similar like these:

[19:52:40] usb 2-2.3: new full-speed USB device number 85 using ehci_hcd
[19:52:40] usb 2-2.3: New USB device found, idVendor=0451, idProduct=f432
[19:52:40] usb 2-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[19:52:40] usb 2-2.3: Product: Texas Instruments MSP-FET430UIF
[19:52:40] usb 2-2.3: Manufacturer: Texas Instruments
[19:52:40] usb 2-2.3: SerialNumber: 36FF49ABB1D22050
[19:52:40] cdc_acm 2-2.3:1.0: This device cannot do calls on its own. It is not a modem.
[19:52:40] cdc_acm 2-2.3:1.0: No union descriptor, testing for castrated device
[19:52:40] cdc_acm 2-2.3:1.0: ttyACM0: USB ACM device
[19:52:50] hid-generic 0003:0451:F432.003E: usb_submit_urb(ctrl) failed: -1
[19:52:50] hid-generic 0003:0451:F432.003E: timeout initializing reports
[19:52:50] hid-generic 0003:0451:F432.003E: hiddev0,hidraw3: USB HID v1.01 Device [Texas Instruments Texas Instruments MSP-FET430UIF] on usb-0000:00:1d.7-2.3/input1

According to line 9 of this logging, in this case the LaunchPad is attached to the system as ‘/dev/ttyACM0′.

Reading the data from MSP430 LaunchPad

For me only minicom (2400 8N1) was showing some data, but in contrast to what I understood from the user’s guide the received data is binary, not in ASCII.  I wrote a quick and dirty Perl script that easily allows for reading the data.

After attaching the LaunchPad and pressing button P1.3 on it, it starts to send data several times per second. Running the script below from the command line, outputs the current temperature.

Receiving serial data ...
22.2C 22.2C 22.8C 22.8C 22.8C 22.2C 22.8C 22.8C
22.2C 22.8C 22.8C 22.8C 22.2C 22.8C 22.8C 22.8C
22.8C 22.8C 22.8C 22.8C 22.8C 22.2C 22.2C 22.8C

The script is no rocket science, its main goal is to prove the LaunchPad is working properly and to act as a starting point for others.


use warnings;
use strict;

use Device::SerialPort;
use Time::HiRes qw( usleep );

my $PortName = '/dev/ttyACM0';
my $PortObj;
$| = 1;

print STDERR "Waiting for serial port ...\n";
while ( not( $PortObj = new Device::SerialPort ($PortName, 'false' ) ) ) {
print STDERR "Waiting: Cannot open serial port: $!\n";
sleep( 1 );

$PortObj->databits( 8 );
$PortObj->baudrate( 2400 );
$PortObj->parity( "none" );
$PortObj->stopbits( 1 );
$PortObj->handshake( "none" );

print STDERR "Receiving serial data ...\n";
my $newline = 8;
while ( 1 ) {
if ( not $newline ) {
# print 8 values per line
print "\n";
$newline = 8;
# try to read a byte of data
my ( $count, $data ) = $PortObj->read( 1 );
if ( ( defined( $count ) ) and ( $count != 0 ) ) {
# if data available, then convert from Fahrenheit to Celcius
printf( "%3.1fC " , ( ( ord( $data ) - 32 ) * 5 / 9 ) );
usleep( 100000 ); # wait 100ms

TI MSP430 LaunchPad from the Linux Command Line

Installing required packages

$ sudo apt-get install binutils-msp430 gcc-msp430 gdb-msp430 msp430-libc msp430mcu mspdebug


mspdebug home page

$ mspdebug rf2500
MSPDebug version 0.19 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer This is free software; see the source for copying conditions. There is NO

Trying to open interface 1 on 050
rf2500: warning: can't detach kernel driver: No data available
Initializing FET...
FET protocol version is 30394216
Configured for Spy-Bi-Wire
Set Vcc: 3000 mV
fet: FET returned error code 4 (Could not find device (or device not supported))
fet: command C_IDENT1 failed
fet: identify failed
Trying again...
Initializing FET...
FET protocol version is 30394216
Configured for Spy-Bi-Wire
Sending reset...
Set Vcc: 3000 mV
Device ID: 0x2553
Device: MSP430G2553
Code memory starts at 0xc000
Number of breakpoints: 2

Available commands:
= delbreak gdb load opt reset simio
alias dis help locka prog run step
break erase hexout md read set sym
cgraph exit isearch mw regs setbreak

Available options:
color gdb_loop iradix
fet_block_size gdbc_xfer_size quiet

Type "help " for more information.
Press Ctrl+D to quit.

(mspdebug) step
( PC: 0fcc6) ( R4: 09b66) ( R8: 0ffdf) (R12: 00000)
( SP: 0027e) ( R5: 0c7ff) ( R9: 0ff65) (R13: 0fd90)
( SR: 00000) ( R6: 0defc) (R10: 0e7ff) (R14: 00000)
( R3: 00000) ( R7: 0e157) (R11: 00298) (R15: 0ffff)
0fcc6: b2 40 6e fd 36 02 MOV #0xfd6e, &0x0236
0fccc: b2 40 6e fd 38 02 MOV #0xfd6e, &0x0238
0fcd2: b0 12 66 fd CALL #0xfd66

Driving the Adafruit mshield v1.0 from Bitlash

Bitlash is a brilliant and powerful sketch for Arduino to do your ad hoc interactive bit banging on attached hardware. Once loaded on an Arduino, you can simply connect to it with a serial terminal emulator and start typing commands.

So yesterday I decided to find out exactly how powerful Bitlash is by bit banging an Adafruit motorshield (v1.0) for a single bipolar stepper motor. The power is in the fact that Bitlash allows you to define functions that are subsequently stored in EEPROM and so you can figure out bit by bit how to control the shield. Now I’m not going through the whole step by step procedure of reverse engineering out how the shield is wired, as the resulting Bitlash code turned out pretty straightforward and there are circuit diagrams for that.

First various Arduino output pins are to be initialized as output:

function initstepper {pinmode(3,1);pinmode(4,1);pinmode(7,1);pinmode(8,1);pinmode(11,1);pinmode(12,1);d3=1;d7=0;d11=1};

  • pin 3 → enable M2
  • pin 4 → serial clock (rising edge)
  • pin 7 → shift register not(Output Enable)
  • pin 8 → serial data
  • pin 11 → enable M1
  • pin 12 → shift register latch

To save digital pins, the motor pins are attached through a shift register. This implies that motor outputs can only be changed by shifting bits into the register and latching it to its outputs. The following functions are called under water:

function bo {d4=0;d8=arg(1);d4=1;};
function latch {d12=0;d12=1;};
function dataout {bo(arg(1));bo(arg(2));bo(arg(3));bo(arg(4));bo(arg(5));bo(arg(6));bo(arg(7));bo(arg(8));latch};

  • bo → shift a single bit into the shift register
  • latch → copy the shift register contents to its output register
  • dataout → shift 8 bits data into the shift register, then latch it to its outputs

Now the tricky bit is how the bits in the data are related to the motor pins. Here is a table:

M1 x x
M2 x x
bit 0 1 2 3 4 5 6 7
M3 x x
M4 x x

The last step is to define the separate steps for the stepper motor. For a full step, eight substeps can be identified:

b5 b4 b3 b6
M1 M2 M1a M1b M2a M2b
s1 + 0 1 1 1
s2 + + 0 1 0 1
s3 + 0 0 0 1
s4 - + 1 0 0 1
s5 - 1 0 0 0
s6 - - 1 0 1 0
s7 - 1 1 1 0
s8 + - 0 1 1 0

And code that into Bitlash functions:

function s1 {dataout(0,0,0,1,1,0,1,0);};
function s2 {dataout(0,0,0,0,1,0,1,0);};
function s3 {dataout(0,0,0,0,0,0,1,0);};
function s4 {dataout(0,0,0,0,0,1,1,0);};
function s5 {dataout(0,0,0,0,0,1,0,0);};
function s6 {dataout(0,0,0,1,0,1,0,0);};
function s7 {dataout(0,0,0,1,1,1,0,0);};
function s8 {dataout(0,0,0,1,1,0,0,0);};

To run the stepper motor:

function runstepper {while (1) { s1;s2;s3;s4;s5;s6;s7;s8};};


As a bonus it is pretty simple to change the stepper´s torque. The easiest way is to PWM the shift register’s output. The function below takes a single argument (0-255).

function torque {a7=255-arg(1);};

This will however affect all four half bridges on the shield. A prettier, though lightly more complex method is to PWM the enable M1 and M2 pins (resp. 11 and 3). This allows for microstepping, but the Bitlash method is really too slow for that.