Home
Dev Journal - Double Header | Print |
Blog - FreakZ
Written by Akiba   
Monday, 10 March 2008
With the buffer management system chosen and the frame buffer pool finished, the next job was to pass a frame up and down the stack. This meant that code needed to be written to process the headers.

There are three headers that need to be handled: the MAC, NWK, and APS headers. Going downstream, the headers needed to be built from the available information you pass into the function. Going upstream, the headers needed to be stripped off from the frame and processed so that they could be put into a structure for easy access.

Many of the people that work with TCP/IP stacks would laugh at putting the headers into a structure. That's because TCP and IP headers (and Ethernet headers for that matter) are fixed sizes. This means that you can just create a structure pointer (ie: a pointer to an IP header struct) and point it at the start of the header in the buffer. That way, you can process all the fields in the buffer instead of copying them into a separate struct. Hope I didn't lose anyone with that explanation. You can save space by doing in-buffer processing because you don't need to use RAM to hold actual header structures.

Read more...
 
Dev Journal - Deciding on the Buffer Management Strategy | Print |
Blog - FreakZ
Written by Akiba   
Sunday, 09 March 2008
After I got the dummy functions in the data path going, I needed to create the data structures that would be traveling through this path. The data structures consists of a frame buffer pool, and the request/indication parameter structures that conform to the Zigbee/802.15.4 specifications. Its at this point that you need to decide on the buffer management strategy. Yeah, I could just hear those yawns. I know buffer management strategy is not the most exciting thing in the world, but its important. Really! So here's a brief and probably incomplete discussion on buffer management...
Read more...
 
The Uselessness of Protocol Wars | Print |
Blog - Misc
Written by Akiba   
Saturday, 08 March 2008

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.

Protocol wars are basically stupid. They are part of the same genus as format wars. So as an overplayed example, lets take Blu-Ray vs HD-DVD. Toshiba was touting the benefits of HD-DVD and preaching to all that would listen that the world would be a better place if we adopted it as the standard. Sony was preaching the same message, except about Blu-Ray. They both were one-upping each other on specs:

HD-DVD - Backwards compatibility with DVD players

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.

Read more...
 
A Zigbee Protocol Stack - Where Do You Start? | Print |
Blog - FreakZ
Written by Akiba   
Thursday, 06 March 2008

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.

Read more...
 
New Blog Category - FreakZ - The FreakZ Project Development Diary | Print |
Blog - FreakZ
Written by Akiba   
Wednesday, 05 March 2008
I created a new category that will be used for the FreakZ development journal. Here, you'll see all my dirty thoughts while implementing the stack.
 
Introduction - FreakZ Open Source Zigbee Project - Part 2 | Print |
Blog - FreakZ
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…

Read more...
 
Introduction - FreakZ Open Source Zigbee Project - Part 1 | Print |
Blog - FreakZ
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.

 

 

Read more...
 
Contiki/Rime's Chameleon Code Committed and Available | Print |
Blog - News
Written by Akiba   
Monday, 03 March 2008

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.

Read more...
 
RSS | Print |
Blog - Misc
Written by Akiba   
Monday, 03 March 2008

I just got the RSS feed working for those of you that are interested. It should be on the right. Feel free to email me with any suggestions for improving the site.

Thanks! 

 
<< Start < Prev 41 42 43 44 Next > End >>

Results 370 - 378 of 391

Contact

Feel free to email me:

Contact