|Introduction - FreakZ Open Source Zigbee Project - Part 1||| Print ||
|Written by Akiba|
|Tuesday, 04 March 2008|
I’ve been talking about it for a while now so I guess I should provide more details on the open source Zigbee stack that I've been working on. Before I start, perhaps I should provide some background info about me, the project, and my struggles wrestling with the Zigbee spec.
I had actually been involved with Zigbee since 2003 when the 802.15.4 MAC spec was first introduced and the Zigbee Alliance was trying to get the Zigbee spec out. I was helping a friend who had started a company based on the Zigbee and MAC standards. He had actually written a hardware 802.15.4 MAC (one of the first that I knew about) and had it prototyped in an FPGA. He also wrote the MAC software that went with it. At the time, we were able to get a copy of the MAC spec since he was on the IEEE committee (an IEEE fellow nonetheless), however we were unable to get the Zigbee spec because it was only in draft form and apparently, only available to the people working on it. In order to be a Zigbee contributor, you had to pay some big bucks. We spent a lot of time asking around for bootleg copies, however no one would hook us up. Time passed and I started getting busy with my day job. Zigbee kind of faded into the background for me, and I decided to focus on my job and try to help build the Japan office for the company that I was working for.
So when I stumbled upon the Zigbee site again in 2007, I was surprised that they had made the spec publicly available. I immediately downloaded it and took a quick look at it. It was difficult to understand since the spec kind of jumps around everywhere, and I decided to shelf it since I didn't have the time to go through it thoroughly. I was wondering why I had to implement so many things if all I wanted to do was flip a switch to remotely turn on a light.
The fateful day occurred sometime around March of last year when my boss/co-worker was complaining that I never stuck to one thing. I kept on changing hobbies and talking about different technologies that I was interested in. He challenged me to pick one thing and see if I can stick to it for more than three months.
Of course, how could I say no to a challenge. I decided to choose Zigbee as the technology that I would spend > 3 months on. With that in mind, I started to work on and off, basically spending a couple of hours on the weekends and some nights to go through the spec and try and understand it. I should say right now that I am still, by no means, an expert on the spec, but I do have a working knowledge of it. Of course who can work on Zigbee without studying the IEEE 802.15.4 spec. I was also relieved to see that this was publicly available, since my friend was no longer around to give me access to the IEEE specs.
After achieving a certain level of proficiency with Zigbee and 802.15.4, I decided that I would attempt to write a stack for it. I've never tried to write a full stack before, so I thought it would be an interesting thing to do. Well, that first attempt failed miserably. I basically implemented it using a bunch of state machines for each layer and polling each state machine in the top layer. Communication between layers was done using messages which conveyed the service requests, confirmations, and indications.
It started out nice enough, but in the end, it was a fat monster. I think I gave up on that method after implementing the framework (message queues, timers, buffer pools, etc), PHY, MAC, and the NWK management layers as it was becoming uncontrollable. I could just picture the buggy mess it would be to try and synchronize all of those state machines, especially since it would just take one unforeseen event to throw a state machine off and that would mess up the rest of the stack.
By this time, I had already won the bet and it was over three months since I had started. I think probably closer to six months, working on and off outside of the day job. I was a bit disheartened, but I could tell that I was moving in the wrong direction. The mistake came about in the initial choice of framework that I implemented. I think this is one of the most important decisions you can make when implementing a stack.
The problem is that polled state machines don't match the actual behavior of a communications stack. A communications protocol is event based. This means that your behavior will change based on the event that occurred. Normally, the external events are:
On my next attempt, I was contemplating the best type of framework for the stack, now that I had a better understanding of its behavior. I was thinking to get rid of the messages, redo my timer structure, add a scheduler, and create an event queue. It was going to be a lot of work, but it would be a much cleaner solution than the one I previously had.
Then I came across the Contiki OS, which was developed by Adam Dunkels and his compatriates at the SICS...
Coming up in Part 2 - Contiki and the birth of the FreakZ project
|< Prev||Next >|