I'm going to kick off the FreakZ development journal by going back in time a bit. I started working on the stack with the Contiki OS for about a month now, in my spare time. One of the things that I always struggle with on a project is where to start. The problem with creating anything is that you start with nothing. You literally have to pull the design out of thin air.

On the Zigbee stack, this will be somewhat of a rewrite since I already had the driver, PHY, MAC, and part of the NWK layer going on my previous attempt. This gives me a partial head start. The standard way to start a design is usually by using one of the three methods: 

• Top Down Design
• Bottom Up Design
• A mixture of Top Down and Bottom Up Design

My first attempt was basically a bottom up design. I started with the framework, followed by the driver, PHY, MAC, and NWK, roughly in that order. I found that, at least for this project, I started to get into the whole forest from the trees thing. I was spending a lot of time tweaking the MAC layer and driver to get the startup, association, management and data going, but I felt like I was losing sight of the upper layers.

Continuing from Part 1…

At that point, I was pretty dejected thinking about all of the work that had to be done to define, debug, and tweak a new framework. One thing that I didn’t realize going into this was that it would require a lot of services that are provided by an operating system. That’s true in most cases of protocol stack design, which makes running any stack other than a trivial one on a microcontroller with no OS a challenge.

As an aside, the problem with using an operating system (say FreeRTOS) to implement a protocol stack is that you wouldn’t be able to run it on another operating system (say Linux) without significant porting effort. That’s because an OS requires memory to push the current context into when it performs a context switch. What that means is that you basically save all the CPU registers (program counter, etc…) and the stack variables on to memory allocated to that thread (old context), and load the contents of the next thread (new context) into the CPU.

The problem occurs when you try to run the stack under a different OS, like say Linux. You can’t run it natively since your stack has a threading structure and Linux has its own threading structure and mixing the two means almost certain death, if not some really nasty timing and memory conflicts. So normally, you would need to port the code on to the new OS in order to run it. That’s why many stacks come with an OS Abstraction Layer (OSAL) so that they can make it somewhat easier to port between OSes. However you still need to be familiar with the OS and its behavior to get it to run properly.

Okay, back to my story…

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.