tmp = 0x20; #endif
// Initialize with a simple pattern----------------简单初始化扩展地址 xad = (uint8*)&aExtendedAddress; for ( i = 0; i < Z_EXTADDR_LEN; i++ ) *xad++ = tmp++;
// Flash LED1 until user hits SW5 ---------闪烁LED1直到SW5按下 led = HAL_LED_MODE_OFF;
while ( HAL_KEY_SW_5 != HalKeyRead() )---------------------SW5循环检测 {
MicroWait( 62500 );
HalLedSet( HAL_LED_1, led^=HAL_LED_MODE_ON ); // Toggle the LED MicroWait( 62500 ); }
HalLedSet( HAL_LED_1, HAL_LED_MODE_OFF ); // Plug AtoD data into lower bytes
AtoD = HalAdcRead (HAL_ADC_CHANNEL_7, HAL_ADC_RESOLUTION_10); xad = (uint8*)&aExtendedAddress; *xad++ = LO_UINT16( AtoD ); *xad = HI_UINT16( AtoD );
#if !defined( ZTOOL_PORT ) || defined( ZPORT ) || defined( NV_RESTORE ) // If no support for Z-Tool serial I/O,
// Write temporary 64-bit address to NV些临时的64位物理地址进入NV osal_nv_write( ZCD_NV_EXTADDR, 0, Z_EXTADDR_LEN, &aExtendedAddress ); #endif }
从程序中可以看出，一开始就检测FLASH中的物理地址，因为这个地址在FLASH中是固定的存储空间，一旦为有效地址就退出函数，一旦为无效地址（0xFFFFFFFFFFFFFFFF）,那么就对其物理地址进行简单的初始化并检测SW5按键。还是比较好理解的！ 3、运行例子
在这里提到了跳线，由于本人采用的非TI原装硬件，没有该跳线，所以必须对程序进行修改，否则检测不到跳线，连ZIGBEE的设备类型都不能确定，肯定不能正常运行了。所以这里就先暂时不说了，这里要说的是一切都正常的情况下，例子的验尸结果。小小跳跃一下。不然学习一直没有进展很麻烦的！
协调器：上电运行，地址检测如上面介绍的情况，通过之后呢-------就进行通道扫描，此时LED1闪烁，一旦协调器成功建立网络，此时LED1停止闪烁，而LED3被点亮。 路由器：上电运行，仍然是地址检测在前。之后就是通道扫描寻求是否又存在的网络，此时LED1闪烁，一旦检测到存在网络并成功加入该网络，LED1将停止闪烁，被替换的是LED3
别点亮，也就表明路由器成功加入了网络。
那么此时能进行的操作控制是什么呢，也是最简单的表现手法---按键无线控制LED： ? 周期（5S）发送信息到网络中每个设备 ? SW1按下，发送一个信息到组1的设备 ? SW2按下，退出/加入组1 这个我是经过验证的。如：
? 按下协调器SW1，路由器的LED1狂闪几下；按下路由器的SW1，那么协调器的LED1也就狂闪几下；当然我是只有两个节点。
? 如果按1下协调器的SW2，在按下路由器的SW1，此时协调器就没有反应，表明协调器已经退出组1；但是再按下协调器SW2在按路由器的SW1就与上一步类似了。路由器与此类似可以通过SW2退出/加入组1.
终于把演示弄完了，接下来就来看看程序。在此之前还是来看看TI提供的Sample指导文档。这个文档个人觉得写的不错，要是没看之前就看程序的却很郁闷的！ 但是本人英文很差，所以需要慢慢看，等点时间放上来
从零开始学Z-Stack之3(2009-03-23 20:17:28)
-----------------Sample Application分析（上）
1、Z-Stack CC2430DB and CC2430EB Sample Application 1.1、介绍
该文档时介绍TI协议入门的一个例子SampleApp的，适用EM和DB开发板。 1.1.1、描述
这个例子是非常简单的演示，每个设备都可以发送和接收两个信息 ? 周期信息-----加入该网络的所有设备每隔10S（可能会加上一个随机数的mS）都发送一个周期信息，该信息的数据载荷为发送信息次数的计数。
? 闪烁控制信息---------通过按下SW1可以发送一个控制灯闪烁的
广播信息，该广播信息只针对组1的所有设备。
所有设备初始化为加入组1，所以网络一旦成功建立/加入就可以进行闪烁控制。可以通过按下设备的SW2退出组1，所以可以通过退出组1可以不接受闪灯信息。通过按下SW2也可以让不在组1的设备加入近组1，从而又可以接受闪灯信息了。
这个理解应该不困难的，反正我理解没有什么障碍！ 1.1.1.1、按键
? SW1：发送闪烁信息到组1所有设备 ? SW2：转换推出/加入组1状态 1.1.2、用户应用开发
这里我基本上能看明白是什么，但是我不打算写出来，因为涉及到一些ZIGBEE的关键术语，不是很明白。
大概就是简单介绍了下用户怎么利用例子做自己的应用，但是实用价值不高，说的太笼统，全是概念性的说明。 1.2、OSAL任务 1.2.1、初始化
因为Z-Stack是在OS下运行的，所以在之前必须调用osalAddTasks()初始化任务。 1.2.2、组织
关于OS的API函数介绍请看文档：Z-Stack OSAL API
(F8W-2003-0002)，应该说协议栈的每层或者说每部分都有相关的API说明文档。osalAddTasks()初始化任务， osalTaskAdd()函数添加任
务，都可以到API文档或程序中详细分析函数功能。 1.2.3、系统服务
OSAL和APL系统服务是唯一的，因为比如按键和串口类似事件处罚就只能用唯一的一个任务标识。这两个硬件都留给了用户自己定义使用。
1.2.4、应用设计
用户可能为每一个应用对象都创建一个任务，或者为所有的应用对象只创建一个任务。当选择上述的设计的时候，下面是一些设计思路： 1.2.4.1、为许多应用对象创建一个OSAL任务 下面是正面和反面（pros & cons）的一些叙述：
- Pro：接受一个互斥任务事件（开关按下或串口）时，动作是单一的。
- Pro：需要堆栈空间保存一些OSAL任务结构。
- Con：接收一个AF信息或一个AF数据确认时，动作是复杂的-----在一个用户任务上，分支多路处理应用对象的信息事件。 - Con：通过匹配描述符（如：自动匹配）去发现服务的处理过程更复杂-----为了适当的对ZDO_NEW_DSTADDR信息起作用，一个静态标志必须被维持。
1.2.4.2、为一个应用对象创建一个OSAL任务
:一对一设计的反面和正面（pros & cons）是与上面一对多设计相反的：
- Pro：在应用对象试图自动匹配时，仅仅一个ZDO_NEW_DSTADDR被
接收。
- Pro：已经被协议栈下层多元处理后的一个AF输入信息或一个AF数据确认。
- Con：需要堆栈空间保存一些OSAL任务结构。
- Con：如果两个或更多应用对象用同一个唯一的资源，接收一个互斥任务事件的动作就更复杂。 1.2.5、强制方法
任何一个OSAL任务必须用两种方法执行：一个是初始化，另一个是处理任务事件。 1.2.5.1、任务初始化
在例子中调用如下函数执行任务初始化：
“Application Name”_Init（如SAPI_Init）。该任务初始化函数应该完成如下功能：
变量或相应应用对象特征初始化，为了使OSAL内存管理更有效，在这里应该分配永久堆栈存储区。
在AF层登记相应应用对象（如：afRegister()）。
登记可用的OSAL或HAL系统服务（如：RegisterForKeys()） 1.2.5.2、任务事件处理 调用如下函数处理任务事件：
“Application Name”_ProcessEvent (e.g. SAPI_ProcessEvent()).除了强制的事件之外，任一OSAL任务能被定义多达15个任务事件。 1.2.6、强制事件