Digging into the RemoTI Development Kit

I’m on to the next phase – trying to use the kit and update the programming to send IR commands when prompted by the PC. This is my last ‘review’ post.

I first attached the CC Debugger to the target board and ran SmartRF, which has a simple interface to the CC2530 for reading and writing .hex files. I saved a copy of the firmware on my hard drive before doing anything.

I then ran the IAR compiler and built the RNP application – the firmware embedded in the daughter board. TI loves these 3 letter acronyms so much they barely define them. Sigh. Anyway, I uploaded that to the daughter and ran the debugger. The application ran the same as the original firmware as far as I can tell. So far I’m really impressed because everything actually worked.

The IAR IDE (two acronyms in a row!) has been a little glitchy. I can’t set a breakpoint while the program is running. I get “Failed to set breakpoint. Driver error”. Also, as noted in the TI addendum doc, during debug the IAR compiler keeps insisting the stack is full but it isn’t. I just tried to clear the pairing table and ended up with 104 pairs? Restarting the target emulator worked so this bug is probably not the firmware.

Now I’m trying to see where to intercept the request for IR output. I put a breakpoint at the beginning of a switch statement and when it hit I clicked step. I got a performance warning about single stepping and now I’ve been staring at the screen for a minute. It seems to have crashed hard. No menu, and the usual Not Responding message. Had to shut down the app.

TI’s software seems pretty clean but boy is it hard to walk through. Everything has these short 3 letter names. The C files are: rtis_np.c, npi.c, np_main.c, rti.c and the entire set of comments is: “This file contains the the RemoTI (RTI) API – Surrogate for the Network Processor (NP).” [yes it says the the]. The entire firmware subsystem is based on callbacks and queueing through the OS layer so it’s tough to walk through and debug but the architecture is appropriate to a Zigbee device and well done. There are a lot of inline comments. The visible code quality is very professional (high praise from me). Time to read the doc…

After reading the doc I have a better idea of what’s going on. The doc is often amusingly confusing but is still better than anyone else’s I’ve seen. The code compiles correctly, the debugger breakpoints well. The doc is relatively complete. Here’s a funny from the hardware doc:

And yes, I did open the remote control and while I didn’t break the remote I did snap a few of the plastic hold-downs. My bad… I didn’t snap a photo since inside the remote there’s nothing but a CC2530, a couple of LEDs (backlight?), and the usual keypress button matrix. There is a nice debugger connector in the battery compartment so you can reprogram without taking it apart.

Summary

Overall this is a good product and an incredible deal for the money. I’m still a bit worried about 8051 resource usage. I don’t think there’s a lot of horsepower left for high-level application code but it does seem to deal with the Zigbee/RF4CE protocol well. If it didn’t require the IAR compiler it would be a no-brainer. Two thumbs up.