Reprints

Email this Article

RSS

Submit PlanetEE del.icio.us Digg Reddit Newsvine StumbleUpon Netscape Yahoo MyWeb Live Bookmarks Fark  Submit

Font Size

What's This?

Returning to the eZ430-F2013 today, I opened up the User's Guide and read it more carefully. I finally came to a page for the Flashing LED Demo. Here are the steps I went through:

***************************************************************************

5. Flashing the LED Demo

This section demonstrates how to set up a project for the eZ430-F2013 and download the application to the MSP430F2013. The sample program will blink the LED on the MSP-EZ430D target board. Start the Workbench (Start --> Programs --> IAR Systems --> IAR Embedded Workbench Kickstart for MSP430 V3 --> IAR Embedded Workbench).

1. Use File --> Open Workspace to open the file at C:\Program Files\IAR Systems\Embedded Workbench 4.0\430FET_examples\Flashing the LED.eww. The workspace window will open.

2. Click the msp430x2xx (C – SpyBiWire) tab at the bottom of the workspace window that corresponds to the eZ430-F2013.

3. Set the correct device by clicking on Projects --> Options --> General Options --> Target and select the MSP430F2013 from the device list.

4. In the Options windows, go to FET Debugger --> Setup --> Connection --> TI USB FET to use the USB Interface.

5. Use Project --> Rebuild All to build and link the source code. You can view the source code by double-clicking on the project, and then double-clicking on the displayed source file.

6. Use Project --> Debug to start the C-SPY debugger. C-SPY will erase the device Flash, and then download the application object file to the device Flash.

7. Use Debug --> Go to start the application. The LED should flash!

8. Use Debug --> Stop Debugging to stop debugging, to exit C-SPY and to return to the Workbench.

9. Use File --> Exit to exit the Workbench. Congratulations, you’ve just built and tested your first MSP430 application.

***************************************************************************

Although the LED was flashing, I wasn't happy, since I seemed to recall the LED flashing away the last time I tried using the development tool. Had I inadvertently run the Flashing LED program without even realizing it, or did the target board come with the program already installed in memory? I don't know. In any case, I thought it would be good idea to do two things: 1) turn off the LED, 2) Turn on the LED. If I could do this, I thought I would have a better understanding of the program, and could then start the LEDs flashing again. I played around with the C code (shown below), trying to figure out how to stop the LED from blinking. The guy who wrote the program, A. Dannenburg of Texas Instruments, toggled the LED by xor'ing the I/O pin, P1.0, inside of a software loop.

#include "msp430x20x1.h"

void main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
P1DIR |= 0x01; // Set P1.0 to output direction

for (;;)
{

volatile unsigned int i; // volatile to prevent optimization

P1OUT ^= 0x01; // Toggle P1.0 using exclusive-OR

i = 10000; // SW Delay
do i--;
while (i != 0);

}

}

The exclusive-or (xor) command looks like this:

P1OUT ^= 0x01

This command is shorthand, I believe, for:

P1OUT = P1OUT ^ 0x01

where 0x01 is the hex value of 0000 0001 (by the way, 0x indicates a hexidecimal number). In essence, this command xor's whatever is currently in P1OUT with the hexidecimal value 01. P1OUT, as I understand it, is just one bit, the bit on the end of the binary number 0000 000x, where x is either zero or one. In an xor command, of course, if both values are the same (both 0 or both 1) the result is 0 and if the values are different (0 and 1 or 1 and 0), the result is 1. Suppose the initial value of P1OUT is 0000 0000. If you xor it with 0000 0001, the result is 0000 0000 and the LED turns off. The new value of P1OUT is now 0000 0000. When you xor this with 0000 0001, the result is 0000 0001 and the LED turns on and the new value of P1OUT is 0000 0001. You can see that putting this in a loop will keep the light blinking.

I figured I could stop the flashing by getting rid of the loop command and changing the hex value to zero (0x00) to turn off the LED, and to 1 to turn it on (0x01). I used 1 first, and that turned off the LED, which I thought was odd. Then, when I changed the number to 0, nothing happened. The LED stayed off. And when I re-inserted 0x01 into the program, again nothing happened. The LED stayed off. Did I break the thing? Let's hope not.

So, I went to the tried and true method for fixing any computing device. I disconnected the USB stick from the power by pulling it out of the USB port and re-inserted it. Sure enough, the LED came on and did not blink. I realized that for some reason, after you change the program, you have to pull the device out of the computer to reset it before you can run the new program (I'm sure there must be a better way to do this).

So at this point, we know that the simple command, P1OUT = 0x00 will turn off the LED and P1OUT = 0x01 will turn it back on. Let's see how we can do some variations on this theme in our next installment.

I'll breeze through the Flashing LED program now, avoiding the things I don't know anything about, explaining the things I do know, and trying to figure out the in-between things. Let's start with what I know.

P1DIR |= 0x01

As I mentioned earlier, this is shorthand for P1DIR = P1DIR | 0x01, better known as an OR statement.

The current value of P1DIR is OR'd with the hex value 01 (0000 0001) to give the new value of P1DIR. This PxDIR command is used to set the port as an input (0) or output (1). If the current value of P1DIR is 0x00 or zero, then ORing it with 0x01 will make the new value of P1DIR equal to 0x01. And if the current value of P1DIR is 0x01 or one, then ORing it with 0x01 still makes the new value of P1DIR equal to 0x01. Of course, the OR statement returns a one if either or both inputs is a one. Thus, P1DIR is set as an output.

That's it for what I know. I am wondering what the for (;;) statement means. I know what a for loop is, and from what I understand, the general form is for (initialization; condition; increment). So I guess for (;;) means there is no initialization, no condition and no increment. And since the LED keeps blinking and never turns off with this particular program, this for statement probably causes an infinite loop to occur.

The next statement I'll take a stab at is the do-while loop. This loop is fairly straightforward. i is initialized at 10000 and then is decremented by one by the do-while loop, where i-- is equivalent to i-1 and the loop continues as long as i is not equal (!=) to zero. So the value of P1OUT is set at one, the loop runs 10000 times and then P1OUT is changed to zero. Then the loop runs 10000 times again before P1OUT gets changed back to a one. The LED blinks very fast, which leads me to believe that 10000 loops doesn't take that long to process, maybe a tenth of a second or less. I tried increasing the value of the loop to 100000, but got the following error message: integer conversion resulted in truncation. I guess that's too big of a number for this microcontroller to handle. The upper limit seems to be 65000 (64K). The blinking slowed, but not that much. A better way to do it, I'm sure, is to put another loop inside the loop that's there (a nested loop). In the next installment, I'll go through the rest of the program, and then it will be time to move on.

I'll now go through the Flashing LED program step by step. Knowing what the program is doing pertains more to the C language than to the device itself, but unless you plan on programming in assembly language, you have to come to grips with C.

The first line of the program is:

# include "msp430x20x1.h"

Essentially, this tells the C compiler to include all the functions defined in the file: msp430x20x1.h. If you already have a copy of the IAR Workbench, you can open this file with a text editor and examine it. The comments in the heading of this file state:

* Standard register and bit definitions for the Texas Instruments
* MSP430 microcontroller.
*
* This file supports assembler and C development for
* MSP430x20x1 devices.

One of the lines in this file states:

#define WDTCTL_ (0x0120) /* Watchdog Timer Control */

This is followed by:

DEFW( WDTCTL , WDTCTL_) /* The bit names have been prefixed with "WDT" */

Obviously, these functions refer to the watchdog timer of the MSP430. The purpose of a watchdog timer is to issue a system reset in the event a time interval expires without software service. But it also seems that the watchdog timer needs to be disabled during debugging, which of course we are doing with the IAR Workbench tool.

Another line states:

#define WDTPW (0x5A00)

And yet another states:

#define WDTHOLD (0x0080)

These functions come up later in the program.

The next line in the program is the typical opening of a C program, the main function. It is written as:

void main (void)

In the C language, the keyword void is an empty data type. When used as a function return type as in void main ( ), it means that the function main does not return a value. How could it in this program, since on our last page we noted that for (;;) starts an infinite loop. When used in a function heading such as main (void), it means that the function main does not take any parameters.

The next line in the program is:

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

Returning to the msp430x20x1.h file, the only time WDTCTL show up is in the line:

DEFW( WDTCTL , WDTCTL_)

I believe DEFW means define word or, in other words, define a 16-bit data word. So this statement seems to be defining WDTCTL and WDTCTL_ (which seems to be the inverse) as 16-bit data. So the program statement seems to give the following value to WDTCTL:

WDTCTL = 0x5A00 + 0x0080

or in binary: 0011 0110 0000 0000 + 0000 0000 0100 0000

which equals: 0011 0110 0100 0000 or in hex 5A80, if my binary addition is right. Actually, you should not be doing the conversion from hex to binary and back to hex. But I thought I would do it here, since the binary numbers usually turn out to represent voltages in a microcontroller. What you should be doing is adding the hex numbers with a scientific calculator, like the one Windows supplies. To go from the standard Windows calculator to the scientific calculator, just click View > Scientific.

In any case, I'm not exactly sure why setting WDTCTL to 0x5A80 stops the watchdog timer. We'll look into this further as we learn more about the MSP430.

The only line we have not commented on so far is:

volatile unsigned int i; // volatile to prevent optimization

This line obviously tells you something about an upcoming variable "i". The statement calls "i" a volatile unsigned integer. (I'll have to use that one on somebody the next time I get into a heated argument.)

In addition, the programmer comments that setting the integer to volatile prevents optimization. In the C language, volatile is another keyword. Essentially volatile indicates that a variable can be changed by a background routine. I'm not exactly sure what the programmer means by this statement. Maybe we'll understand this better at a later time.

That's it for now. By studying this sample program, I think we have enough information to do some further experimentation with the hardware.

5/14/06

Now that the sample LED flashing program is behind us, I'm going to take a closer look at the detachable target board (see the figure). This board gives you access to all the pins of the microcontroller. But I can see right away that confusion may arise as I try to explain what I'm trying to do with this board. Here's why: The microcontroller pins are labeled one way, and the terminal holes on the board are labeled another way. If you keep this in mind, we can hopefully avoid any confusion.

A quick glance at the schematic shows that the sample program deals with the P1.0 output of the microcontroller. This output is connected to the LED through a 330-ohm resistor. If you look at the target board, there is a terminal for P2, and the schematic shows that it connects directly to P10, which is the P1.0 output. I checked this with a DMM to make sure, and this is indeed the case. P10 is the only output with components attached to it.

I thought it would be a good idea to exercise the I/O pins by making all of them outputs and setting them all high and then setting them all low. I figure if you can do this, then you will know how to turn on and off any electronics connected to the target boards. In order to make measurements at the terminals, you have to open the case of the eZ430-F2013 development tool, which can be done with a flat-blade screwdriver.

The program to do this consists of two steps. Make the I/O an output, and then turn the output on. Here is a simple program to do this:

#include "msp430x20x1.h"

void main(void)

{

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

P1DIR |= 0xFF; // Set all outputs to output direction

P1OUT |= 0xFF //Turn all outputs on

}

P1 includes all of the I/Os—P1.0 through P1.7. The command P1DIR indicates the direction of the I/O either input (0) or output (1). By setting P1DIR to FF (1111 1111), all eight I/Os are set as outputs. Why am I using the OR statement to do this? Just using the same technique as the sample program. P1DIR = 0xFF should work equally well. Once all the I/Os are set as outputs, P1OUT turns the outputs on or off. Again, FF is used to turn all the outputs on.

On the MSP430F2013, the eight I/Os--P1.0 through P1.7--correspond to terminals P2 through P9. If the program works, you automatically know that P2 is turned on, since the LED indicates this by turning on. The rest of the terminals need to be checked by connecting the DMM between the I/O terminal pin and ground (P14).

I inserted the development tool into the USB port on my PC and then loaded IAR Workbench. Since the sample program was still in memory, the LED was blinking. I then loaded the sample program, modified it as shown above, selected Project > Make from the menu and then Project > Debug. As usual, this turned the LED off. I removed the tool from the USB port and then put it back in. I was pleased to see that the LED was a solid green, which is an indication that Port 1.0 is turned on. I then checked Port 1.1 through 1.7 (terminals P3 through P9) with the DMM. Sure enough, all at 3.6 volts, which meant that all the outputs were turned on.

The next step is to turn all of the outputs off. Here is a simple program to do this:

#include "msp430x20x1.h"

void main(void)

{

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

P1DIR |= 0xFF; // Set all outputs to output direction

P1OUT &= 0x00; //Turn all outputs off

}

In this program, P1DIR stays the same, since we still want the I/Os to be outputs. But the P1OUT command is changed. We use an AND with P1OUT so that all of the outputs are changed to zero. I went through the same process as described above to load this new program onto the target board. After removing the tool from the USB port and inserting it again, the first thing I noticed was that the LED was off—a good sign. Checking all the ports with the DMM showed that they were all now at zero volts. So that's it. We now know how to turn all of the outputs on and all of them off.

It follows that you can turn some outputs on and some off, by figuring out what hexadecimal number to use. For example, 0F (0000 1111) turns on the first four outputs and turns off the remaining four. (P1.1 corresponds the rightmost digit of the binary number and P1.7 corresponds to the leftmost digit.) The easiest way to program this is just to use the following command: P1OUT = 0x0F.

6/11/06

Thus far I have been using the IAR Embedded Workbench IDE in a certain way. I open the Blinking LED tutorial and then modify it. I don't think this method will cut it as we move forward. To get a better handle on how to use this software, I have decided to create a program from scratch with the software and see where that leads.

From the opening screen (see page 1 of this blog) I selected "Create a new project in current workspace" and landed on a blank page (also shown on page 1). So I did what I usually do in a Windows program, I hit the New Document icon in the left most part of the menu bar. This gave me a page to work with. I suspect that you can just start programming away at this point. Eventually, I want to do some fairly elaborate programming, but for now I just want to get to know my way around the IDE.

I entered the program from page 5 of this blog that turns on all the outputs of the MSP430:

#include "msp430x20x1.h"

void main(void)

{

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

P1DIR |= 0xFF; // Set all outputs to output direction

P1OUT |= 0xFF //Turn all outputs on

}

and then saved this as a C program (.c extension). Then I selected Project>Make and it asked me for a file name. I wasn't expecting this, and I'm not sure what the "Make" extension should be. Like all non-programmers, the land of the IDE is quite foreign to me. Rather than just jumping into this, I think it's best to background myself by reading something that explains the tool and how to use it. So I went to the IAR web site to see what was available.

I located a 505-page document called "MSP430 IAR Embedded Workbench IDE--User Guide"

The URL for this document is: ftp://ftp.iar.se/WWWfiles/msp430/guides/ou430.pdf

Note that this is not the same user guide contained on the CD-ROM when you purchase the development tool.

I think it will be worthwhile to read this document. Not only should it explain how to use this particular IDE, but since so many programming ventures depend on knowing one IDE or another, it may be good knowledge to have under your belt, so to speak. I'll break here for a quick read and hopefully return before the week is out.

8/1/06

In trying to understand the IAR Embedded Workbench IDE (Integrated Development Environment), it seems like a good place to start is on page 25 of the IAR Embedded Workbench IDE--User Guide. The chapter is entitled, "Creating an application project." I'll highlight what I believe are the important points as I run through the chapter. I'll also point out anything that I don't understand.

Here's how the pieces fit together in the IDE. You start with a workspace and add one or more projects. Projects may be application or library projects.

Workspace
Project 1 (application)
Project 2 (library)
Project 3 (library)

The guide says that "each project can contain a hierarchy of groups in which you collect your source files." And "for each project you can define one or several build configurations."

The guide suggests creating a projects directory (folder), which I did as C:\projects, and then to make a copy of the tutor directory and put it in the projects directory. So after copying tutor to C:\projects, I now have a C:\projects\tutor directory.

The original tutor directory can be found at: C:\Program Files\IAR Systems\Embedded Workbench 4.0\430. This directory is created when you first install the software for the EZ43-F2013 Development Tool.

At this point, we're all ready to create an application project. Here's what the guide says:

Step 1: Create a new workspace for the tutorial application. Rather than use the ready-made workspace, I created a new one with File>New>Workspace.

Step 2: Create a new project by selecting Project>Create New Project. A project template appears, called Empty Project. I clicked OK.

Step 3: Create a name for the new project and save it in the projects directory. The guide suggests the name: project1. I followed the suggestion, of course.

The guide tells you that two build configurations are created by default: Debug and Release. The tutorial uses only Debug.

Step 4: Save the workspace with File>Save Workspace. The guide tells you to name the workspace "tutorials" and to save it in the projects directory. Filename extension is eww.

At this point, the guide tells you to add two source files to the project: Tutor.c and Utilities.c. Tutor.c contains a program to initialize an array with the first ten Fibonacci numbers and print the result.

Obviously, this program will not do anything that we can see or measure on the target board. But, we're not worrying about the hardware here, just trying to understand the IDE.

By the way, Fibonacci numbers are a series of numbers beginning with two given numbers and followed by numbers that are the sum of the previous two numbers. Utilities.c contains utility routines for the Fibonacci calculations.

Although "groups" were mentioned above, the guide points out that this tutorial project has only two files and therefore there is no need to create a group. Let's continue on.

You add source files to the project by selecting Project>Add Files. Highlighting Tutor.c and Utilities.c from the tutor directory brings these files into the project.

I'll stop here with a screen shot of what I have so far. If you have downloaded the guide yourself, you might want to run right through the tutorial.

8/8/06

It's been awhile since I've added a new page to this blog, so I had to re-read page 7 to figure out where I was. Fortunately, I took a screen shot of where I left off. When I returned to the file, it looked like it had taken on a life of its own. Besides project1, there was project2, project3, project4 and project5. Not really knowing why this happened, I just deleted the extras and got my screen back to looking like the one on page 7. But I'll check to see if this happens again and try to figure out what's going on.

For now, I'll continue where I left off. It's time to select project options. The User Guide says, "For application projects, options can be set on all levels of nodes." Further on it says, "Because these options must be the same for the whole build configuration, they must be set on the project node." Truthfully, I don't understand what this means, but will continue anyway.

The User Guide says to select project1 - Debug and then choose Projects>Options. (There's a dropdown menu just below the word "Workspace" on the left side of the screen. If you click on the down arrow, you will see project1 - Release and project1 - Debug.) A dialog box appears with a bunch of tabs. First you have to verify settings by clicking on the tabs and then set the compiler options for the project. I hit a snag trying to verify settings, since the screenshot in the User Guide doesn't agree with the screen shown on my computer. A tab called "Optimizations" is missing. The Guide acknowledges that this might happen but doesn't tell you what to do if it does happen. Ah, well.

The project is now ready to be built.

The Guide says, "You can now compile and link the application. You should also create a compiler list file and a linker map file and view both of them." I'll try my best.

Following instructions, I compiled Utilities.c and Tutor.c by selecting each file and choosing Project>Compile,. The IAR Embedded Workbench IDE creates directories (folders) called List, Obj, and Exe, which I was able to confirm with Windows Explorer. There are also list files (lst) and object files (r43) in the appropriate folders.

The list file has a header, body and end with a variety of information about the code. Rather than go through this file now, we'll save this chore to a later time.

The Guide refers to the Optimizations tab again, but doesn't really tell you how to add it to the set of tabs. Maybe this was covered in an earlier chapter of the Guide. I don't think it's particularly important at this point.

After compiling the programs, it's time to link the application. With project1-Debug highlighted, you select Project>Options and then Linker in the Category list. The options for this example are already selected, so it's sufficient to hit OK at this point.

After compiling and linking, the next step is to make an executable file (.exe). In this case, however, the executable will be one that can run on the debugger, and so will have an extension of d43. You create this by highlighting project1-Debug and selecting Project>Make. The file project1.d43 will appear in the exe folder mentioned above.

I've deliberately skimmed over some material in this section of the User Guide just to get through it. I think it's best to take a high-level view of the example program rather than getting bogged down in the details. But I will return to this section at a later date.

The last two pages of this blog were an attempt to understand the IDE better. Using the tutorial, we created a project that contains two C-language files, Tutor.c and Utilities.c. Then, we developed the executable files needed to run the programs. Again, Tutor.c is a program to initialize an array with the first ten Fibonacci numbers and print the result, while Utilities.c contains utility routines for the Fibonacci calculations.

Now we want to run the program to see if it works. This is done with the IAR C-SPY Debugger. If you think about it, there's no reason to plug the eZ430-F2013 into the USB port to run this program. It's not like this microcontroller is connected to a display. Instead, the program automatically runs on the C-SPY Simulator.

Tutor.c and Utilities.c work together to accomplish the task mentioned above. If you start the IAR Embedded Workbench IDE and open the tutorials workspace, you'll see a window with tabs along the top showing Tutor.c and Utilities.c. To enter the debugger mode, just select Project>Debug. This brings you to the screen as shown in the FIGURE. Note that the first statement of the main function is highlighted in green. This is where the program starts.

The job of a debugger, of course, is to find mistakes or bugs in a program. Since there are no bugs in this tutorial program, we'll just use the debugger to run through the program. But before we start, let's look at Tutor.c more closely. You can use the scroll bar to move from the top to the bottom of the program.

If you do this, you'll see that there are three functions using the format void function ( void ): next_counter; do_foreground_process; and main. But there are other functions, too, namely init_fib, get_fib and put_fib. You'll also see an include# statement for the header file, Tutor.h, and a variable named call_count.

Now, let's use the debugger to step through the program. We'll use two commands to do this: Step Over and Step Into. Step Over executes the next statement or instruction, without entering C functions, while Step Into executes the next statement or instruction, entering C functions. The difference between the two will be evident as you step through the program. To employ these functions, you can select them from the menu, press a function key or click on the button. Clicking on the button is my favorite.

Let's begin at the first statement of the main function:

call_count=0;

(The integer variable, call_count, is assigned the value 0.)

Since this statement is not a function, either Step Over or Step Into does the same thing—moves the cursor to the next statement.

Now the cursor highlights init_fib();

If you want to see what this function does, you cannot use Step Over, which would just move you to the next statement in Tutor.c. You have to use Step Into. When you click on Step Into, the cursor jumps from the Tutor.c program into the Utilities.c program and highlights

short i=45;

which is the first statement of the function

void init_fib( void );

This function is used to "Initialize MAX_FIB Fibonacci numbers" according to the program comment. Since MAX_FIB is a variable, it can represent any amount of Fibonacci numbers. By continuously clicking on the Step Into button, you can see how the program executes. This is a great help for understanding how the program works. In the statement, short i=45, short indicates that the variable i is a certain type of integer, and 45 is value assigned to i. Why i is assigned the number 45 is not clear to me.

The next statement

root[0] = root[1] = 1;

refers to something called root. Notice that earlier in the Utilites.c program there is this statement:

unsigned int root[MAX_FIB];

In the C language, square brackets [ ] indicate an array, in this case an array named root. The size of the array is actually the variable, MAX_FIB, which is an unsigned integer. And since there is only one variable, this is a single-dimension array. The statement

root[0] = root[1] = 1;

indicates that the first and second elements of the array are equal to 1.

Clicking on Step Into again brings you to the statement:

for ( i=2 ; i root[i] = get_fib(i) + get_fib(i-1);

The three parts of the for statement within the parentheses are initialization, test and increment. In this case the for statement starts at i=2, then i is checked against the variable MAX_FIB. If i is less than MAX_FIB, the statement on the second line is executed, after that i is incremented by 1, since i++ means to increment i by 1 (i=i+1). So what is the value of MAX_FIB? For this program, MAX_FIB is 10. You can check this by hovering your cursor over the variable MAX_FIB anywhere that it appears in either Tutor.c or Utilities.c. Where was MAX_FIB set to 10? Keep in mind that there are four programs in operation here: Tutor.c, Tutor.h, Utilities.c and Utilities.h. If you open up Utilities.h with a text editor, you'll see a define statement right at the top: #define MAX_FIB 10.

At this point in the program, the array looks like this:

root[0] = 1

root[1] = 1

root[2] is about to be evaluated.

I'll stop here.

8/27/06

Continuing from where we left off, if you click on the Step Into button, the green highlight jumps to get_fib(i) in the line:

root[i] = get_fib(i) + get_fib(i-1);

This is the line that computes all the numbers in the array. With i now equal to 2, the program will compute root[2], the third member of the array. This is the sum of get_fib(2) + get_fib(1). Let's take a closer look at the get_fib function.

Clicking once again on the Step Into button jumps to the first line of the function:

unsigned int get_fib( int nr )

This line defines the function get_fib. Information about the return value of the function precedes the function name. In this case, the return value is an unsigned integer. Information about the arguments of the function are within the parentheses. In this case, the argument is an integer variable nr. What is the initial value of nr? Hovering the mouse cursor over nr shows that it is equal to 2 (nr=2). Why is this? if you compare the two statements shown above, you'll see get_fib(i) in one of them and get_fib( int nr ) in the other. Since i=2, nr has to be the same integer value, or so it seems.

The get_fib function contains an if else statement, the first line of which is:

if ( nr>0 && nr<=MAX_FIB )

In this statement && means a logical AND. As you can see, as long as nr is greater than zero AND less than 10, the program moves to the next statement, which is a return statement that returns the value of root[nr-1], which is 1 at this point. Clicking on Step Into jumps the green highlight back up to get_fib(i-1) in the init_fib function. And clicking on Step In again repeats the process just described, except for one subtle difference: nr is now equal to the value of i-1, which is 1. Thus, the value returned for get_fib(i-1) is root[nr-1] or root[0], which also happens to be 1. So now the value of root[2] is 1+1 or 2.

Now it's back to the for loop of the init_fib function. The variable i is incremented to 2, and the process repeats until i reaches 10, and the for loop ends. You can continue clicking on Step In to watch the loop in action and can check the variables as they change after each loop.

On that note, we'll end this segment.

8/17/06

The tutorial we've been following continues with a section called "Inspecting Variables." We've already inspected variables by using the mouse "hover" method. If you select the command View>Auto, you'll see the current value of recently modified expressions. The section also explains "Setting a Watchpoint." Then the following sections cover "Setting and Monitoring Breakpoints," "Debugging in Disassembly Mode," "Monitoring Registers" and "Monitoring Memory." I'll pass on these sections for now, knowing that in the future, when trying to debug a non-working program, these sections will be much more relevant.

So that brings us to the section, "Viewing Terminal I/O." C-SPY lets you simulate stdin (standard input) and stout (standard output) with the Terminal I/O window. You can view the output of the Fibonacci program with this window by selecting View>Terminal I/O. The contents of the window depends on how much of the application has executed.

Stepping through the program can take a long time, obviously. On the other hand, running this program takes less than a second. To run the program, you can select Debug>Go or click the Go button on the toolbar, which is the button with the three arrows.

If you click the Go button with the Terminal I/O window open, the first ten Fibonacci numbers will appear in the window: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55.

That's it for now. In the next installment, we'll take a look at a design article that appeared in the February, 2006 issue of EEPN entitled, PIR-based Motion Detection: Sensor-to-Solution. This step-by-step article describes an application for the MSP430F2003 MCU. With the background gained thus far, it will be interesting to see if it's possible to implement an application like this.

Reader Comments I just started playing with the eZ430-F2013 yesterday. I'm a software developer, just new to the embedded scene. Your article helped me get a few things (in particular, using the screwdriver to open the case :). I wrote a couple of short blinking samples which I think are better than the ones I saw. They are available at http://my.opera.com/ET3D/homes/files/blink.zip (tried to upload them to the MSP430 Yahoo group, but there's no space there even for a 3K file). I hope people will find them helpful. ET -October 10, 2006   (Article Rating: ) We need a microcontroller with low power. Noone here knows how to program them. It is now my resposibility as the lead engineer to figure it out. Wikibooks said; "There are no comprehensive resources available over the internet which deal with the various design and implementation issues of this technology." Microcontroller.com said; "They won't use it if they can't program it." So how does one learn to program an eZ430? Gregg -October 08, 2006   (Article Rating: ) Great Article! Keep it up! fridmann -October 01, 2006   (Article Rating: ) Please see this post. EZ430 -->"Digital Convergence" <--- http://jledger.proboards19.com/index.cgi?board=microhacking&action=display&thread=1159024762 Verl Burkart aka. dilbert Http://www.rebootretry.blogsopt.com verlwb -September 23, 2006   (Article Rating: ) yes very useful ,now i got away with my problem....it'll be really inspiring if you could send me some projects on which i could work on. Anonymous -September 20, 2006 sir ,iam a student of sudharsan engg. college.ece dept. iam also using msp430 kit ezf2013 kit ,but whenever the debugging is over it shows fatal error.(failed to initialize device).don't no why could you please tell wat to do. R.Sriraman -September 18, 2006 I am also mostly a hardware designer, but this thing reminds me of the old 8-bit Intel 8085 on steroids. The I/O pins (at least in the small package) are multi-function, and the function depends on what embedded peripherals you are using. I am particularly interested in the 16-bit sigma-delta A/D converter. TI has a nice application on their web site that shows how to interface it to a pair of passive infrared detectors for motion detection, using COTS parts available from DigiKey. The really nice thing about the MSP430 family is the two clocks: one for the CPU and one for the peripherals (including the watchdog timer) that allows you to shut down the CPU to conserve power and wake it back up automagically with a hardware interrupt when something happens, like the A/D conversion completing or an input pin changing state. In the real world, where many things happen way sloooow, the CPU sleeps, wakes up for a few milliseconds to do only necessary things and then goes back to sleep. Programming the MSP430 for that is sort of like programming in Visual Basic, where everything is driven by events. Takes some practice to get used to thinking in terms of events, and programming that way, instead of linearly. I got a late start on this. I ordered two development kits last month and received them last week. Because you need truly random access to the documentation to quickly climb the learning curve, it is a good idea to print the relevant PDF files from the TI web site. They total about a thousand pages or so. Duplexed and bound yields three manuals, each about an inch thick, on the hardware, the C compiler, and the development environment. What a bargain for twenty bucks, even after adding in the cost of printing! I wish I could think of a killer app that would sell a hundred million of these things... maybe a personal CBR monitor you wear around your neck to warn of terrorist attacks and other health hazards? Where can I buy the sensor system on a chip for that? Howard B. Evans, Jr. -August 08, 2006   (Article Rating: ) Keep up the great work =) I am at the same point you are with the MSP430 and am interested in reading more about your experimentation. Michael -June 30, 2006 Though I primarily do HW design and haven't worked with a microprocessor IDE in ten years, I was able to modify that boring "Flash LED" program to instead slowly brighten and dim the LED on and off. It took a few iterations to get it working and it required me to exercise the debugging tools to find my mistakes. Unless you are a total newbie to this type of development environment, doing basic compiling and debugging is very easy. I too would like to see some tutorials, especially any that go beyond the basics. Howard Evans -June 26, 2006   (Article Rating: ) I have two of these units and I attended the MSP430 Day Seminar at Arrow Electronics. The chiups are quite interesting and we have gottne a bunch o guys togther on the PICLIST and the ham radio QRP-L list. I started a Blog area for the MSP430/EZ430 at <http://web.mac.com/brianbr/> where we are accumulating some samples and shoing some projects already done. We have solved the mystery of where to get that nasty little 4 pin female connector on the Traget Board to "role your own" ... I picked up a 100 of the F2013 chips and materials to make a bunch of connectors and they can be had at <http://www.wulfden.orh/msp430/> Cheers ... BBR, underhill center, vermont Brian Riley (n1bq) -June 09, 2006   (Article Rating: ) Great article, especially for someone like me who's just starting out with embedded goodies. I'll wait a while for the kits to become more 'available,' but I'll probably pick one up. Thanks much. Bruce Lane -April 17, 2006   (Article Rating: ) POST YOUR COMMENTS HERE Name: Email: Rate this article:  less useful more useful  1 2 3 4 5 Your Comments: Enter the text from the image below Please refresh the page if you have trouble reading this text.