A recent comment on my blog (there's only two right now) kind of got me thinking about the purpose of protocol wars. The commenter was a 6LowPAN backer and was taking a lot of jabs at Zigbee. Anyone that knows me knows that I'm  not a diehard fan of anything. I never really subscribed to the whole "whose side are you on" type of thing, not even for presidential elections (go Obama). However I did point out some holes in his arguments.

Blu-Ray - Higher storage capacities

HD-DVD - Lower manufacturing cost

Blu-Ray - More DRM options

Yada yada...

However the consumer doesn't give a shit about the storage density of the disc or compatibility with DVD players. What they wanted was a disc that they can watch HD content on. Could Blu-Ray do it? Yes. Could HD-DVD do it? Yes. Does the consumer care if Blu-Ray or HD-DVD wins? I'm pretty sure the answer was no. The whole consumer market just wanted a decision made. That was it. However the whole time the format wars were going on, damage was being done to the entire industry. The consumer didn't know which player to buy or to even buy one at all. The studios couldn't decide if they should release HD content. The manufacturer's had to make expensive players that were compatible with both. And finally, how did Sony win the format war? Was it by having a better spec? No. They paid off Warner . There you go folks.

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.

Adam Dunkel's and the guys at SICS just committed the Chameleon code for Contiki's wireless sensor networking stack. Chameleon rides underneath Rime and is a header abstraction layer which can interface to different MAC/PHY protocols. For those of you that don't know Rime, its a refreshingly simple and small wireless sensor networking protocol stack . Anyone that's looked through the code can see that its thinly layered and easy to follow. The core of the stack does simple transmit and receive, but there are also source code modules for mesh routing, reliable transmission, broadcast, and more. The stack is part of the Contiki OS download along with the uIP stack.