[Akiba] I spent the weekend checking out the Freescale MC13224 datasheet and writing the review. There are a lot of features so this is going to be a long post. For my sake, I've divided it up into sections. So grab a cup of coffee and sit back 'cuz this is gonna take some time...[/Akiba]

Freescale recently announced its MC13224 Platform in Package chip. Aside from the attempt at creating a new semiconductor marketing buzzword, it's a highly integrated chip that is almost an entire 802.15.4/Zigbee module on one chip. This is Freescale's 3rd generation 802.15.4 radio and it is definitely head and shoulders above its previous 802.15.4 SoC, the MC1321x series. The chip comes in a 9.5 x 9.5 mm, 99-pin LGA package and supports a temperature range of -40 to 105 degrees Celsius, otherwise known as industrial temp.

MCU
Just as a reference, the MC1321x series was based on the HCS08 line of 8-bit micros and feature tiny amounts of RAM and flash. The largest of the series, MC13213, had 60 kB of flash and 4 kB of RAM. In terms of Zigbee, you could probably fit the stack inside it, but you wouldn't have much room for anything else. Also, with 4 kB of RAM, it'd be extremely difficult to use that chip as a router. Since a router (ideally) requires a frame buffer pool, routing table, neighbor table, discovery table, indirect transmission queue, address table, binding table, group table, and discovery cache (did I miss anything?), it'd be amazing if you could fit all of that in 4 kB of code and still have room for a decent application.

The resource issue has been addressed in the MC13224. It features an ARM7 TDMI 32-bit processor, one of the first of the SoCs to use an ARM7 in fact. If you don't know about ARM7's, you've probably been hiding underneath a rock for the past 10 years. It's an extremely energy efficient 32-bit microprocessor and there's a wealth of tools available for development on it. There is an open source JTAG tool called OpenOCD which interfaces to the GNU Debugger (GDB) and also includes schematics for building your own JTAG hardware probe. The ARM-GCC compiler is actively maintained and has been stable and well optimized for a long time for the ARM7s. Also, there are a lot of OSes that are ported to it such as uCLinux, uCOS-II (RTOS), eCOS (RTOS), and FreeRTOS (RTOS). And that's just some of the open source OSes!

Also for those that believe that 8-bit micros are easier to use than 32-bit ones, I'd beg to differ. If you've ever programmed an 8051 using Keil, you'd know that you have to use a lot of non-ANSI compiler specific extensions due to limitations of the microcontroller. On the other hand, you can program an ARM7 in (almost) 100% ANSI C and have it portable to an AVR, MIPS, x86, or any other chip that supports an ANSI compiler.

Okay…enough with the microcontroller architecture preaching…let's get back to business...

Just thought I would give everyone a quick heads up that Atmel released their RZRAVEN Zigbee Dev Board firmware a few weeks ago. I just found out about it now when I was browsing around their website. The source code looks like it's completely open, but the license agreement limits the usage of the software to Atmel products only, basically the same as Microchip and TI. The firmware contains some interesting applications such as a packet sniffer application that allows you to inject frames and also jam the signals. You need to register to download the firmware. Here's the link.

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...   

 

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.

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.