Forums

Hi,

I'd like to recommend that you upgrade to z-stack 1.4.3-1.2.1 as soon as possible since there has been numerous bug fixes since 1.4.0.
Here's a code example that sets P0.2 high:

 P0SEL &= ~BV(2);  // set P0.2 as GPIO pin
 P0DIR |=  BV(2);  // set P0.2 as output
 P0    |=  BV(2);  // set output high

More information on I/O configuration (including use of peripherals can also be found in the 2430 datsheet)

Hope this helps.

Hello Z,

Thanks for the reply, and it will help me get into this. I found the elements you are using in this code in the 'Peripherals, I/O registers' section of the 2430 datasheet, and the defines in hal_defs.h. I also found a similar usage of this same code in Serialize.c. Is there anywhere that these type of code examples in the Z-Stack are grouped to be able to reference?

Also, regarding your suggestion to upgrade the Z-Stack version, I was told by TI that they are now up to Z-Stack 2.1.0, but unfortunately the Workshop literature is only up to Z-Stack 1.4.0. I am hesitant to move to a version that is not compatible with the labs which I can use to build on. What types of bugs are you referring to, and how severe do you feel the impact will be of working with 1.4.0? Thanks. 

Wireless1

Thanks for the reply, and it will help me get into this. I found the elements you are using in this code in the 'Peripherals, I/O registers' section of the 2430 datasheet, and the defines in hal_defs.h. I also found a similar usage of this same code in Serialize.c. Is there anywhere that these type of code examples in the Z-Stack are grouped to be able to reference?

I would assume these examples are in the .\Components\hal directory for accessing peripherals, GPIO, etc.

Wireless1

Also, regarding your suggestion to upgrade the Z-Stack version, I was told by TI that they are now up to Z-Stack 2.1.0, but unfortunately the Workshop literature is only up to Z-Stack 1.4.0. I am hesitant to move to a version that is not compatible with the labs which I can use to build on. What types of bugs are you referring to, and how severe do you feel the impact will be of working with 1.4.0?

If you are using the CC2430, which earlier in this thread you did mention, I would think you should stick to the v1.4.x line of Z-Stack software.  It seems this is based on the CC2430 family.  The v2.1.x appears to be geared for the CC2520+MSP430 architecture.
The v1.4.3 Z-Stack software deliverable does have a document that discusses upgrading from the v1.4.2 to v1.4.3.  I don't believe it discusses v1.4.0 to v1.4.3 however.

@ Wireless1:

The best place to look for peripheral access code examples would be in the hal drivers. In the z-stack 1.4.3 release there is a document called "Z-stack HAL porting guide" that talks about the related files.
1.4.0 is a few evolutions behind. We've made improvements in the low level MAC and at the network layer (routing, etc). There have also been code size reduction benefits due to the move to the 7.30B IAR compiler. You'd be able to run the labs on 1.4.3, but you'd have to move your files over to the new codebase. We also redesigned the ZDO callback interface to the application from 1.4.2 to 1.4.3, so how the application handles this is going to be different.

@ BrandonAzbell:

You're correct on all accounts. We've had porting guides in the different stack releases, basically going from 1.4.0->1.4.1, 1.4.1->1.4.2, 1.4.2->1.4.3. It's simpler really to just start with a 1.4.3 sample app codebase like GenericApp.

Actually I've just uploaded some porting documents since 1.4.0 to my files section if anyone is interested.

Hi Z,

I looked at the Z-Stack HAL Porting Guide that you mentioned, and it will be very helpful. It looks like it will apply to Z-Stack 1.4.0 as well. You menitoned that you uploaded porting documents to your files section, but I don't know how to access that, so please let me know.

I have another question: I am going to be running a ZigBee network with as many as 40 of our custom boards, each of which will have a CC2430 on it. In Lab6A, page 6-15, there are several #defines. I would like to know whether I need to set any or all of these #defines in the actual system. Do I have to set anything else beside the PAN ID in f8wConfig.cfg, as described on page 6-16? Also in this lab, it says to note the ID number of each EB and DB. I want to know where that is used? Looking at the source code, I see in Lab6.h, a #define for LAB6_DEVICEID, and maybe that is where it should be used.

Thank you.

Hi Wireless1,

you can access the files from "Z" over his/her profile (https://community.ti.com/members/611578/default.aspx) in the section "My files"

Cheers. Flo

If anyone can respond to the second question in my posting of of 10/22, I would apperciate it. I'll copy what I wrote:

I have another question: I am going to be running a ZigBee network with as many as 40 of our custom boards, each of which will have a CC2430 on it. In Lab6A (of the TI ZigBee Workshop Student Guide), page 6-15, there are several #defines. I would like to know whether I need to set any or all of these #defines in the actual system. Do I have to set anything else beside the PAN ID in f8wConfig.cfg, as described on page 6-16? Also in this lab, it says to note the ID number of each EB and DB. I want to know where that is used? Looking at the source code, I see in Lab6.h, a #define for LAB6_DEVICEID, and maybe that is where it should be used.

Thank you to anyone who can respond to this.

 

 

These defines are used to populate a Descriptor table which is ultimately used by the Application Framework (AF) interface layer in the ZigBee stack.  Refering to the Z-Stack API F8W 2006-0021.pdf documentation (in the Z-Stack v1.4.3 software tree), Section 3.2 indicates this structure is used to define the Simple Descriptor which each endpoint must have a ZigBee Simple Descriptor.  The descriptor describes the endpoint to the rest of the ZigBee network.  Another device can query another endpoint for its simple descriptor and determine what kind of device it is.

Some of the parameters which are #define variables in the Lab6 are to be obtained from the ZigBee Alliance.

So yes, I would say these are needed in an actual system.

Brandon,

Thank you for the response.

I see in the Z-Stack API F8W 2006-0021.pdf that AppProfId and AppDeviceId are to be obtained from the ZigBee Alliance, but in the labs and samples, a value of 0x0F04 is used for AppProfId, and 0x0001 for AppDeviceId. Can I use these values in my system, and if not, how to I obtain the right values to use?

Also, in Lab6, part C, it shows how to bind the Coorinator to the other devices manually. Is there a way that all devices can be bound to each other automatically with no user action?

Thank you.

Wireless1

I see in the Z-Stack API F8W 2006-0021.pdf that AppProfId and AppDeviceId are to be obtained from the ZigBee Alliance, but in the labs and samples, a value of 0x0F04 is used for AppProfId, and 0x0001 for AppDeviceId. Can I use these values in my system, and if not, how to I obtain the right values to use?

I really don't have any information about the values used in the lab regarding if they are valid ZigBee Alliance profile/device id values or just numbers used for demonstration purposes.
Regardless, I believe you will need to get appropriate values from the ZigBee Alliance directly.  See link below.
http://www.zigbee.org/en/join/membership_requirements.asp

Wireless1

Also, in Lab6, part C, it shows how to bind the Coorinator to the other devices manually. Is there a way that all devices can be bound to each other automatically with no user action?

Yes, the Student Guide for the Workshop provides an illustration of automatic binding.

The boards numbers on the EB and DB development boards are hard-coded indentifiers in the USB interface. Thay have nothing to do with the ZigBee stack.

There are no HAL defined GPIO APIs. Modifying the LED APIs is the shortest path to get them.

The profile ID, cluster ID, etc used in the workshop labs were picked out of thin air. They are not "real" ZigBee Alliance assigned numbers ... they are for development purposes only. In order to obtain "real" manufacturer specific profile ID numbers, you will have to join the ZigBee Alliance and apply for them. So yes, you can use them for developing your project, but I would certainly not use them in a real product. There would be no guarentee that someone else would also be incorrectly using that profile ID ...

Yes, you can certainly use something like automatic binding to bind two devices together with no user intervention at all. Once bound though, you might want to think about the use of NV_RESTORE. That will store the binding table in non-volatile memory so that the devices can simply restore their previous binding rather than re-bind at every power up.

 

Scott

Scott (or anyone),

Thank you for the answers to my previous questions.

I still have a question regarding automatic binding. Although Lab 6C in the Workshop has an example of this using ZDApp_AutoFindDestination(), it only binds the routers and end devices automatically. Is there a way to also use ZDApp_AutoFindDestination() to automatically bind the coordinator to the network so that it can also send data to other devices, without having to manually bind it? If not, is there another way to do it, so that any device can send data to any other device, without manual binding?

Thank you.

It is my understanding that a coordinator is a router, but has the unique characteristic of starting the network, among I'm sure a couple of other things.
Therefore, I don't see why an automatic bind can not happen with the coordinator.

Does anyone know whether what Brandon says is correct? If so, after the Coordinator is powered up, followed by all the other devices in any order (assume they are all routers, and some require multiple hops to reach the coordinator), that the network will be formed and binding occur, so that messages can be sent from any device to any other device?