|
Yesterday was a major breakthrough in the development. I've been spending all week tracking down and cleaning up bugs in the actual hardware. And finally, I was able to test most of the major ZDO and ZCL functions. This includes the ZDO device discovery and network management functions as well as the ZCL's general read/write/report attributes commands and the on/off and level control (dimming) clusters. The ZCL report attribute function is particularly interesting because you can set it to report attribute data periodically. This should work well for something like energy monitoring, where you monitor the accumulated energy usage, and upload the data to the internet periodically, say hourly. Regarding the development, I'm lucky that I decided to take the time at the beginning of the project to put together a simulator because it increased the debugging speed and efficiency more than I could have imagined. I found that there was a very high correlation between the hardware behavior and the simulator behavior, and I was able to reproduce all bugs (except driver related ones) on the simulation platform. That helped me catch a couple of really nasty bugs like a memory leak that I found. It would have taken a couple of days to debug that one in hardware, but with GDB, I just needed to set a breakpoint on memory access and then view a stack trace after the break happened. My current test setup is using two Atmel AVR Raven USB stick's interfacing to the PC via FreakUSB and the USB Communications Device Class serial emulator driver on it. I've also implemented an identical command line interface as the simulator so that it's easy to go back and forth between hardware and simulator with no differences in commands. I'm also using the Daintree Network Analyzer I just got and it's much more useful than I expected it to be. I caught a couple of protocol errors, some bad decisions in my ZCL interpretation, and many constants that I needed to modify to be Zigbee compliant. Interestingly enough, I'm using the Zigbee Pro decode mode and my stack is still decoding okay...heh heh. Hopefully within a week or so, I'm going to put together a document on how to use the simulator and hardware command line interface and all the commands that have been tested so far. I'll be releasing the code and documentation together, since it doesn't make sense to release one without the other. The number of commands in the command line interface has increased to about 40 and it's quite useful for exercising the stack, and even adding customized commands. Unfortunately, without documentation, it's going to be a pain in the ass to figure out how everything works. I'm also going to describe my test setup, which I would recommend to anyone interested in using the FreakZ stack. I found that the most efficient method is to have two devices that interface to the PC and use the same command line as the simulator. As I mentioned earlier, the high correlation between the hardware and sim means that you can write applications, test and debug them on the sim, and then move them over to hardware when things are working. Since each node has a command line, you can also control each node to simulate an event and see how the rest of the network behaves. Although I didn't know how useful it would be, that crappy, little simulator I wrote at the beginning of the project has turned into an excellent development tool. Unfortunately, I couldn't do anything really crazy with the Raven USB sticks because they're tiny and don't have any IO for interfacing to sensors or external circuits. Also, the Raven LCD boards which come with the Raven kit can't interface to a PC so a command line interface is out of the question. Basically, the Raven kit is a way to evaluate Atmel's MCU and radio, but isn't really meant to be a full hardware/software development platform. In the end, I finally just bought an extra Raven USB stick from DigiKey to set up my tests. They're available now for about $40. I'm going to be taking a short break from stack development to design development boards that address these issues. Mostly, I'm going to make boards with increased I/O, USB and serial interfaces, and separate boards for the MCU and radio. That way, they can have the command line interface, connect to external circuits, and the MCU/radio combinations can be mixed and matched. I'm excited about the last one because I want to try out some of the 868/915 MHz radios. I heard that they have a longer range for the same power than 2.4 GHz radios and they're less susceptible to physical barriers. It'll also be a good platform for me to do actual testing and reviews of radio performance from the different vendors. I'll have more details on the development boards later. In the meantime, here's some pics of my little demo I set up for everyone. The picture sequence shows the LED on the Raven USB sticks turned on via the Zigbee Home Automation Profile's On/Off cluster commands. The Zigbee frames can be verified by the trace from the Daintree analyzer. The last picture is just a shot of my test setup. I deliberately chose to turn on LEDs because I wanted to bask in the not-so-subtle irony of taking 16 months to toggle an LED...
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
Show/Hide comment form