|Introduction - FreakZ Open Source Zigbee Project - Part 2||| Print ||
|Written by Akiba|
|Wednesday, 05 March 2008|
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…
So I was depressed and weighing my options. On the one hand, I could just implement a simple event-based framework (event queue, scheduler, soft timers, tick handling, messages) or I could use a full-blown OS. The real kicker is that once you choose to use an OS, debugging becomes a real pain. You can’t simulate the hardware on a friendly PC where you have access to its heavenly debugging resources (stack traces, infinite breakpoints, and it runs fast). Debugging on a non-native target usually means that you have to work in the metal (on the actual hardware) which is slowww. When you’re writing code and debugging on the actual hardware, then you’re adding another dimension to things that can go wrong (hardware issues), as well as having limited and (usually) slow debugging resources.
So as I was perusing the potential candidates for the OSes that I would consider, I ran into TinyOS and Contiki. TinyOS is a one of the most popular platforms for wireless sensor networking and is heavily used in academic research on WSNs. The only problem was that it uses its own version of C (NesC ) and I didn’t want to have a multi-language stack. Heck, I’ve been in Japan for six years, and I’m still struggling with Japanese. Also, using a language other than C might scare off the people that I was writing the stack for (hobbyists with a basic understanding of C, ie: Make Magazine readers).
So I started to study the Contiki OS which was written by Adam Dunkels and the guys at SICS. I was very impressed as I learned more about it. Contiki OS is not exactly an OS as mentioned above. It uses a “weird” trick that takes advantage of a property of ANSI C compilers and preprocessors to implement “threads”. Actually, they’re not exactly threads. They were dubbed “protothreads” and they require almost no memory; just two bytes of RAM to store a line number. On top of that, since it doesn’t require its own block of memory, its able to run as a process/thread in other OSes which would make porting to different OSes trivial (hopefully). I actually confirmed this because I’m once again happily developing on my PC. On top of that, Contiki also has a TCP/IP stack available (great for a Zigbee gateway), over the air downloads, uses C, and best of all, its event-based. Perfect!
Needless to say, I’m using Contiki to implement the framework of the FreakZ stack. This time around, I’ve also decided to document a lot of my research on Zigbee as well as my development inside this blog. I had such a hard time finding resources on actual protocol stack implementation on my first attempt that I wanted to show other developers the decisions and tradeoffs that occur in stack implementation as well as the reasons (at least my reasons) for making them. As well as documenting my progress, I’ll also be documenting my mistakes so please take it easy on me ;)
p.s. For anyone that doesn’t like the name FreakZ, you should be thankful. The original name was BitchZ.
|< Prev||Next >|