The Radio Frequency for Consumer Electronics (RF4CE) standard lets engineers create products that need basic wireless remote-control operations that can offer two-way communications. The standard allows interoperability among devices manufactured by many companies. Although the ZigBee Alliance now oversees the RF4CE specifications, RF4CR "radios" do not use an underlying ZigBee protocol. They do, however, use a standard 2.4-GHz (ISM band) PHY/MAC IEEE 802.15.4 radio that ZigBee devices also rely on.
To help developers get off to a quick start with RF4CE product designs, Texas Instruments created this kit and its own RemoTI RF4CE stack. If your development plans call for wireless remote control of household appliances and entertainment equipment, this kit deserves your attention.
The kit includes a wireless multi-button handheld remote control, a target module, a CC2530EM wireless evaluation module, a CC2531 wireless dongle (USB), a CC Debugger pod, batteries and cables. Engineers must download up-to-date code and documents from TI's website as explained in a two-page "Quick Start Guide." Setup involved attaching the CC2530EM to the target board and connecting the assembly to my lab PC through a USB cable. The Windows software "discovered" the modules and went through the usual driver-identification and setup steps without problems.
The downloaded software included a Target Emulation program that creates a graphical "RemoTI Controller Display" on the PC's screen. Written steps explain how to associate the handheld remote (HH remote) with the emulator so they can communicate. Keep in mind that the target module communicates with a PC via a virtual serial port, so you must know which port your PC has assigned to the "serial" link between them. When you start the Emulator, choose "Serial Port" and then select the proper serial port. On my lab PC, the connection used port COM22. If in doubt, go to Start-->Settings-->Control Panel-->System-->Hardware and then choose Device Manager (Windows XP). Next, click of Ports (COM & LPT) and find the COM port assigned to "TUSB3410 Device."
If you want to use the USB dongle instead, disconnect the target and wireless modules from the USB port and instead connect the dongle to a USB port. When you start the Emulator, select USB HID.
When you use either the USB module or the USB dongle, pressing buttons on the HH remote should highlight corresponding legends on the PC display. This step confirmed communication from the HH remote to the PC. The Emulator also displays the data bytes received from the HH Remote. But the "RemoTI Target Emulator (TE) User's Guide," (SWRU202A) doesn't explain what these bytes mean and how to use the information when you run tests or debug code.
At this point, TI recommends engineers print the "RemoTI Sample Applications User's Guide," (SWRU201A), which as of April 2010 exists only within the many documents downloaded from the TI's website as described in the "Quick Start Guide."† Strangely, I could not find this document on TI's website.
The "RemoTI Sample Application User's Guide" includes seven sample applications, several of which require a download of the free IAR Embedded Workbench for the 8051 processor included in the CC2530 and CC2531 wireless microcontrollers. For this software,†click here†and register. IAR will return by e-mail a URL you use to access and download the code. You also will receive a serial number and a key used to "unlock" the IAR tools. CAUTION: Download the full 30-day version of the tools. IAR's Kick Start version has a 4-Kbyte code limit, which I thought might not allow a full evaluation of the dev kit examples.
The RemoTI Dev Kit has a shortcoming: The documents lack a thorough description of how to use the RemoTI stack and how to create a simple remote-control application or framework. The samples lack flow charts or state diagrams, so I couldn't determine what must happen and in what order. The kit suffers from a dearth of basic examples and tutorials that help engineers understand the needed software components and the interaction between a remote control and a target. If TI can provide this information, engineers will have a kit they can use without having to decipher the code TI provides.
Before you start on any of the sample applications, I recommend you print and read the "RemoTI Developer's Guide," (SWRU198) and also the technology summary and technology paper provided by the ZigBee Alliance at www.zigbee.org/Markets/ZigBeeRF4CE/TechnicalSummary.aspx. These documents provide information that will help you understand how the RF4CE stack works and how TI has implemented it in the RemoTI stack. Without this information in hand you can get confused by operating-system functions and hardware-abstraction layers. Diagrams in the Developer's Guide clarify the stack operations and layer "connections."
I also recommend kit users download and print the "RemoTI Development Kit Hardware User's Guide," (SWRU211) that provides more hardware-setup details, information about the Target Module, programming Flash memory, and the CC Debugger module. You can find complete schematic diagrams and PCB-layout files for the Target Module and the HH remote at www.ti.com/remoTI. Find reference-design files for the CC2530EM board at www.ti.com/cc2530emk.
TI created the HH remote specifically for this kit, so you can access a small programming/debugging connector within the remote's battery compartment. Note that this connector has no "key," so you could improperly connect the CC Debugger pod. Read the "Hardware User's Guide" and use its diagrams to make the proper connection if or when you choose to reprogram the HH remote.
TI has done a professional job with its documents for this kit. The "RemoTI Sample Applications User's Guide," for example, defines acronyms and expressions and includes a list of eight helpful references that relate to this kit, the RemoTI protocol, and the RF4CE stack.
I noted earlier that the download from TI includes documents, which means you have the latest version that include any updates or corrections. Look in the Texas Instruments directory for the Resource Guide folder. The version I downloaded provided 15 documents, links to other information, and a list of changes from earlier RemoTI versions. I liked having these documents on hand on my lab PC.
I got off to a difficult start with the samples in the Application User's Guide because I mistook the Target Board for what TI calls the "Basic Remote Controller," or the handheld remote (my name for it). So, I tried several times to program the Target with code meant for the HH remote. It seemed logical to me that the remote control was the "thing" I wanted to control remotely, and not the HH remote. After a few hours I figured out my error and proceeded. The IAR Embedded Workbench tools worked just fine.
Unfortunately, TI calls the application that runs on the Target a "Network Processor," rather than a Target application. I used this sample application to reprogram the Target board with the factory-programmed code. After doing so, the Emulator worked well. I also ran the Emulator with the USB dongle, which also worked well.
In several places, TI leaves it to engineers to determine which type of device to program and how to program it via many "project configurations," that include a CC2530F64, CC2530F128, CC2530F256, CC2531F256, CC2530F64-HEX, and CC2531F256-HEX. But the instructions do not explain how to determine the configuration to use with devices in the kit. I found the Target MCU labeled CC2530F256, so I chose that configuration when I reprogrammed the "Network Processor " code. TI's technical writers and engineers should do a better job explaining why and how to choose the proper configuration.