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

Custom USB Apps

Answer to "How to tweak that app that runs on the PC?"

there is a new version of the sensor monitor for the eZ430-RF2500-SEH which includes the full source code and was built using free or open source software. this might be a good start for you:

It was developed using the open source Qt
cross-platform applications framework, QWT, and compiled using Microsoft Visual C++ 2008 Express Edition, which are all freely available.

Hello World Done

Took the out-of-box access point device (the one that's in the USB stick) and converted it into an end-device, did the opposite with the end device (one that's plugged into the battery board) and re-ran the demo sensor visualizer app.

This used section 10.2 of the SLAU227D app note (Feb 2009 revision).

I would reword some of it:

10.2 point # 2:

existing :

Select Open Existing Workspace, and browse for the demo application workspace (*.eww) file. The project is available on the CD or at http://www.ti.com/lit/zip/slac139.

Problem :

Windows needs to know that you want to look at extensions for Known File Types (once you've installed IAR, .eww is a known type - and so you will not see .eww, you will only see the other files that are .ewd .ewp (when you select All Files).

Preferred wording :

Select "Open Existing Workspace", and browse for the demo application file "eZ430-RF2500 Sensor Monitor Demo vX.YZ"

Point #4 :

Existing :

Select Project -> Debug in IAR to download...

Preferred :

Select Project -> Debug using the Project menu in IAR to download...

Point #6 :

Exsting :

Select Debug --> Stop Debugging exits the debug mode while leaving the target board executing code.

Preferred :

Select Debug --> Stop Debugging to exit the debug mode while allowing the target board to continue executing the program.

FET Vs IAR

The Flash Emulation Tool costs $100. But, what does it get you over just the eZ430-RF2500 hardware? Is it only that you can protect the firmware with fuse-blow for production purposes?

How do I download code into the MCU from IAR? I don't see Project-> "Debug in IAR" in the IAR. Maybe that's a typo. Probably means "Project->Debug" in IAR.

In IAR Workbench, Unable to "Set as Active"

Kudos : Brandon E

Problem : App note http://focus.ti.com/lit/ug/slau227d/slau227d.pdf says to right-click on "Access Point" project in IAR and select "Set as Active". But, that option is grayed out when I right click. Is there a physical difference between the access point board and the end device board? I switched them out of the box just to see if I could get the firmware download right as a hello-world example.

Solution : Is the Access Point project name already in bold? Yes? That means it's already active.

There is no physical difference between the boards. Behaviour is entirely dependent on the code.