Not sure what you mean... Another MCU than which one ?  If you want to connect the CC2420 to the MSP430 microcontroller, you can find the corresponding Z-stack www.ti.com/z-stack

Thanks, Emmanuel 

I think he wants to use the Z-stack on any uC which is connected to the CC2420 as the radio transceiver.

If it is the right question, I am also interrested to know if this community could support the move to another configuration than the ones currently supported officially by TI. I am specially interrested to port elegantly the Z-stack with the CC2431 as a co-processor with any other uC available (8051, arm, ...). The versatility of the stack is mandatory to its succes, I think specially facing a simpler SimpliciTI stack.

But, it is my personnal point of view/interrest.

JP

 Hi,

I agree with JP. Given the drop in cost of 32-bit chips it would be great to have the Z-stack running on some bigger and more powerful mcus.  At the moment you can use a CC2480 as a network coprocessor and plug any mcu you want to it if you need to. That makes it a 2-chip solution though.

 JP: The CC2431 is just a CC2430 with a location engine.  We are using the CC2430 for a full application running with the Z-stack but you can just write a simple interface to the CC2431 using one of the USARTs and connect any mcu to it on the other end. Just leave the Z-stack in the CC2431 no? I'm not 100% clear on what you meant so I may be way off. This basically makes it a custom version of the CC2480.

emmsys

Hi JP,

The Z-Stack for CC2420 is bundled with IAR EW430 + MSP430FG4618 as a solution. If you require support for another microcontroller it is a bit more challenging since TI provide Z-Stack NWK layer and MAC higher layer as libraries build for a specific release of IAR EW430 toolchain. To support your request will require Z-Stack source code to be build for your microcontroller combined with the compiler of choice of course. TI do not support this.

Which microcontroller is of interest?

LPWRocks  

 Maybe you can clarify what you are trying to do when usng "the CC2431 as a co-processor with any other uC available".  What you might be looking for is the Z-Accel solution or the CC2480, where you have the full ZigBee stack running as a black box or network processor with a simple UART or SPI interface.  Then you can select whatever micro you are comfortable with or have an existing application running on and just bolt up the CC2480 to add ZigBee connectivity.  This keeps things simple and allows flexibility when selecting your micro based on application requirements.  Please note though that the CC2480 does not support the hardware based location that the CC2431 provides so if you mentioned the CC2431 because you need the location solution then you would have to implement your own form of network processor for this specific device.   

You can also take a look at RC2300-ZNM ZigBee Network Module from Radiocrafts. It contains the ZigBee stack and supports a very easy to use API so that you can run your code in any uC with a UART / SPI interface. The module got all the RF circuitry including antenna integrated.

Hi again,

Yes, this is one option. 

Please feel free to investigate our extensive RF Developer Network also for other options. 

LPW RF Developer Network  

http://focus.ti.com/general/docs/staticcontent.tsp?contentId=29028

LPWRocks 

 What is the point of vieww of all of you ?

Hi JP,

You have some great points. Open source commnuities are great, such as the TinyOS coming out of Berkeley, http://www.tinyos.net/

In terms of ZigBee and open source communities I am only aware of one. They started out when ZigBee 2004 came to the market. This specification is of course now obsolete. I do not know the current status of this project. This community contacted us three years ago. See below:

From the OpenBee community that contact us back in 2005:

"We are two engineers working at the University of Applied Sciences Valais, Sion, Switzerland (http://www.hevs.ch).  We have begun the development of a ZigBee compatible stack under GNU/GPL license. The stack will be microprocessor, radio transceiver and operating system independant.

At the moment, we are working on the structure of the OpenBee Stack. For this, we use the UML tool Rhapsody from I-logix (http://www.ilogix.com), to speed up the design and shorten the implementation time. During this phase we will not check in any code into the sourceforge CVS repository, because the code is generated out of the UML description (C code is generated). The proposed structure of the code will be regularly posted on http://www.openbee.org and your comments are welcome (release 1.x already available in the member area). Once the architecture of the stack is defined, function declarations for the different parts (MAC, NWK, APS, AF, security, route discovery, etc.) will be available and the collaborative development can begin. If you announce your interest for a specific part, we'll provide you with the corresponding functions declarations.

Rhapsody design files will be made available both as UML graphs and as Rhapsody source file (Rhapsody licence required!). If you do not intent, or could not use rhapasody as development tool, we can take your source files and reverse engineer it into the Rhapsody project. This means you can work with your favorite IDE.

Don't hesitate to propose your ideas. To keep up with the latest news on OpenBee, just register on the OpenBee website www.openbee.org This will give you access to the member area of the site and will add your email address to the news mailing list. "

Hope this helps.

LPWRocks

 Hi all,

 Related with Zigbee, Open sources and TinyOS. There is another IEEE802.15.4 / Zigbee Stack written in nesC for TinyOS, it is called Open-ZB and is developed by a research group called IPP-Hurray.

If you want more information, its website is: http://www.open-zb.net/

You can get their stack in the download area. It is not complete, but it works.

Daimon

 Hi,

Lots of great information! I'm just playing devil's advocate now (and I don't work for TI!) but from TI's perspective, and given how new ZigBee is, they can provide better support if the Z-stack runs on a limited number of their own platforms. If they open up the Z-stack to everyone then it won't be possible to provide support. Also, these stacks are certified as ZigBee compliant platforms. If you move the Z-stack to other platforms than the whole package needs to be re-certified. Lots of interesting pros/cons for all of this!

Emmsys

 Hi,

That is right. Every new build for a specific platform will require compliance testing to obtain the status of a ZCP - ZigBee Compliant Platform.

 http://www.zigbee.org/en/certification/index.asp

LPWRocks 

Hi,

I agree with you in the main point, but as you can modify part of the ZDO or the OSAL, which are not really the Zigbee stack itself, why you can't modify the other files?. Of course TI won't have to provide support to modified stacks.

On the one side If the code is opened people can contribute with improvements or suggestions, which TI can add to Z-stack, or not.

On the other side who wants to modify the stack has to deal with the Zigbee compilance testing ( In adition, Everybody who wants the Zigbee logo for its product has to pass the Zigbee certification product program), but at least we can choose. 

 It depends on each one interests.

Daimon,

Your feedback is definitely something requested often, but unfortunately the situation is not as simple as opening up the code.  First, going through the product certificaiton process is different then the stack certification process, and while TI can currently make the statement that we provide our customers with a ZigBee compliant platform on which to build a product, we could no longer make this statement if we provided source code that a customer could potentially modify.  If even a single line of code is modified then technically the customer would need to re-certify this.  We realize this is not impossible, just something that is unlikely given that most customers want to focus there efforts on the application and not have to worry about the networking aspects of ZigBee (hence Z-Accel, but a completely separate topic).  Anyway that said, another issue is that as you probably know the ZigBee stack, most specifically the networking portion of it, is quite complex and there is significant resources in development and testing of this code to make it as bug free and performance enhanced as possible.  Opening up the code does offer the benefits of potentially allowing for customer improvement, but would likely result in customers going down paths that we simply don't have the bandwidth to support.  As mentioned by several others, there are ZigBee stacks out there in the open source community which are available.  However realizing the time and effort that has gone into fixing bugs and stress testing the system with 10's to even 100's of nodes, I caution most about building a product on one of these open source solutions without performing this extensive testing on their own.  Anyway great conversation nonetheless.  If opening up the source would make our customers more successful, I believe we would do this, but when taking the more global view of the ZigBee market and it seems that the best bet to help our customers be successful is to keep them focused on their application and hide the details of networking.   

 PME_BLUM,

 I agree in  the point that almost all TI's customers are just interested in adding a application over the Z-stack, therefore it's better not to open up the code. However as a different project, which can't be supported by TI and in this case the compilant certification is the customer's problem, the code can be open up. In that situation TI will have a compilant platform as now and in addition the advantatges of a open project.  For example, I'm developing a new product based on CC2430 and Z-stack, but I want to add an external RAM memory which my application will use without problem, but the Z-Stack ( I'm specially interested in the routing mecanism) won't be able to use it. I know that I won't have support and I will have to pass the stack certification process before the product certification one( maybe the product is not certified after all), but that improvement is very interesting for my application.

 I understand TI point of view, so I won't insist, but it's an intersting conversation.