User Guide

Thanks, that helps. One thought - is there a compiler feature that can tell the user what clocks will be active with the program he has written and what current consumption he can expect? Users, like me, who are novices are more interested in creating apps than in optimizing them. Later, when we start thinking about optimization, we would want to know where the ducks are to shoot. Such a feature in the compiler might make the MSP430 more marketable. It might already exist.

Replying to:

Execution will suspend immediately. Code execution will pickup immediately after the device is awakened. So the lines of code will execute after the device wakes back up. The operating modes are described in Chapter 2 of the Family User s Guide. You can download this from the following link:

http://focus.ti.com/mcu/docs/mcuprodtechdoc.tsp?sectionId=95&tabId=1201&familyId=342&techDoc=6&documentCategoryId=6

Please let me know if you need further assistance.

Regards,

If you have further questions please reply to this email. And see the MCU Knowledge Base located at http://www-k.ext.ti.com/sc/technical-support/mcu-kbase

-----Original Message-----
Sent: 3/9/2009 05:45:43 PM
To: support@ti.com
Subject: eZ430-RF2500 demo app question


I am using this product from TI. My question is about the MSP430. What happens when the following line is encountered by the execution unit?
__bis_SR_register(LPM3_bits+GIE); // LPM3 with interrupts enabled

does it suspend operation immediately and go into a low power mode or does it finish execution of the current program before going into LPM3?

If it suspends execution immediately, how does it make sense to suspend execution during a program containing :

SMPL_Ioctl( IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_SLEEP, "" );
__bis_SR_register(LPM3_bits+GIE); // LPM3 with interrupts enabled
SMPL_Ioctl( IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_AWAKE, "" );

or even :

while (SMPL_SUCCESS != SMPL_Link(&linkID1))
{
__bis_SR_register(LPM3_bits + GIE); // LPM3 with interrupts enabled
BSP_TOGGLE_LED1();
BSP_TOGGLE_LED2();
}

In these examples, we say go into LPM3 and then we ask it to do other things. Does execution of the program pick up where it left off? Is there an online location I can find answers to such questions?

Surprise! P1DIR and Port_1 ISR

You can't use the push button on P1.2 of the eZ430-RF2500 to generate an interrupt if you have bit 2 of P1DIR set. Nice.

And, BSP_init() - though supposedly a utility, will mess this up. So watch out.

Stage 3 - Day 2 ATR

Okay, the documentation is horrendous, but, still, kudos to the TI team for atleast putting something together that works. I think they have what it takes to send TXN soaring. But, it'll have to be a team effort.

In the demo app for the eZ430-RF2500, they're using a timer interrupt to wake the chip up and run the join-network, etc. Okay, figured that part out. Also, there's a lot of undocumented stuff scattered around like

__bis_SR_register(LPM3_bits + GIE); // LPM3 with interrupts enabled

without it being really easy to find out what the effect of this will be. Now, if they had a PDF of the source code with hyperlinks... ummm.

Stage 3 - Push Button on End Device Toggles Access-Point LED

Turning out to be not so simple as the demo code for the eZ430-RF2500 is famously unmaintainable. Wish some of those folks had been exposed to some structured programming concepts. How's someone to take this :


BSP_EXIT_CRITICAL_SECTION(intState);
}
}
}
}
}

[Wince:(] I'd rather see :

} // if( SMPL_R..
} // for
} // if( sPeer..

} // while(1)
} // main

And it gets better - function definitions without any clues about what the h they do, code snippets in the main() that really should be separate functions... If we don't need to know what they do, why not put them in the .h files? Not the best way to sell MSP430.

Stage 2 - Push Button Toggles LED on Same Board

Done. There is no quick way. You have to read a few posts and a bit of the datasheets. Nothing like being able to delegate:)

Now, for the big kahuna - probably can just scale down the temp sensor monitor.

Stage 1 - Flashing LED on Target Board

Found a thread that helped. I want to first use the pushbutton to do something on the target board itself before going wireless. Before that, Mann muss first ensure he can talk to the LED.

Fortunately, that's a piece of cake if you use the flashing_LED example by Dannenberg. You'll have to change #include "msp430.h" to #include "msp430x22x4.h" as in Adrian's example https://community.ti.com/forums/p/859/2554.aspx#2554. And, you'll have to ignore the warning that derivative and target don't match (MSP4301x11 vs 2x44 or something like that, allow it to continue)

But, moved the target board back to battery, and stuff works. A journey of a thousand miles, etc.

Wireless Hello World

What I define as the hello-world of the wireless world. Press a button here, light up an LED there. Duke's teach-science project tells you how to do this with a 433 MHz link, but you need to hook stuff up with wires and a breadboard. Or you could buy a garage door opener. Or, just use the eZ430-RF2500 from TI and do a little programming.

My goal - push the button on the End-Device target board and light up the LED on the Access-Point board. It's not that trivial since you need to know a bit about the network protocol and such, but, atleast, no messy wires making a lab out of your house.

Access-Point - connected to PC through USB for power only. Awaiting a packet that tells it to toggle the LED status.

End-Device - connected to battery board. Polls (or awaits interrupt from) push button port to send a packet to the access-point with code indicating please-toggle-LED.

What's missing in TI documentation :

Block diagram of the eZ430-RF2500 - how is the MCU connected to the CC2500 - schematic diagram is overkill.

Resources :

SimpliciTI protocol overview