| DevJournal - Getting Ready for Cooja | | Print | |
| Written by Akiba | |
| Sunday, 04 May 2008 | |
|
I haven't updated the blog on the status of the stack for a while. The week before last, things got really busy due to the start of the Golden Week holidays in Japan so I ended up working a lot. That ate into a lot of the time that I wanted to spend on implementation. Also, my wife got laid off from her job last week. Although it doesn't affect us too much financially, the fact that she's home all day is taking a toll on my implementation time. Since she has a lot of free time, she's taken to cleaning the apartment, and I mean thoroughly cleaning. I guess she needs to focus her energy somewhere, but she gets mad at me if she starts cleaning and I'm not on hand to help out. So I've been helping her clean the closets, her room, the floors, laundry, throwing things out, etc. My room only gets cleaned by me. The good news is that the apartment never looked better. The bad news is that it's cutting into my coding time about as much as working full time two weeks ago. Ahhh…the price of marriage. I did manage to sneak out a bit last week and hide in a local coffee shop. Now that the weather's better, I've changed my normal place that I do my coding. Before, it was at the local hamburger shop, where I can buy a cheap coffee and hang out on the second floor for a couple of hours. That’s important because a lot of places get mad at you if you stay too long with just a cheap drink. But now that the weather's improving, I've been going to a café about 15 minutes away by bicycle. It has a nice veranda with a view of the park across the street. You don't get to see too much greenery in Tokyo so it's a nice change of scenery for me. So although my pace has slowed a bit, the cleaning gave me ample time to think through some of the stack implementation. That helped make my coding more efficient when I had the chance to do some implementation. Right now, the progress on the stack is quite good. The implementation of the management functions went much more smoothly than my first attempt at it last year. I now realize the mistakes I made on that first attempt, and a lot of them had to do with the initial planning stage. The main reason things went smoothly this time is the choice of implementation strategy. Starting with the data path was a good move because it gave me an initial means of transport and also I was able to see the code flow moving up and down the stack. The management functions rely heavily on the transport, both direct and indirect, so since it was already available, coding them up went much faster. Also, my previous strategy was a bottom-up design where I implemented the driver first, followed by the MAC, and then moving up into the NWK layer. This was a mistake. In general, this approach is fine, however a Zigbee stack is unique in that its actually built on top of another protocol, 802.15.4. However I figure that it only uses about 30% of the functionality of the 802.15.4 specification. This is where I got tripped up in doing my bottom up approach. By going bottom up, I ended up implementing a lot of functionality that wasn't used by Zigbee, thus making things much more complicated than they should have been. Since Zigbee doesn't allow beacon mode, then that basically takes out a lot of the features of 802.15.4: superframes, timeslots, guaranteed time slots, contention access, timing control, etc. This time around, after the data path was implemented, I then started with the network management functions. This is at the top of the management hierarchy so my management implementation was a top-down strategy. By starting with the NWK layer, I was able to see the MAC functions that I needed and only had to implement them in a way that was usable by the NWK layer. This limits the usability of the MAC in other applications (ie: 6LoWPAN or wHART) but I'm not too concerned right now. The main goal is to have something that works, and that is as small as possible. I would recommend anybody that is setting out to write their own Zigbee stack to follow this approach, where you implement the data path first, and then do a top down implementation on the management services. So far, I have the following management functions completed:
These management functions are enough to start up a network and add devices to it. I also have tests written for most of the functions. Not bad for two weeks of limited implementation time. The tests have been saving my ass, too. As the number of tests is increasing, I'm getting more test failures, since modifications to one area sometimes affect some distant area. If the tests weren't self checking, then it would have been difficult to see these problems. I've even caught some issues that depended on the sequence the tests were run in. Those would have been ugly to debug in hardware. Anyways, if my simple tests are already catching a lot of bugs, then there must still be a whole cockroach nest in my code. By the way, regarding bug trackers, I'm leaning towards Trac for its integration with Subversion, but any suggestions on bug trackers would be welcome.
Email This
Hits: 692 Trackback(0)
Comments (0)
![]() Write comment
|
| < Prev | Next > |
|---|