In order to do an actual scientific experiment using the MSP430, we need one more tool. To be fair, we could do with what we’ve covered so far, but it requires constant (or at least regular periodic) monitoring of the equipment, and manual recording of the data displayed on the LCM. No, what we need is a way to automatically record the data when it is taken.

There are two different paths open to us at this point: the MSP430 has on-board flash memory. We could use it to record multiple measurements. The other, more complicated path is to learn how to communicate between the LaunchPad and a computer via USB. There’s some elegance in starting with the former, as our focus to this point has been on the LaunchPad itself, but unfortunately we’d need a way to transfer the data from the flash memory to a useable location anyway, which more or less requires connection to a computer. So even though it will delay getting to some of the cooler things we can do with the MSP430, it’s time we tackle serial communication. Once we have this piece mastered, we’ll start a little science experiment that will take me a few days/weeks to complete. During that time, we’ll begin looking at recording to flash, communicating with external peripherals, and how to put all the pieces together for remote data collection. We’ll also start looking at alternative power systems, system control, and other great things that will completely open the field of what’s possible with a microcontroller. The future looks bright; but first we’ll have to tackle this difficult task.

Well, things aren’t really so bleak… serial communication isn’t that complicated. In fact, most MSP430 devices have peripherals built in already for that very purpose, making it simple to do. However, of the two devices that come with the LaunchPad, only the G2231 has one of these peripherals, and it only has two modes of operation, conspicuously missing the one we really need first: the Universal Asynchronous Reciever/Transmitter, or UART. So, instead, we are going to turn to learning to implement this functionality in software.

Fortunately, there’s some real advantage to this; a solid understanding of how serial communication works helps us understand how to process and record scientific data. In fact, when we get to the USI/USCI peripherals, looking at other modes of communication such as SPI and I2C, we’ll take the time to understand how these methods send data. (The particular implementation of a serial communication system is called a protocol. There are even more protocols available, including Bluetooth, Wi-Fi, and ZigBee, which are cool things we’ll tackle some day!)

You might be asking, “Why are we going to rehash software UART? Lots of people have published articles about it already, and lots of code and examples are available.” Well, I’d respond that there are two reasons. The more philosophical reason is that you become a better scientist when you understand how the tools you’re using work; Einstein once said you don’t really understand anything until you can explain it to your Grandmother. The more practical reason is that none of the articles I’ve perused give much explanation to why the code is set up the way it is. That’s our goal here: by completely dissecting the software UART, we learn how serial communication works, and get a thorough example of using the MSP430 peripherals to our advantage in getting jobs done. We’ll also do a very thorough job, starting with just transmission (I guess technically it would be UAT), then moving to just reception (likewise UAR), then designing a full-on UART transceiver. Along the way, we’ll talk a bit about crystals as well as learn about calibrating our DCO. We’ll even talk about saving DCO calibration to the flash memory, and introduce the concept of a checksum. (So we’ll see a little bit about writing to flash memory soon after all!)

If that sounds like a lot to cover, it is. I’ll do my best to keep the posts coming regularly and quickly, so that we can move on to more advanced ideas soon. There is motivation for approaching this topic in this way at this time, however. These tutorials have always been designed as notes from my own learning. As a result, sometimes the methods/styles have been a little disjointed, but one of the goals of this blog was to put together a curriculum that could be used to teach science students in a one-semester course on microcontrollers. (After graduation, I’ll gather, edit, and format these tutorials into a book that can be downloaded for just such a purpose.) I think the material we’ve covered to this point fits about a one semester course very well, so think of this tutorial as the final project for the course. It’s a bigger concept that will take a while, but will draw on our knowledge from the other peripherals and skills we’ve learned. The fact that we’ll introduce some new ideas along the way will add to the sum total of knowledge taken away from this course. So strap in; we’re going to start the final for MSP430 101!

[via: http://mspsci.blogspot.com]

GPIO Interrupt Example

The first example we’ll do uses the Port 1 interrupts; this code is easily changed for any port number used in your particular device.This code will show how to do the DCO example we did in

Tutorial08-b

, which demonstrates changing the DCO, using interrupts.

First, we need to configure the port to use interrupts.The LaunchPad button is on P1.3, so all of our concern will be on that pin.The pin needs to be configured as an input.Since the default state of the pin is logic 1, a high-low transition (a drop from 1 to 0) should be used to signal the interrupt.We can code this using:

P1IES |= BIT3;// high -> low is selected with IES.x = 1.
P1IFG &= ~BIT3;// To prevent an immediate interrupt, clear the flag for
// P1.3 before enabling the interrupt.
P1IE |= BIT3;// Enable interrupts for P1.3

We’ve enabled the interrupt for P1 now, and a high-low transition caused by the button press will set the interrupt flag in P1IFG.The processor, however, isn’t set to recognize maskable interrupts like P1IFG.We can turn on the interrupts with:

_BIS_SR(GIE);

or equivalently:

_enable_interrupt();// Note the singular name here!It’s not interrupts.

The first method parallels the

bis.w

instruction in assembly used for this command, and can be used to configure the SR in one step with other options, such as low power modes.The second method is a little more human readable, and works well enough if you don’t need to enable any LPM’s.

Next we need to write the ISR.Something like this will work:

#pragma vector = PORT1_VECTOR
__interrupt void P1_ISR(void) {
switch(P1IFG&BIT3) {
case BIT3:
P1IFG &= ~BIT3;// clear the interrupt flag
BCSCTL1 = bcs_vals[i];
DCOCTL = dco_vals[i];
if (++i == 3)
i = 0;
return;
default:
P1IFG = 0;// probably unnecessary, but if another flag occurs
// in P1, this will clear it.No error handling is
// provided this way, though.
return;
}
} // P1_ISR

The port interrupts can be sourced from 8 port pins, and so the ISR needs to decide what to do with each possible interrupt.The switch statement in C is ideal for this task, and is used here to single out a BIT3 flag.If, for some reason, the MSP430 is flagged with a different Port 1 interrupt, it simply clears the flag and moves on.Since none of the other flags are enabled, this should never happen, but it’s good coding practice to include something like this.Error handling would be ideal, but it’s not done here.

Note that since the P1 interrupt has 8 sources and individual flags, you need to clear the flag manually.Don’t forget to do this, or your code will continually keep interrupting!This code makes use of three pre-stored values for BCSCTL1 and DCOCTL and increments through them each time the interrupt is called.These values, as well as the counter

i

, need to be global for the ISR to see them, and so they are declared outside of the

main()

function.See the whole code put together in

interrupted-1_G2211.c

.

Timer_A Example

As a second example, we’ll do something similar to a project I’m working on and turn a light on and off using a relay switch.I’ve coded this using a switch on P1.6 so that you can observe its behavior on a LaunchPad using the green LED instead of the actual relay.If you have a relay, be sure to

connect it correctly

to prevent too much current draw from your MSP430.Using the 1 MHz calibrated DCO divided by 8, Timer_A will count up to 62,500 in 0.5 s.In my actual application, I’d like to turn the light on for a few hours, then turn it off for a few hours.That’s easier to do with a slower clock, and an ideal application for the LFXT1 clock source.But, since we haven’t covered that yet and many people likely do not have the crystal soldered to their LaunchPad’s, we’ll do more frequent on/off cycles to simulate the actual process.We’ll use the DCO to turn the light on and off in 1 minute intervals.To do this, we’ll make use of the Timer_A up mode and interrupt using the CCR0 registers.(Yes, this is essentially a fancy version of blinky.Turns out “Hello, world!” is actually useful in microcontrollers!)

We configure the timer with the following:

TACCR0 = 62500 – 1;// a period of 62,500 cycles is 0 to 62,499.
TACCTL0 = CCIE;// Enable interrupts for CCR0.
TACTL = TASSEL_2 + ID_3 + MC_1 + TACLR;

The long string of assignments to TACTL are, in order, select SMCLK as the clock for Timer_A (runs off the DCO by default), select input divider of 8 (1 MHz SMCLK becomes 125 kHz), select up mode, and clear the count in TAR.These values are defined in the device header file so that you don’t have to constantly manipulate bits by hand.The mnemonics are easier to use most of the time.(For other configuration options, see the Timer_A section in your device’s header file.)

The ISR may look something like this:

#pragma vector = TIMERA0_VECTOR
__interrupt void CCR0_ISR(void) {
// no flag clearing necessary; CCR0 has only one source, so it’s automatic.
if (++i == 120) {
P1OUT ^= RLY1;
i = 0;
}
} // CCR0_ISR

Again, we’re using a global variable

i

as a counter, and presumably have defined

RLY1

to be

BIT6

in the program header.Every time a flag occurs (twice a second) the counter is incremented.If we’ve reached 120 (60 s at 2 Hz) the relay control is toggled and the counter resets.

The complete code for this example is in

interrupted-2_G2211.c

.For you impatient folks, feel free to adjust the timer period to whatever value preserves your sanity.

These two examples should get you started with interrupts.As always, feel free to ask questions or suggest other helpful tips!

[via: http://mspsci.blogspot.com]

We’re almost at a point where we have built a complete scientific instrument. The one thing the capacitance meter lacks is a way to provide the measurement outside of the debugging environment– not very convenient for working in the field. There are a number of ways we can transfer the data somewhere usable. One way that is useful for single measurements is by displaying the result on an LCD display, much as consumer meters do. We’re now going to look at using a standard alphanumeric LCD module with the LaunchPad. This project will also introduce the concept of building a custom library; by the end of this tutorial, you will have a library that you can import into future projects to add an LCD display without having to re-code the entire thing.

The LCD Module (LCM)

One disadvantage to this tutorial is that it require having an LCD display, which you might not have. If not, and are willing to purchase one, I would recommend doing so. These displays can be very useful, and are not very expensive. They come in a variety of sizes and styles– for this tutorial we will use a standard 16×2 character alphanumeric display modules, such as those found at

SparkFun.com

. SparkFun carries a variety of these modules; feel free to pick one to your liking, but be certain of a few things: it needs to be configured to run on 3.3 V and should not have been modified to accept serial input. If you’d like a larger module (such as a 20×4 display), it’s up to you, as they all work the same way. Get whatever color you’d like.

The SparkFun LCM’s utilize an ST7066 chip as the interface to the display, which is based on the ubiquitous HD44780 interface. (If the names make this sound technical, don’t worry too much about them– the important thing here is that we have an interface that translates data from the MSP430 into the commands and characters needed to control the LCM.) This interface uses an 8-bit parallel transmission for sending data to/from the display. As you can imagine, with 8 bits for data, plus another 3 bits for control, you can very quickly run out of GIO pins on your MSP430. In fact, even if we use the G2211 device without a crystal so that P2.5 and P2.6 are available, we only have 10 GIO pins available in total, so we’re short 3 pins to control the LCM (needing 11 pins) and the comparator interface (needing 2 pins) for our meter. Fortunately, the HD44780 interface (and thus the ST7066) provides a means of sending data in two 4-bit chunks, and as long as we have no need for reading data from the LCM, we can get by with 6 pins for LCM control, allowing us to just fit the comparator and the LCM into the 8 GIO pins for P1 on our G2211. We’re stretching the limits of this chip at this point, which is excellent motivation for expanding to other MSP430 devices in the future!

Connecting to the LCM

The standard LCM module has 16 pin connections (14 without a backlight). The first few connections are for power (possibly in two places, if the LCD is also backlit) and contrast adjustment. Pin 1 (labeled as Vss) should be connected to your LaunchPad ground. Pin 2 (Vdd) is connected to the LaunchPad Vcc. If you are using the backlight, pin 15 (LED+) is also connected to Vcc and pin 16 (LED-) to ground. (This is most easily done on a breadboard. If you find yourself losing track of this description, a good guide to follow is one written by

LadyAda

.) Pin 3 (Vo) controls the contrast of the screen. If you have a 10k potentiometer available, tie it to the wiper and tie the two ends to Vcc and ground for an adjustable contrast. If not, you can just ground this pin; it probably won’t look as good as it could, but it will work.

That leaves 11 pins for the control and data lines. The three control lines are pins 4 (RS), 5 (R/W), and 6 (E). The read/write (R/W) pin is not necessary here, and by tying it to ground we keep the LCM always in write mode. We won’t be able to read anything from the LCM (such as the address of the cursor, the busy state flag, etc.), but it saves us a pin on the MSP430. The Register Select (RS) and Enable (E) pins are what we’ll use to control the LCM. Finally, pins 7-14 are the data lines D0-D7 respectively. You can consider these pins much like the P1 pins on the MSP430– D0 is the first bit, D1 the second, and so on. If we used an entire GIO port on an MSP430 to control the data lines, we could connect Px.n to Dn, and by writing a value to Px, we can write the same value to D (conveniently saving us from any strange coding to accommodate changing the order). Since the G2211 doesn’t provide enough ports to do this, we’ll use the 4-bit mode instead. This mode uses only D4-D7. Leave D0-D3 unconnected for now. (Doing so prevents accidentally writing commands we don’t intend.)

For the capacitance meter, we’re going to change some of the pin arrangements to accommodate the LCM. We’ll use P1.1 as TA0.0 rather than CA1, and use P1.2/CA2 as the input to V+ on the comparator. P1.0 will control RS, P1.3 will control E, and P1.4-7 will control D4-7.

Note: P1.3 is also connected to the button– this shouldn’t affect the code, but since there is a pull-up resistor on P1.3, there will be excess current whenever we drive E low. Unfortunately, the LaunchPad is not designed with a jumper like on P1.0 and P1.6 for the LEDs, so we’ll just have to live with this. While we’re on the topic, be sure to remove the jumpers for the two LEDs and on the TXD/RXD pins.Sending Commands to the LCM

Once we’re wired up, sending commands or characters to the LCM is a straightforward task. In fact, it can even be done by hand, without a microcontroller at all! (If you’re interested in this, or would like to know more about what’s going on, see the Reader Exercise below.) The basic idea is that we write an instruction to the data pins and pulse E. The instruction is sent on the falling edge of E, which is why it’s pulsed. The instruction issues a command if RS is low, and sends a character if RS is high.

As an example, let’s look at the commands we need to set the LCM in 4-bit mode. The 8-bit binary instruction

0b001nnnxx

is the “Function Set” instruction. (Here, the n’s represent values we choose for the configuration, and the x’s imply an unused bit– these can have either 0′s or 1′s and not affect the instruction.) Bit 4 in this instruction sets the interface mode: a 1 sets the LCM to accept 8-bit instructions, and a 0 sets it to accept 4-bit instructions. So by sending the instruction

0b00100000

(or

0×20

), we configure the LCM to accept commands and characters in two 4-bit chunks instead of one 8-bit chunk. This command must be issued first in order to do anything with our 6-wire setup. We first set the data lines with

P1OUT |= 0×20;

(which also sets RS low (command mode) and E low in this wiring scheme) and then send the command by pulsing E.

The LCM does not respond instantly to the command, and there are some strict timing requirements in order for it to work correctly. Specifically, RS must be set low a certain amount of time before beginning the pulse on E. The data lines must be set a certain amount of time before the falling edge on the pulse, and must be held at that value a certain amount of time after the pulse. Then a certain amount of time must elapse before we can pulse E again. Fortunately for us, the only timing value of major concern is the time between command pulses. The other times are on the order of a few hundred nanoseconds, and at the processing speeds of the MSP430 there is enough latency to accommodate them. The amount of time needed to complete a command before accepting another can be on the order of 150 milliseconds, however, and so delays must be incorporated to handle them.

So, to recap, here’s the set of instructions needed to set the LCM in 4-bit instruction mode:

__delay_cycles(10000);// wait for the LCM to settle on power-up
P1OUT |= 0×20;// set to 4-bit instructions
P1OUT |= BIT3;// E high
__delay_cycles(200);
P1OUT &= ~BIT3;// E low
__delay_cycles(200);
P1OUT &= 0x0F;// clear the upper 4 bits

Though E can be set high before setting the data lines, it’s convenient to switch the order to prevent any timing mismatches. Note that if you use different pin connections, or especially if you use multiple GIO ports, this code won’t work exactly as is; it’s convenient to use P1.4-7 for D4-7 to be able to assign directly to P1OUT, but this is not general. If we were to swap the order, for example, to P1.4-7 as D7-4, then we would be writing

0b0100

instead of

0b0010

on the data line with this code. So be careful; either use the pin connections I’ve suggested here, or assign the data line bits individually as needed. The final line clears the data line bits to make it easier to set the next command properly.

Other Initializations: Sending Commands in 4-bit Mode

Now we have our LCM ready to accept 4-bit commands. This mode works by sending the upper 4-bits (or nibble) with a pulse on E, and then sending the lower nibble with a second pulse. With our wiring scheme, we can do this easily by the following code:

P1OUT |= ( & 0xF0);// send upper nibble
pulse();
P1OUT &= 0x0F;// clear
P1OUT |= (( & 0x0F;) << 4);// send lower nibble
pulse();
P1OUT &= 0x0F;// clear

I’m assuming here that I’ve lumped the commands to pulse E with the incorporated delays into a function

void pulse(void)

.

refers, of course, to whatever 8-bit command or character we’re sending to the LCM. If we encapsulate this set of commands into a function

void SendByte(char)

,then we can issue the next initialization commands as follows:

SendByte(0×28);// Function Set 4-bit, 2-line mode (for 2-line displays, of course)
SendByte(0x0E);// Display on, underline cursor on, non-blinking
SendByte(0×06);// Character entry mode: increment address, no display shift

After sending these commands, our LCM is ready to display whatever characters/text we want to send it. Note that to send characters, the commands are similar to above, but P1OUT must also set BIT0 (RS) to tell the LCM to receive character instructions rather than commands. In

lcddemoG2211.c

, I demonstrate this with a more generalized version of SendByte that lets you send commands and characters. It also demonstrates other commands, such as clearing the display and moving the cursor. If you have an LCM, try out the code yourself. I wouldn’t use a DCO faster than about 2 MHz with the selected delays, so if you play around with the code keep that in mind. In the next tutorial, we’ll look at how to encapsulate all of this into a custom library that we can keep on hand and how to import it into our capacitance meter project.

Reader Exercise: Not really an exercise– more suggested reading. If you’d like to know more about how the modules work and the specific commands and characters that can be sent, I suggest reading the following two articles from Everyday Practical Electronics:
How To Use Intelligent LCDs: Part One
How To Use Intelligent LCDs: Part Two
These articles are very easy to understand, and do a great job of explaining how to use the LCM.

[via: http://mspsci.blogspot.com]

The idea behind the capacitance meter is simple, but (as may be evidenced in part by the time it took me to get to this) there are some particulars that need to be resolved.

First: how do we minimize any delay in the timing due to delays from carrying out instructions? If we’re not careful, a non-negligible amount of time can pass between when we start the capacitor discharge and the timer, or between the comparator trigger and the timer capture.

Second: how do we determine what capacitances can be measured for a given configuration? Smaller capacitors will discharge more quickly, leading to shorter measurement times (meaning more error due to the digital nature of the timer). Larger capacitors take more time to charge up, and may not be fully charged when we start discharging.

The first issue is easily resolved by using features built into the Timer_A module. The second is less easily resolved, but easily understood, so we will know in advance the limitations of our code. There are a couple of things we’ll be able to do to improve it generally, but for our purposes here we won’t be too concerned about it.

New Feature of the Timer_A Module: Output

Let’s introduce here two features in Timer_A we haven’t used yet. First off, let’s look at how we can use the timer to change an output. Recall that the Timer_A module has a certain number of “capture/compare” registers built into each MSP430 device. (The G2211 and G2231 have two.) Each of these registers can drive their own output; we can program the MSP430 to adjust the output every time the timer reaches the value stored in the register. For example, we can set the output TA0.1 to set the output (to 1, that is) every time the timer reaches the value set in TACCR1. Or we can toggle the output TA0.0 every time the timer reaches the value set in TACCR0. We also have modes that allow us to use

both

registers on the same output, giving one result at TACCR1 and another at TACCR0. (This ability is used for pulse width modulation, or PWM. We’ll talk about that in an upcoming tutorial!)

Take a look at table 12-2 in you x2xx Family User’s Guide:

This table lists all of the possible modes we can use to work with the timer outputs.

New Feature of the Timer_A Module: Capture

So far we have only discussed uses of the timer in compare mode. The other mode, capturing, can be used to do precise timing of events. In capture mode, the timer records the value in TAR into TACCRx at the moment when the capture is triggered. This trigger can come externally, or it can come from internal connections to other modules, including the comparator. By configuring the timer in this way, we can record the timer value when the comparator output provides either a rising edge (going from 0 to 1) or a falling edge (from 1 to 0).

Putting It All Together

Here’s the general concept used in the capacitance meter. Note that accurate timing requires a calibrated clock, so we’ll use the calibrated 1 MHz DCO for this project. First, we connect the resistor to a timer output. (For this purpose, we’ll use the TA0.0 output.) The junction between the resistor and capacitor is tied to a comparator input, and the other end of the capacitor is connected to ground. We start charging the capacitor by setting TA0.0, and wait some specified amount of time for the capacitor to charge. The output is then reset (grounded) at the time specified in TACCR0. While the capacitor’s voltage is above the reference voltage, the output is set at 1 (assuming we tied the RC circuit to V+ and the reference to V-). When it drops below that value, the comparator output falls, triggering a capture in the timer, recorded in TACCR1. The difference in time between TACCR1 and TACCR0 is an accurate measurement of the decay time of the RC circuit from Vcc to Vref. (Note that if TACCR0 is 0, no subtraction is needed.)

Obviously the longer the time it takes to fall, the more accurate our timing measurement will be overall. But what happens if the time is longer than 2^16 microseconds? TAR rolls over, and starts counting over again; so in our code, we’ll need to account for any rollovers that may occur.

Let’s examine the comparator configuration used in the code:

void CAinit(void) {
CACTL1 = CARSEL + CAREF_1;// 0.25 Vcc ref on – pin.
CACTL2 = P2CA4 + CAF;// Input CA1 on + pin, filter output.
CAPD = AIN1;// disable digital I/O on P1.7 (technically
// this step is redundant)
} // CAinit

This sets up the comparator to use CA1 on the V+ input. If you check the MSP430G2211 datasheet, CA1 is connected to P1.1. Looking up the register description in the Family User’s Guide, we configure for CA1 on V+ by setting P2CA4. (P2CA0 also controls V+, and for CA1 should be clear.)

Now let’s look at the timer configuration:

void TAinit(void) {

TACTL = TASSEL_2 + ID_0 + MC_0;// Use SMCLK (1 MHz Calibrated), no division,

// stopped mode

TACCTL0 = OUTMOD_1 + CCIE;// TA0 sets VCTL at TACCR0

TACCTL1 = CCIS_1 + SCS + CAP + CCIE;// Use CAOUT for input, synchronize, set to 

// capture mode, enable interrupt for TA1.

// NOTE: Capturing mode not started.

} // TAinit

The timer is set up without starting. Setting TACCTL0 to OUTMOD_1 sets the output TA0.0 when TAR reaches TACCR0, which is 0 by default. Enabling the interrupt lets us keep track of overflows. In TACCTL1, we change to capture mode by setting CAP. To know how to connect the comparator, we need to check the device datasheet. Find the table called “TIMER_A2 SIGNAL CONNECTIONS” and make sure you’re looking at the one specific to devices with COMP_A+. In the Device Input Signal column, find CAOUT (internal), and note the Module Input Name in the column next to it: CCI1B. The CCISx bits in TACCTLx select the input, and in the Family User’s Guide, we see that these two bits should be set to 0b01 to select CCIxB. In the device’s header file, we find that we can set these bits with CCIS_1.

Also note that by setting SCS, we synchronize the capture to the timer clock. We haven’t started capturing yet, just as we haven’t started the timer. The code is set up to wait for the user to push the button connected to P1.3. Doing so exits LPM0, and continues the main code. The following then happens:

First, the timer is turned on. When the timer rolls over the first time, TA0.0 (on P1.5 in this code) is set, charging the capacitor. We want to wait long enough for the capacitor to charge. The code is set to wait for 10 overflows, which corresponds to about 655 ms. At this point, the comparator is turned on, and the timer is configured to reset TA0.0 at the next overflow (so we’ve actually charged for 11 overflows at this point). We let the timer capture the next event, or when the voltage at the capacitor (on P1.1/CA1) drops to the value at Vref, or 1/4 Vcc. At this point, an interrupt is triggered. The interrupt routine turns off the captures and the timer and returns to the main code. The code loops back, and starts the process again, waiting for the user to press the button to start a measurement.

Note: Before running the code as set up, keep in mind we’re using P1.1; what else is this pin used for? You’ll want to remove the TXD jumper to get the project to work properly. Thanks to RobG over at www.43oh.com for pointing this out to me… I was really puzzled by it for an embarrassingly long time!

Try running the code found in

CMeterG2211.c

. To do this, you’ll need a resistor and a capacitor. Use a 10 kO resistor and a 100 nF capacitor (it will have a label that says 104 on it) if you can. In the debugger, set the code to run freely, and push the button. The led should switch from green to red, then back to green, indicating the measurement is done. The timer has captured the event and recorded the time in TACCR1. Unfortunately, there’s no way to see this as is yet! Pause the debugger, and examine the timer_a2 registers. The time is recorded in TACCR1. For the suggests RC combination, you should have a value somewhere around 1400. (You can change from the default hex format to decimal by right-clicking the register and selecting decimal in the format menu.)

Try increasing R to 100 kO. You should see the time increase by a factor of 10. Try using a 1 uF capacitor. (You might need to increase the number of overflows to wait while charging to get something accurate here.) In the watch window, we can view the value in the overflows variable. To do this, click where the window says , and type in the variable name. With such a large capacitor, you should see the number of times the timer wrapped around before stopping. With the measured time and the known resistor value, you should be able to use the formula provided in the previous tutorial to calculate the value of the capacitor. Feel free to experiment with this program. In particular, how consistent are your timing measurements?

Aside from the lack of ability to see the timer value without using the debugger, there are a few issues to work out still in this meter. We’ll take a careful look at some of these in the future, and bring back this code to demonstrate ways we can see data and ways we can improve the timer.

Reader Exercise: Given the discussion in the previous tutorial about the accuracy of the meter, and from your own experimentation with the program, where are the major sources of error in the measurement? How consistent is the timing? What might cause the inconsistency? What assumptions have we made in the way we measure the capacitance? Once you’ve built an instrument to make any kind of scientific measurement, it’s important to identify all of these aspects. By doing so, we identify the limitations of the instrument, both those we can fix and those we have to live with. 

[via: http://mspsci.blogspot.com]

Now that we have some degree of control over the MSP430, it’s a good opportunity to introduce the low power mode.This feature is arguably one of the most important for the MSP430, and is an excellent reason for choosing this microcontroller over many others.Let’s look at how the modes work.

The operating mode of the MSP430 is controlled with four different bits in the status register.These bits are called CPUOFF, OSCOFF, SCG0, and SCG1.The first two are fairly self-evident; the first of these controls the power to the CPU of the MSP430.The second controls the power to the external oscillator (ie. crystal usually).In addition, these bits turn on/off MCLK and ACLK respectively, since those are associated with the CPU and LFXTL.The other two bits add more control over SMCLK, the DCO, and the DC generator.

In the

x2xx Family Guide

, page 2-15 shows a diagram and table explaining how the operating modes work.For our convenience, TI has defined 6 different modes that are easily accessible to us via the header files.The MSP430 starts off in Active Mode, where the CPU and all clocks are up and running.This is the mode in which we’ve been running up until now.Any time the MSP430 needs to do something, it will be in Active Mode.That’s not to say that peripherals can’t operate in the other modes.There are 5 low power modes, labeled LPM0 through LPM4.These are the commonly used configurations, and only rarely will you need one of the other 10 possible modes available with a 4-bit configuration.(One exception to that would be turning off an unused crystal oscillator that’s soldered to your LaunchPad, but not being used in your current project.More on that later.)

the

_BIS_SR()

function we saw earlier is perhaps the easiest method of using the LPMs.The header files define a set of names called LPMx_bits to help with the bit management.To enter a low power mode, simply issue the command

_BIS_SR(LPMx_bits);

with x replaced by the LPM number you’ve chosen.Keep in mind that if you want to use interrupts, you will also have to add GIE to the argument, or at least

_enable_interrupt();

before going into the LPM.

Another good thing to keep in mind is that the LPMs are distinct; you don’t need to include LPM0 to use LPM1.In fact, doing so (eg. using a command such as

_BIS_SR(LPM0_bits + LPM1_bits + GIE);

) would have undesirable side effects by adding the binary values that the header file definitions provide together.

One of the features of the MSP430 architecture is that you don’t need to tell the CPU to wake up on the interrupt, nor do you need to put it back in the LPM manually.All of this is done automatically; when an interrupt is triggered, the Status Register is saved to memory (pushed onto the stack) and reset, waking up the CPU.Once the ISR has been satisfied, the original Status Register (including the LPM setting) is popped off the stack back into its place, and the MSP430 returns to the low power state.If you require your program to wake up the chip and stay awake, you will need to include a line in your ISR to do so:

_BIC_SR(LPMx_bits);// clears the bits corresponding to LPMx and exits the low power mode

Note the different function name; _BIS_SR() is Bit Set Status Register (ie. set to 1) while _BIC_SR() is Bit Clear Status Register (ie. clear to 0).

Example using the Low Power Modes

As an example, I’ve coded up a

simple program

that plays a tone on an 8Ω speaker.The speaker I have has two pins with 0.2″ separation, and so it plugs right into the headers on the LaunchPad.To accommodate the spacing, I’m using P1.0 and P1.2 to drive the speaker.If you don’t have a speaker available, you can simulate the same idea using the two LEDs on the LaunchPad; just follow the instructions in the code and change SOUT to BIT6 and adjust the frequency accordingly.

The idea is simple; we start with P1.0 high, P1.2 low, and switch each at a given frequency.This method provides a square wave, not a pure tone, but it does work.Keep in mind that audible frequencies are generally in the 100′s and 1000′s of Hz.It might be interesting to see how low of a frequency you can hear (clicking doesn’t count; listen for an actual tone) and how high you can hear.Also, you can keep one pin constantly low and switch only the other if you want to reduce the volume.

There’s more to explore with the low power modes, and next time we’ll start playing with the low frequency oscillator to drop into the deeper sleep modes.

Reader Exercise:This tutorial’s code uses LPM0.Try out the other low power modes by using LPMx_bits in place of LPM0_bits.What happens if you try to use LPM1?LPM2?LPM3?LPM4? Can you explain why some of these work and others don’t?Those that work, is there any actual difference between the modes as implemented for this program?As you answer these questions, think about what clock is sourcing the timer and what oscillator is used for the clock.

[via: http://mspsci.blogspot.com]