Diving into the MSP 430

We recently started working the MSP 430 RF2500.  It’s the basic MSP 430 processor, with the addition of a CC2500 Radio.  It’s programed in C with access to low level registers and hardware.  Thomas Watteyne, a professor at Berkley, has produced a great walk through for this device, and we have been slowly working through the different tutorials he presented, and I want to take a minute to talk about the first of three of the basic projects we’ve mastered so far.  The code for each project is included below, and in the code section of our page.

#include “io430.h”

#include “in430.h”

int main( void )

{

  WDTCTL = WDTPW + WDTHOLD;

  int i;

  P1DIR |= 0x03;              //Set LED’s to Output

  while (1) {

    P1OUT ^= 0x03;            //Toggle LED state

    for (i=0;i<10000;i++) {

      __no_operation();

    }

  }

}

First is a basic blink program. This application will toggle one of the on board LED’s, and while it’s very inefficient power wise it shows some of the basics for working with an MSP.  The two important commands here are P1DIR and P1OUT.  P1 refers to port 1 of the 4 available on the MPS, each with 8 pins of IO. DIR sets a port to either input or output based on a binary value. OUT sets the pins on a port to logic high or low, also based on a binary value.

From the MSP data sheet we can find that the on board LED’s are connected to pins 0 and 1 on port 1, so the binary to address them is 00000011.  This translates to 0x03 in decimal, as used in the code above.  The address is then bit-wise OR’d with the P1DIR to set the LED’s to outputs. To blink the LED the address is bit-wise XOR’d with P1OUT to toggle the on off state, and then followed by a for loop delay.  This is then wrapped in the while(1) loop standard to most embedded applications.

I mentioned above that this is a really power hungry application.  The problem is with the no_operation command.  This basically burns an entire clock cycle to do nothing.  Although a single no op seems trivial, notice that its wrapped in a for loop that runs 10,000 times before we actually toggle the LED’s.  The solution turns out to be to use interrupts, which we’ll go into in the next post.  Stay tuned…