It was a busy week last week. Japan's Golden Week holidays start this week which is a week-long vacation. That means that last week, everyone was scrambling to get things done so they wouldn't get delayed or have to come in during the holidays. My two-day work week turned into a full week of work, which sucks because I only get paid for two days. They said that I can get compensation days this week, but this whole week is a vacation. I've been tricked! 

Anyways, I did get a chance to sneak away and go to the Tokyo Sensor show so I thought I would post the pictures from it. I spared everyone the pictures of pressure, light, and other types of sensors since they aren't too exciting. In fact, there wasn't a whole lot exciting at the show from the companies. All the really cool stuff came from the university research projects. That just goes to show me the difference between corporate and non-corporate creativity. I'll take a cool university research project over a powerpoint product roadmap any day. That reminds me...I need to make the software roadmap for this project. Ha ha ha.

Here's the pictures...   


View the embedded image gallery online at:

Man. Somebody actually put up an old performance of me and one of the guys from my crew . It was one of the last performances we did together. I was the guy in the bandana and he's the one with the dreadlocks. We got called to do the charity performance and brought in another group of female lockers we knew to perform with us. It was a rush job, where we got called at the last minute so only had about three rehearsals to get everything together including our own routine. My friend ended up getting a record contract in Taiwan later that year and eventually became part of the group called Machi. I was already working at the time, but did performances here and there. About a year after he left for Taiwan, I ended up quitting dancing altogether and moved to Japan.

For people that buy their own parts and build their own boards, you normally do price searches on digi-key which is dramatically overpriced. I've forgiven them for this because they're convenient and they cater to individuals/hobbyists so I figure their handling costs are higher. But lately, I've been liking the chip price search engines and thought I'd share two of them that I use a lot:

Findchips - Findchips does a search over many distributors (mostly US based) including the big ones for the hobbyists (Digi-Key, Jameco, Mouser...). They have a decent interface and show which distributors have the part you're looking for as well as the price. 

Octopart - I just found this one recently. It has a search engine and also a category tree that you can use to look for stuff that you might not know to search for.  It's still quite a new site and many of the categories are empty (similar to my site?). Also, Digi-Key is currently suing them to take their prices off of the site, although I don't know why they'd turn down extra traffic and sales. It's a good site though and when you do searches, they even search the semiconductor manufacturers for the price listings. You can test this out by doing a search for CC2420. Note: Manufacturers should help them build up their product category trees by listing their own products. It couldn't hurt sales and might even improve it. 

Anyways, I just thought I would share those with everyone because they're quite useful. 

An interesting question was asked in the forums which, although reworded,  goes something like this:
"Why do the Zigbee SOC offerings have very little resources?"

This is actually an interesting question and to answer it requires a bit of a background on IC design.

Semiconductor hardware is all about cost, at least it is these days. The times are long gone when semiconductors was a glam industry. Consumer devices and PC products are all pushing down costs like crazy and the manufacturers are constantly pressuring the semiconductor suppliers to reduce their price. This is especially rampant in the standard products market, which includes the likes of ethernet, 802.11, and (if it takes off) 802.15.4 chips since they are all based on open standards.

I feel pretty good today. It feels like I was able to accomplish a lot of things on the stack for a change. Sometimes I feel pretty lethargic when I code. It's like working out; hard to start, but once you get going,  it's easy to lose yourself in it.

One of my major accomplishments was rewriting a lot of functions to remove some useless code. In the 802.15.4 and Zigbee specs, they use a large configuration structure called the Information Base (MAC Information Base (MIB) and Network Information Base (NIB)). They also specify how to access it, which is using set and get functions. The problem is that the structures are quite large and contain varied data types so the code to set and get all of the struct members is quite big.

I was thinking today if it was really worth the code space to have set/get functions instead of just accessing the structures via a pointer. That was when I decided to check the code size of the object files. The total was 3k of flash for the set/get functions. Holy Scheiser!

I sharpened my axe and started slashing left and right. Basically, I removed all of the code in the set/get's and even deleted the files. Then I just wrote a simple one-line function that would return a pointer to each of the structures. I had to do a lot code surgery in other areas since I had the set/gets sprinkled all over the place. But in the end, in return for accessing the structure via a pointer, I got an extra 3kB of code savings. Don't laugh...that's 10% of a 32 kB flash MCU! Wow...I guess I am a geek. Anyways,  accessing the structures directly is a bit unsafe if you're not careful, but I don't think set/get's add much more safety either.

In other unexciting coding news,  I put the finishing touches on the network discovery and mac scan functions and wrote a self-checking test to make sure it worked. After debugging a couple of bone-headed mistakes, I was able to get it to pass the simple test I wrote, as well as the regression where I run all the previous tests. That felt pretty good. 

So off I go on to the network join functions. This one will take a while because there is a client side and server side to the join procedure and both of them are pretty involved. I'm also gonna be a bit busy this week since the part-time job is going to take up at least two days due to unforeseen busy-ness, and I'm spending one day to go to the Sensor show at the convention center in Tokyo. Hopefully, I can take some cool pictures and show everyone some of the new sensors that are coming out over here. 

That's about it for today. TTFN. 

Now that the data path is basically working, I've moved on to the network management functions. Network management services consists of starting, joining, and leaving a network, neighbor discovery, addressing, and transceiver control. There are also a couple of other side functions too, but that's basically it. Many of these functions rely on data transmission which is why I wanted to tackle the data path first. With the data services functional, then implementation of the management services will be much easier.

Management Service Overview
The network management services are actually top level management functions that rely on the MAC management services. The MAC management services are channel scanning, association (joining), disassociation (leaving), polling, and some other side functions.

There was an inquiry awhile back on why I didn't open up the design implementation on this project. My answer was a bit generic, in that I said that coordination would be a bitch, or at least something to that effect. Let me elaborate on that statement.

The Zigbee protocol stack has many functions that are hopelessly intertwined with each other. I'll highlight one case as an example and explain why it would be difficult to coordinate multiple developers on its implementation.