Factors to consider when selecting a Zigbee controller for your designThe Zigbee networking standard has slowly but surely taken up an important share of the wireless market. Vendors of Zigbee products are increasing, and more and more types are coming out. With the increasingly fiercer competition, the number of providers paying attention to Zigbee's declared features - low cost and low power consumption - has grown, hence the increasing popularity of the single-chip solution.
Users have opened up to the single-chip solution for its potential to dramatically reduce the cost, shorten the development cycle and accelerate time-to-market, thus taking a positive role in the promotion and application of Zigbee. However, some limitations have cropped up as a result of this diversification.
|Figure 1. The performance of the controller that manages the Zigbee network coordinator must be higher than that for other network devices.|
Introducing the 'brain'
As shown in Figure 1 above, a Zigbee network has three device types: the coordinator, the router and the end device. The coordinator is the so-called "brain" or center of the entire network, responsible for functions such as setting up, maintaining and managing the network, and allocating network addresses.
Because it undertakes many tasks, the performance of the "brain" manager must be higher than that for other network devices. For simple networks or applications, the same controller can be used for the three device types.
However, the burden on the network coordinator becomes heavier as networks expand and applications grow more complex, gradually surpassing the capability of the single chip. In the same token, Zigbee end devices and routers need controllers with lower cost and power consumption due to their relatively simpler functions.
|Figure 2. Several factors must be considered when selecting a controller.|
Evaluating Zigbee controllers
Various controllers offer Zigbee users a lot of alternatives, making it difficult to select the appropriate product. One's choice must be considered seriously because the controller picked for the Zigbee network coordinator is related to the development of the entire project.
As shown in Figure 2, above, the following factors should be considered -
Performance. For the normal operation and management of a Zigbee network coordinator, a high-performance controller with more powerful computing and processing capabilities must be employed. Here, high performance is relative to the end device or router in the Zigbee network.
A 32bit MCU can be selected, as well as the 8bit and 16bit MCUs used before. Although the performance and main frequency speed of 8bit and 16bit MCUs are increasing continuously, the inherent bus width still limits their computing and processing capabilities.
For instance, the network address allocation, routing table maintenance and management in a Zigbee network all need large amounts of computation.
The 32bit MCU undoubtedly has the advantage in this regard. Moreover, the 32bit MCU also has greater advantage when implementing a connection between a Zigbee network and another network.
While the higher processing capability would surely lead to an increase in power consumption and cost, the network coordinator, which usually uses the main power supply instead of the battery, needs minimal energy requirements. In terms of cost, the price of the 32bit MCU has gradually dropped, and some low-end 32bit MCUs are even cheaper than many 16bit MCUs.
Considering performance above cost and power needs when selecting a controller for the network coordinator device is, in the end, the most economical route because Zigbee end devices and routers, which make up the main equipment for the entire Zigbee network, are mostly low-priced products.
On-chip resources. For a controller's on-chip resource, first consider whether its peripheral modules meet the basic application requirements. For instance, there should be enough interface available for the wireless transceivers to connect to.
Also account for whether there are enough modules for the development of different applications. This is not to say the more the better, but rather the closer to the needs the better. Too many peripheral modules unused will not only mean more expenses but also an increase in power consumption.
Another factor that should be considered is embedded memory space. Because the Zigbee coordinator is the central node of the network, the protocol stack software for the "brain" takes up much space. The existing typical stack usually takes up over 40Kbytes flash memory and 2Kbytes RAM.
If the embedded flash memory and RAM are low, the space left for user applications becomes too small, forcing users to shorten and optimize their codes with the greatest effort. For those applications with many application codes or need flash to store user data, users have to give up once memory becomes insufficient.
Therefore, a network coordinator should use a controller with a large embedded memory to leave enough room for users to write application programs. Keeping the margin of memory space at a certain level is also helpful for product maintenance and upgrade.
Development tools. Although a network coordinator uses different controllers from those used by other network devices, its development tool should be consistent with that for other devices. If different development tools are used, suffering various losses is inevitable. First, the development cost will increase - more money will be spent if more than one type of development tool is used, and more engineers would possibly be needed to operate each tool.
Secondly, the workload will increase - engineers will take much time and energy to learn and use the different products and development tools. Finally, the development cycle will lengthen, and the speed of time-to-market and promotion will slow.
Compatibility and upgradeability. During product development, future maintenance and upgrade should be considered given today's fast-changing society and as product life cycles become shorter.
Therefore, the developer must reflect on compatibility and upgradeability issues when selecting controllers to avoid added costs. Generally, one chooses a midrange controller in the initial phase of development.
Once the development is finished, the controller may be replaced after the practical proof. If performance of the controller used now has much margin, lower-end products can be chosen.
As time passes, an upgradeable controller may be used to, for example, connect the Zigbee network with an Ethernet network. In a word, the controller selected for one's network coordinator should be flexible enough to provide compatibility with low-end products while having the capability to upgrade to highend applications as well.
Providers. One last point that could be easily overlooked is the providers that should be considered when selecting controllers.
Providers that have proven product systems and stable offering capability would be perfect for the job. Generally, these kinds of providers have a complete and mature set of controllers, excellent teams for technical support, competitive product prices and stable product offerings - factors that are very important to users.
Using a proven product provider helps raise the quality of a user's product and shorten its testing period. Selecting the better provider will get twice the result with half the effort.
A complete offering of various controllers provides opportunity to select products close to a user's needs and facilitate compatibility and upgradeability. An excellent technical support team helps users troubleshoot and speed up development. Competitive price and continuously stable offering capability can guarantee that the production and user's product can be continued even after several years.
The five factors discussed are some points that engineers should consider when choosing a controller for their Zigbee network coordinator. Because they are related to one another, a complete and thorough study should be performed and each factor weighed during the selection stage to get optimal results.
Patrick Yang is an Applications Engineer at Freescale Semiconductor