学习zigbee入门-3

转】学习zigbee入门-3

Sample Application 分析-上
1、Z-Stack CC2430DB and CC2430EB Sample Application 
1.1、介绍 
       该文档时介绍 TI 协议入门的一个例子 SampleApp 的，适用 EB开发板。 
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()初始化任务（特别说明一下 osalAddTasks()函数在ZStack-1.4.3-1.2.1中被省略掉了）
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（如 SampleApp_Init）。该任务初始化函数应该完成如下功能：变量或相应应用对象特征初始化，为了使 OSAL 内存管理更有效，在这里应该分配永久堆栈存储区； 在 AF 层登记相应应用对象（如：afRegister()）； 登记可用的 OSAL 或 HAL 系统服务（如：RegisterForKeys()） 
1.2.5.2、任务事件处理 
        调用如下函数处理任务事件： “Application Name”_ProcessEvent (e.g. SampleApp_ProcessEvent()).除了强制的事件之外，任一 OSAL 任务能被定义多达 15 个任务事件。
1.2.6、强制事件 
       一个任务事件 SYS_EVENT_MSG (0x8000), 被保留必须通过 OSAL 任务设计。 
1.2.6.1、SYS_EVENT_MSG (0x8000) 
        任务事件管理者应该处理如下的系统信息子集，下面只列出了部分信息，但是是最常用的几个信息处理，推荐根据例子复制到自己项目中使用。 
1.2.6.1.1、AF_DATA_CONFIRM_CMD 
       调用 AF_DataRequest()函数数据请求成功的指示。Zsuccess 确认数据请求传输成功，如果数据请求设置 AF_ACK_REQUEST 标志位，那么，只有最终目的地址成功接收后，Zsuccess 确认才返回。如果如果数据请求没有设置 AF_ACK_REQUEST 标志位，那么，数据请求只要成功传输到下跳节点就返回 Zsuccess 确认信息。 
1.26.1.2、AF_INCOMING_MSG_CMD 
      AF 信息输入指示 
1.2.6.1.3、KEY_CHANGE 
        键盘动作指示 
1.2.6.1.4、ZDO_NEW_DSTADDR 
        匹配描述符请求（Match Deor Request）响应指示。（例如：自动匹配） 
1.2.6.1.5、ZDO_STATE_CHANGE 
        网络状态改变指示 
1.3、网络信息
       示例应用程序编译为协调器的在DEFAULT_CHANLIST指定的通道上形成一个网络，协调器将建立一个随机编号源于自身的 IEEE 地址或由 ZDAPP_CONFIG_PAN_ID 指定的网络 PAN ID（如果ZDAPP_CONFIG_PAN_ID 不为 0xFFFF）。 示例应用程序编译为路由器或结束设备的将尝试加入网络在DEFAULT_CHANLIST指定的通道上，如果ZDAPP_CONFIG_PAN_ID 没有定义为 0 xFFFF ，路由器将受到限制，只有加入参数 ZDAPP_CONFIG_PAN_ID 规定的网络 PAN ID。 
1.3.1、自动启动 
        设备自动开始尝试组建或加入网络。如果设备设置为等待计时器或其他外部事件发生后才启动，那么HOLD_AUTO_START 必须被定义。为了稍后以手动启动方式启动设备，那么需要调用

ZDApp_StartUpFromApp()函数
1.3.2、软件启动 
        为了在形成网络过程中节省所需的设备类型，那么所有的路由器设备可以被通过SOFT_START定义作为一个协调器。如果自动启动是需要的话，那么AUTO_SOFT_START必须被定义。 
1.3.3、网络恢复 
        通过设置 NV_RESTORE 和/或 NV_INIT，可以让设备断电或者意外掉电重新启动后重新回复网络。 
1.3.4、加入通告 
       当设备形成或加入网络后会发通报到 ZDO_STATE_CHANGE 信息事件