ZigBee Code Space

I have heard continuing discussion about code size and its growth over time in the ZigBee stack. As a stack provider, Ember has tracked code size over time since our conversion from a proprietary network stack to the ZigBee stack. Our initial stack was ZigBee 2004, then ZigBee 2006 and then ZigBee PRO. I thought I would share some of this data from the past 3 years.

First, one cautionary note on using this data for the comparison of stack sizes between different suppliers or even different technologies. This is a difficult task because data is reported in different methods and it is often not broken down in enough detail to ensure a valid comparison is being done. Our examples below report on application stack sizes because these are fully functional applications including all underlying layers required including serial and OTA bootloaders, non-volatile storage so stack and application data can persist, device drivers, etc. This is not a “minimum possible size” benchmark, this is a real, fully deployable customer application.. Similarly for more complex applications such as Smart Energy, the application security requirements have a substantial impact on overall code size but are not a part of stack functionality.

When we do break down the stack for discussion, we use the following components. Note these sizes are more approximate based on a sampling of actual application sizes. The notes indicate the amount of flexibility and application has to use or not use a particular component.

Below we show a tracking of our sensor-sink reference application over roughly 3 years. This application encompasses everything necessary to send sensor data at regular intervals into a central collection point (the sink). This application does not use application level security so it does not reflect the growth in application space for use of link keys or public key encryption. However, as the graph shows, this application had only grown slightly in the two years from EmberZNet 1.0 to EmberZNet 3.1. In the EmberZNet 3.3 release the code size decreased substantially due to the new compiler release.

While it may appear the stack size has not changed much, in reality we have been adding ZigBee features but at the same time constantly been shrinking code and improving the tools and compiler to maintain the customer code space as much as possible. These efforts were given a large boost with the recent compiler release resulting in substantial code size decreases in the stack and application. The good news is there are further compiler improvements coming in early 2009.

So when people ask me about the growth in ZigBee code space over time, I can’t agree there is a big problem. Our benchmarking shows that feature growth does not always mean code space growth. In a future post we will discuss the growth of the Smart Energy Application and how well it fits.