《Zigbee入门与实践》第六章Zigbee无线组网提高.pdf

《《Zigbee入门与实践》第六章Zigbee无线组网提高.pdf》由会员分享，可在线阅读，更多相关《《Zigbee入门与实践》第六章Zigbee无线组网提高.pdf（75页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、键入文字 JIAJIEKEJI 2012 ZigBee 无线传感器网络提高无线传感器网络提高 佳杰科技 D&J H T T P: / /J I E L O V E D A N.T A O B A O.C O M http:/ 佳杰科技 前言前言 笔者在上一章中给出了一个简单的点对点的无线通信实验，是读者对 ZigBee 无线传感器网络中的数据通信方法有个感性的认识。使用 ZigBee 协议栈进行应用程序开发过程中，虽然说读者可以不必关心 ZigBee 协议栈的具体细节，但是读者需要对 ZigBee 协议栈的基本构成与内部工作原理有个清晰的认识，只有这样才能将 ZigBee 协议栈提供的函数充分

2、地融入自己的实际项目开发过程中。 本章将着重讨论 ZigBee 协议栈的构成以及内部 OSAL 的工作原理， 在此基础上讲解一下ZigBee 协议栈中的串口工作原理， 最后通过一个具体的无线温度检测试验来帮助读者更好地理解本章内容。 http:/ 佳杰科技 目录目录 ZigBee 无线传感器网络提高 . 1 前言. 2 6.1 深入理解 ZigBee 协议栈的构成 . 4 6.2 ZigBee 协议栈 OSAL 介绍 . 9 6.2.1 OSAL 常用术语 . 9 6.2.2 OSAL 运行机理 . 10 6.2.3 OSAL 消息队列 . 15 6.2.4 OSAL 添加新任务 . 16 6

3、.2.5 OSAL 应用编程接口 . 17 6.3 Zstack 提高知识 . 20 6.3.1 地址类型(Address types) . 20 6.3.2 绑定(Binding) . 22 6.3.3 路由(Routing) . 25 6.3.4 配置信道(Configuring channel) . 27 6.3.5 描述符(Descriptors) . 28 6.3.6 非易失性存储项(Non-volatile Memory Items) . 29 6.3.7 安全(Security) . 29 6.4 Zigbee 与 PC 通信实验 . 31 6.5.1 提出要求 . 32 6.5

4、.2 公共文件的编程 . 32 6.5.3 协调器编程 . 33 6.5.4 实验测试 . 37 6.5.5 实验分析 . 39 6.5.6 串口工作原理剖析 . 43 6.5 PC 与 Zigbee 任意字符串传输实验 . 48 6.5.1 提出要求 . 48 6.5.2 公共文件的编程 . 48 6.5.3 协调器编程 . 49 6.5.4 代码分析 . 51 6.5.5 实验现象 . 52 6.6 协议栈串口应用扩展实验 . 53 6.5.1 提出要求 . 53 6.5.2 公共头文件编程 . 54 6.5.3 协调器编程 . 54 6.5.4 终端节点编程 . 58 6.5.5 实例测

5、试 . 65 6.7 ZigBee 串口控制 LED 灯实验 . 66 6.6.1 提出要求 . 66 6.6.2 头文件的编程 . 66 6.6.3 协调器编程 . 67 6.6.5 实验结果 . 74 6.8 ZigBee 串口互传实验 . 错误！未定义书签。错误！未定义书签。 http:/ 佳杰科技 6.9 ZigBee 按键值串口显示实验 . 错误！未定义书签。错误！未定义书签。 6.10 ZigBee 官方串口互传实验 . 错误！未定义书签。错误！未定义书签。 6.11 无线温度检侧实验 . 错误！未定义书签。错误！未定义书签。 6.6.1 实验原理及流程图 . 错误！未定义书签。错

6、误！未定义书签。 6.6.2 协调器编程 . 错误！未定义书签。错误！未定义书签。 6.6.3 终端节点编程 . 错误！未定义书签。错误！未定义书签。 6.6.4 实例测试 . 错误！未定义书签。错误！未定义书签。 6.12 ZigBee 协议栈中的 NV 操作 . 错误！未定义书签。错误！未定义书签。 6.7.1 NV 操作函数 . 错误！未定义书签。错误！未定义书签。 6.7.2 NV 操作基础实验 . 错误！未定义书签。错误！未定义书签。 6.7.3 实例测试 . 错误！未定义书签。错误！未定义书签。 6.13 本章小结 . 错误！未定义书签。错误！未定义书签。 扩展阅读之一:ZigBe

7、e 协议中规范(Profile)和簇 (Cluester)的概念 . 错误！未定义书签。错误！未定义书签。 扩展阅读之二:探究接收数据的存放位置 . 错误错误！未定义书签。！未定义书签。 6.1 深入理解深入理解 ZigBee 协议栈的构成协议栈的构成 ZigBee 协议栈的实现方式采用分层的思想，分为物理层、介质访问控制层、网络层和应用层，应用层包含应用程序支持子层、应用程序框架层和 ZDO 设备对象。在协议栈中，上层实现的功能对下层来说是不知道的，上层可以调用下层提供的函数来实现某些功能。 ZigBee 协议栈的构成如图 5-1 所示。 http:/ 佳杰科技 图 5-1 ZigBee 协

8、议栈的构成 物理层（PHY）和介质访问控制层（MAC）是由 IEEE 802.15.4 规范定义的，物理层负责将数据通过发射天线发送出去以及从天线接收数据；ZigBee 无线网络中的网络号、 网络发现等概念是介质访问控制层的内容，此外，介质访问控制层还提供点对点通信的数据确认（Per-hop Acknowledgments）以及一些用于网络发现和网络形成的命令，但是介质访问控制层不支持多跳（Multi-hop） 、网型网络（Mesh）等概念。 网络层（NWK）主要是对网型网络提供支持，如在全网范围内发送广播包，为单播数据包选择路由，确保数据包能够可靠地从一个节点发送到另一节点，此外，网络层还具

9、有安全特性，用户可以自行选择所需的安全策略。 应用程序支持子层主要是提供了一些 API 函数供用调用，此外，绑定表也是存储在应用程序支持子层。ZigBee 设备对象 ZDO 是运行在端口 0 的应用程序，主要提供了一些网络管理方面的函数。每个 ZigBee 设备都与一个特定类别(profile)有关，可能是公共类别或私有类别。这些类别定义了设备的应用环境、设备类型以及用于设备间通讯的丛集。公共类别可以确保不同供货商的设备在相同应用领域中的互通作业性。 设备是由类别定义的，并以应用对象(Application Objects)的形式实现(见图 2)。每个应用对象透过一个端点连接到 ZigBee

10、堆栈的余下部份，它们都是组件中可寻址的组件。 从应用角度看，通讯的本质就是端点到端点的连接(例如，一个带开关组件的设备与带一个或多个灯组件的远程设备进行通讯，目的是将这些灯点亮)。 端点之间的通讯是透过称之为丛集的数据结构实现的。 这些丛集是应用对象之间共享信息所需的全部属性的容器，在特殊应用中使用的丛集在类别中有定义。 每个接口都能接收(用于输入)或发送(用于输出)丛集格式的数据。一共有二个特殊的端点，即端点 0 和端点 255。端点 0 用于整个 ZigBee 设备的配置和管理。应用程序可以透过端http:/ 佳杰科技 点 0 与 ZigBee 堆栈的其它层通讯，因而实现对这些层的初始化和

11、配置。附属在端点 0 的对象被称为 ZigBee 设备对象(ZD0)。端点 255 用于向所有端点的广播。端点 241 到 254 是保留端点。 所有端点都使用应用支持子层(APS)提供的服务。 APS 透过网络层和安全服务提供层与端点相接，并为数据传送、安全和固定服务，因此能够适配不同但兼容的设备，如带灯的开关。 APS 使用网络层(NWK)提供的服务。NWK 负责设备到设备的通讯，并负责网络中设备初始化所包含的活动、消息路由和网络发现。应用层可以透过 ZigBee 设备对象(ZD0)对网络层参数进行配置和存取。 每个端口（Endpoint）都能用于收发数据，有如下两个端口较为特殊。 1)

12、端口 0 该端口用于整个 ZigBee 设备的配置和管理， 用户应用程序可以通过端口 0与 ZigBee 协议栈的应用程序支持子层、网络层进行通信，从而实现对这些层的初始化工作，在端口 0 上运行的应用程序成为 ZigBee 设备对象（ZDO，ZigBee Device Object） 。 2) 端口 255 该端口用于向所有的端口广播。 在 ZigBee 协议栈中， 各层之间进行数据传递是通过服务接入点 （Service Access Point）来实现的。一般使用两种类型的服务接入点：一种用于数据传输的服务接入点，另一种用于管理的服务接入点。例如：在 ZigBee 2007 协议栈，发送数

13、据时使用的是APSDE-DATA.request，显然这是一个发送数据请求，是从 APS 层发给下层来请求数据发送的。 服务接入点常用缩写如表 5-1 所示。 表 5-1 服务接入点常用缩写 英文缩写英文缩写 全称全称 备注备注 APS Application Support Sub-Layer 应用程序支持子层 SAP Service Access Points 服务接入点 APSDE-SAP APS Data Entity-SAP 应用程序支持子层 数据实体服务接入点 APSME-SAP APS Management Entity-SAP 应用程序支持子层 管理实体服务接入点 NLDE-S

14、AP Network Layer Data Entity-SAP 网络层数据实体服务接入点 NLME-SAP Network Layer Management Entity-SAP 网络层管理实体服务接入点 MCPS-SAP MAC Common Part Service-SAP MAC 层统用服务接入点 PD-SAP Physical Layer Data Entity-SAP 物理层数据实体服务接入点 PLME-SAP Physical Layer Management Entity-SAP 物理层管理实体服务接入点 可以将服务接入点理解为一些 API 函数，在上层可以通过调用这些 API

15、 函数来使用下层提供的功能（服务） 。 在 IAR 工程的左侧有很多文件夹，如 App、HAL、MAC 等，如图 5-2 所示，这些文件夹下面包含了很多源代码，这种实现方式与 ZigBee 协议的分层思想是相对应的，尽量将实现某些功能的函数放在同一个文件夹下。 http:/ 佳杰科技 图 5-2 工程主界面 整个协议栈是从哪里开始执行的呢？请观察图 5-2 中，在 Zmain 文件夹下有个 Zmain.c文件，打开该文件可以找到 main（）函数，这就是整个协议栈的入口点，即从该函数开始执行！ 下面看一下 main（）函数主要做了哪些工作，main（）函数原型如下： int main( voi

16、d ) osal_int_disable( INTS_ALL ); HAL_BOARD_INIT(); zmain_vdd_check(); InitBoard( OB_COLD ); HalDriverInit(); osal_nv_init( NULL ); ZMacInit(); zmain_ext_addr(); zgInit(); #ifndef NONWK afInit(); #endif osal_init_system(); osal_int_enable( INTS_ALL ); InitBoard( OB_READY ); zmain_dev_info(); #ifdef

17、LCD_SUPPORTED zmain_lcd_init(); #endif http:/ 佳杰科技 #ifdef WDT_IN_PM1 WatchDogEnable( WDTIMX ); #endif osal_start_znp(); return 0; 在 main()函数中调用了很多其他文件中的函数，在此可以暂不考虑，重点是osal_start_system()函数，在此之前的函数都是对板载硬件以及协议栈进行的初始化，知道调用 osal_start_system()函数，整个 ZigBee 协议栈才算是真正的运行起来了，那么osal_start_system()函数是如何将 ZigBe

18、e 协议栈调用起来的呢？下面将进行这部分内容的讲解。 802.15.4 MAC 层层 IEEE 802.15.4 标准为低速率无线个人局域网络(LR-WPAN)定义了 OSI 模型开始的两层。PHY 层定义了无线射频应该具备的特征，它支持二种不同的射频讯号，分别位于 2450MHz波段和 868/915MHz 波段。2450MHz 波段射频可以提供 250kbps 的数据速率和 16 个不同的讯息信道。868/915MHz 波段中，868MHz 支持 1 个数据速率为 20kbps 的讯息信道，915MHz支持 10 个数据速率为 40kbps 的讯息信道。 MAC 层负责相邻设备间的单跳数据

19、通讯。它负责设立与网络的同步，支持关联和去关联以及 MAC 层安全：它能提供二个设备之间的可靠链接。 关于关于服务接取点服务接取点 ZigBee 堆栈的不同层与 802.15.4 MAC 透过服务接取点(SAP)进行通讯。SAP 是某一特定层提供的服务与上层之间的接口。 ZigBee 堆栈的大多数层有两个接口： 数据实体接口和管理实体接口。 数据实体接口的目标是向上层提供所需的常规数据服务。 管理实体接口的目标是向上层提供存取内部层参数、 配置和管理数据的机制。 ZigBee 的安全性的安全性 安全机制由安全服务提供层提供。 然而值得注意的是， 系统的整体安全性是在类别级定义的，这意味着类别应

20、该定义某一特定网络中应该实现何种类型的安全。 每一层(MAC、网络或应用层)都能被保护，为了降低储存要求，它们可以分享安全钥匙。SSP是透过 ZD0 进行初始化和配置的，要求实现先进加密标准(AES)。ZigBee 规格定义了信任中心的用途。信任中心是在网络中分配安全钥匙的一种令人信任的设备。 ZigBee 堆栈容量和堆栈容量和 ZigBee 设备设备 根据 ZigBee 堆栈规定的所有功能和支持，我们很容易推测 ZigBee 堆栈实现需要用到设备中的海量存储器资源。 不过 ZigBee 规格定义了三种类型的设备，每种都有自己的功能要求： ZigBee 协调器是启动和配置网络的一种设备。协调器

21、可以保持间接寻址用的固定表格，支持关联，同时还能设计信任中心和执行其它活动。一个 ZigBee 网络只允许有一个 ZigBee协调器。 ZigBee 路由器是一种支持关联的设备，能够将消息转发到其它设备。ZigBee 网格或树型网络可以有多个 ZigBee 路由器。ZigBee 星型网络不支持 ZigBee 路由器。 ZigBee 端终设备可以执行它的相关功能，并使用 ZigBee 网络到达其它需要与其通讯的设备。它的内存容量要求最少。 然而需要特别注意的是，网络的特定架构会戏剧性地影响设备所需的资源。NWK 支持http:/ 佳杰科技 的网络拓朴有星型、树型和网格型。在这几种网络拓朴中，星型

22、网络对资源的要求最低。 6.2 ZigBee 协议栈协议栈 OSAL 介绍介绍 ZigBee 协议栈包含了 ZigBee 协议所规定的基本功能， 这些功能是以函数的形式实现的，为了便于管理这些函数集，从 ZigBee 2006 协议栈开始，ZigBee 协议栈内加入了实时操作系统，称为 OSAL（操作系统抽象层，Operating System Abstraction Layer） 。 非计算机专业的读者对操作系统知识较为欠缺，但是 ZigBee 协议栈里内嵌的操作系统很简单，读者只需做几个小实验，会很快掌握整个 OSAL 的工作原理。 OSAL（Operating System Abstra

23、ction Layer） ，即操作系统抽象层，如何理解 OSAL 呢？从字面意思看是跟操作系统有关， 但是后面为什么又加上 “抽象层” 呢？在 ZigBee 协议栈中，OSAL 有什么作用呢？下面将对上述问题进行讨论。 6.2.1 OSAL 常用术语常用术语 在讲解之前，先介绍操作系统有关的部分基础知识。 操作系统（OS）基本术语如下。 1) 资源（Resource） 任何任务所占用的实体都可以称为资源， 如一个变量、 数组、结构体等。 2) 共用资源（Shared Resource） 至少可以被两个任务使用的资源称为共享资源， 为了防止共享资源被破坏，每个任务在操作共享资源时，必须保证是独占

24、改资源。 3) 任务（Task） 一个任务，又称一个线程，是一个简单的程序的执行工程，在任务执行过程中，可以认为 PU 完全属于该任务。在任务设计时，需要将问题尽可能地分为多个任务，每个任务独立完成某种功能，同时被赋予一定的优先级，拥有自己的 CPU 寄存器和堆栈空间。一般讲任务设计为一个无线循环。 4) 多任务运行（Muti-task Running） 实际上只有一个任务在运行，但是 CPU 可以使用任务调度策略将多个任务进行调度， 每个任务执行特定的时间， 时间片到了以后，就进行任务切换，由于每个任务时间很短，例如：10ms，因此，任务切换很频繁，这就造成了多任务同时进行的“假象” 。 5

25、) 内核（Kernel） 在多任务系统中，内核负责管理各个任务，主要包括：为每个任务分配 CPU 时间；任务调度；负责任务间的通信。内核提供的基本的内核服务是任务切换。 使用内核可以大大简化应用系统的程序设计方法， 借助内核提供的任务切换功能，可以将应用程序分为不同的任务来实现。 6) 互斥（Mutual Exclusion） 多任务间通信最简单， 常用的方法是使用共享数据结构。对于单片机系统， 所有的任务都在单一的地址空间下， 使用共享的数据结构包括全局变量、指针、缓冲区等。虽然共享数据结构的方法简单，但是必须保证对共享数据结构的写操作具有唯一性，以避免晶振和数据不同步。 保护共享资源最常用

26、的方法是： 关中断； 使用测试并置位指令（T&S 指令） ； 禁止任务切换； 使用信号量。 其中，在 ZigBee 协议栈内嵌操作系统中，经常使用的方法是关中断。 http:/ 佳杰科技 7) 消息队列（Message Queue） 消息队列用于任务间传递消息， 通常包含任务间同步的信息。 通过内核提供的服务、 任务或者中断服务程序将一条消息放入消息队列，然后，其他任务可以使用内核提供的服务从消息队列中获取属于自己的消息。 在 ZigBee 协议栈中，OSAL 主要提供如下功能： 任务注册、初始化和启动； 任务间的同步、互斥； 中断处理； 存储器分配和管理。 6.2.2 OSAL 运行机理运行

27、机理 如图 5-1 中从宏观上表现了 ZigBee 协议的结构，但并没有 OSAL 的踪迹。ZigBee 协议栈与 ZigBee 协议之间并不能完全画等号。 ZigBee 协议栈仅仅是 ZigBee 协议的具体实现， 因此，存在于 ZigBee 协议栈中使用的 OSAL 并没有出现在 ZigBee 协议中。 在 ZigBee 协议中可以找到使用 OSAL 的某些根源。 在基于 ZigBee 协议栈的应用程序开打过程中，用户只需要实现应用层的程序开发即可。从图 5-1 可以看出应用程序框架中包含了最多 240 个应用程序对象，每个应用程序对象运行在不同的端口上，因此，需要一个机制来实现任务的切换

28、、同步和互斥，这就是 OSAL 产生的根源。 因此，从上面的分析可以得出下面的结论：OSAL 就是一种支持多任务运行的系统资源分配机制。 OSAL 与标准的操作系统还是有一定区别的，OSAL 实现了类似操作系统的某些功能，例如：任务切换、提供了内存管理功能等，但 OSAL 并不能称为真正意义上的操作系统。 为了探究 OSAL 运行机理，请读者回顾一下第四章讲解的点对点数据传输实验。 在左侧工作空间窗口打开 App 文件夹，可以看到三个文件，分别是“Coordinator.c” 、“Coordinator.h” 、 “OSAL_GenericApp.c” 。 整个程序所实现的功能都包含在这三个文

29、件当中。 首先打开 Coordinator.c 文件，可以看到两个比较重要的函数 GenericApp_Init 和GenericApp_ProcessEvent 则负责处理传递给此任务的事件。GenericApp_ProcessEvent 函数的主要功能是判断由参数传递的事件类型，然后执行相应的事件处理函数。 因此，在 ZigBee 协议栈中，OSAL 负责调度各任务的运行，如果有事件发生了，则会调用相应的事件处理函数进行处理。OSAL 的工作原理示意图如图 5-3 所示。 那么，事件和任务的事件处理函数式如何联系起来的呢？ ZigBee 中采用的方法是：建立一个事件表，保存各个任务的对于的

30、事件，建立另一个函数表，保存各个任务事件处理函数的地址，然后将这两张表建立某种对应关系，当某一事件发生时则查找函数表找到对应的事件处理函数即可。 现在问题转变为： 用什么样的数据结构来实现事件表和函数表呢？如何将时间表和函数表建立对应关系呢？可以说， 只要将上述两个问题解决， 在整个协议栈的开发将会变得很容易。 http:/ 佳杰科技 图 5-3 OSAL 的工作原理示意图 在 ZigBee 协议栈中，有三个变量至关重要。 taskCnt该变量保存了任务的总个数。 该变量的声明为:uint8 taskCnt，其中 uint8 的定义为： typedef unsigned char uint8

31、tasksEvent这是一个指针，指向了事件表的首地址。 该变量的声明为：uint16*tasksEvents,其中 uint16 的定义为： typedef unsigned short uint16 taskArr这是一个数组，该数组的每一项都是一个函数指针，指向了事件处理函数。 该数组的声明为：pTaskEventHandlerFn tasksArr 其中 pTaskEventHandlerFn 的定义（需要特别注意）如下： Typedef unsigned short (*pTaskEventHandlerFn) ( unsigned char task_id, unsigned sh

32、ort event ) 这是定义了一个函数指针,也就是说数组里面存放的是函数。 因此，tasksArr 数组的每一项都是一个函数指针，指向了事件处理函数。 事件表和函数表的关系如图 5-4 所示。 讲到这里， 可以总结一下OSAL的工作原理： 提供tasksEvents指针访问事件表的每一项，如果有事件发生，则查找函数表找到事件处理函数进行处理，处理完后，继续访问事件表，查看是否有事件发生，无线循环。 tasksEventstasksCnt GenericApp_ProcessEvent tasksEvents1 Hal_ProcessEvent tasksEvents2 Nwk_event_

33、loop tasksEvents3 macEventLoop Taskevent LOOP 图 5-4 事件表和函数表的关系 从这种意思上说，OSAL 是一种基于事件驱动的轮询式操作系统。事件驱动是指发生事件后采取相应的事件处理方法，轮询指的是不断地查看是否有事件发生。 OSAL 任务 1 任务 2 任务 3 任务 1 事件处理函数 任务 2 事件处理函数 任务 3 事件处理函数 http:/ 佳杰科技 前文提到，在 main()函数中，直到调用 osal_start_system()函数，整个 ZigBee 协议栈才算是真正地运行起来了，下面将深入 osal_start_system()函数

34、的内部去探究协议栈是如何被调动起来的。 osal_start_system()函数原型如下： void osal_start_system(void) #if !defined ( ZBIT ) & !defined ( UBIT ) for(;) #endif uint8 idx = 0; osalTimeUpdate(); Hal_ProcessPoll(); do if (tasksEventsidx) break; while (+idx tasksCnt); if (idx tasksCnt) uint16 events; halIntState_t intState; HAL_EN

35、TER_CRITICAL_SECTION(intState); events = tasksEventsidx; tasksEventsidx = 0; HAL_EXIT_CRITICAL_SECTION(intState); events = (tasksArridx)(idx,events ); HAL_ENTER_CRITICAL_SECTION(intState); tasksEventsidx |= events; HAL_EXIT_CRITICAL_SECTION(intState); #if defined( POWER_SAVING ) else osal_pwrmgr_pow

36、ercoserve(); #endif 为了看清 osal_start_system()函数的工作机制，可以将条件编译指令去掉，此外，前文讲到，在访问共享变量时需要保证该变量不被其他任务同时访问，因此，这里采用的关中断http:/ 佳杰科技 的方法，如下代码块就是一种典型的使用方法。 HAL_ENTER_CRITICAL_SECTION(intState); HAL_ENTER_CRITICAL_SECTION(intState); 使 用HAL_ENTER_CRITICAL_SECTION 关 中 断 ， 访 问 完 共 享 变 量 后 ， 使 用HAL_ENTER_CRITICAL_SEC

37、TION 宏恢复中断即可。 因此，为了分析问题方便，可以将这些宏去掉，经过简化的 osal_start_system()函数如下（简化后便于分析，同时工作原理没有变化） ： 1 void osal_start_system(void) 2 for(;) 3 uint8 idx = 0; 4 osalTimeUpdate(); 5 Hal_ProcessPoll(); 6 do 7 if (tasksEventsidx) 8 break; 9 while (+idx tasksCnt); 10 if (idx hdr.event ) case AF_INCOMING_MSG_CMD Generi

38、cApp_MessageMSGCB( MSGpkt ); break; default: break; osal_msg_deallocate( (uint8 *)MSGpkt ); MSGpkt = ( afIncomingMSGPacket_t *)osal_msg_receive( GenericApp_taskID); return (events SYS_EVENT_MSG); return 0; GenericApp_ProcessEvent函数的基本实现方法是:使用oasl_msg_receive函数从消息队列上接收一个消息（在该消息中包含了事件以及接收到的数据） ，然后使用 s

39、witch-case 语句判断事件类型，如果是接收到新数据事件 AF_INCOMING_MSG_CMD，则调用相应的事件处理函数。 注意加粗部分的 return 语句，使用了异或运算，可以通过下面的例子看到异或运算的作用。 使用如表 5-2 中的事件，假设同时发生了串口接收事件和读取温度事件，则此时http:/ 佳杰科技 events=0b00000101,即 0X05，假设同时发生了串口接收事件，则应该将第 0 位清零，如何实现呢？只需要使用异或运算即可，即 enents0 x01=0 x50 x01=0 x04，即 0b00000100，可见使用异或运算恰好可以将出来完的事件清除，仅留下未

40、处理的事件。 从上述函数中可以看到 SYS_EVENT_MSG，SYS_EVENT_MSG 与 AF_INCOMING_MSG_CMD有什么内在联系呢？ 前文讲到可以使用每个二进制位表示一个事件，因此在 ZigBee 协议栈中，用户可以自己定义事件，但是，协议栈同时也给出了几个已经定义好的事件，SYS_EVENT_MSG 就是其中的一个事件，SYS_EVENT_MSG 的定义如下: #defined SYS_EVENT_MSG 0 x8000 由协议栈定义的事件成为系统强制事件（Mandatory Events） ，SYS_EVENT_MSG 是一个事件集合，主要包括以下几个事件（其中前两个较

41、为常用） ： 1. AF_INCOMING_MSG_CMD 表示收到了一个新的无线数据。 2. ZDO_STATE_CHANGE 当网络状态发生变化时， 会产生该事件， 如终端节点加入网络时， 就可以通过判断该事件来决定何时向协调器发生数据包 （读者可以结合第四章终端节点的代码进行理解） 。 3. ZDO_CB_MSG 指示每一个注册的 ZDO 响应消息。 4. AF_DATA_CONFIRM_CMD 调用 AF_DataRequest()发生数据时， 有时需要确认信息，该事件与此有关。 因此，可以将 OSAL 的运行机理总结为： 通过不断的查询事件表来判断是否有事件发生， 如果有事件发生，

42、则查找函数表找到对应的事件处理函数对事件进行处理。 事件表使用数组来实现， 数据的每一项对应一个任务的事件， 每一位表示一个事件；函数表使用函数指针数组来实现， 数组的每一项是一个函数指针， 指向了事件处理函数。 6.2.3 OSAL 消息队列消息队列 讲解消息队列之前需要讲解一下消息与事件的区别。 事件是驱动任务去执行某些操作的条件，当系统中产生了一个事件，OSAL 将这个事件传递给相应的任务后，任务才能执行一个相应的操作（调用事件处理函数去处理） 。 通常某些事件发生时，又伴随着一些附加信息的产生，例如：从天线接收到数据后，会产生 AF_INCOMING_MSG_CMD 消息，但是任务的事

43、件处理函数在处理这个事件的时候，还需要的到所收到的数据。 因此，这就需要将事件和数据封装成一个消息，将消息发送到消息队列，然后在事件处理函数中就可以使用 osal_msg_receive，从消息队列中得到该消息。如下代码可以从消息队列中得到一个消息。 MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive(GenericApp_TaskID); OSAL 维护了一个消息队列，每一个消息都会被放到这个消息队列中去，当任务接收到事件后， 可以从消息队列中获取属于自己的消息， 然后调用消息处理函数进行相应的处理即可。 OSAL 中消息队列如图 5-5 所

44、示。 http:/ 佳杰科技 图 5-5 OSAL 中消息队列 每个消息都包含一个消息头 osal_msg_hdr_t 和用户自定义的消息， osal_msg_hdr_t 结构体的定义为： typedef struct Void *next； Uint16 len； Uint8 dest_id; osal_msg_hdr_t; 6.2.4 OSAL 添加新任务添加新任务 在使用 ZigBee 协议栈进行应用程序开发时，如何在应用程序中添加一个新任务。 结合第 4 章讲解使用的工程，打开 OSAL_GenericApp.c 文件，可以找到数组 tasksArr和函数 osalInitTasks。

45、tasksArr数组里存放了所有任务的事件处理函数的地址；osalInitTasks是 OSAL 的任务初始化函数，所有任务的初始化工作都在这里面完成，并且自动给每个任务分配一个 ID。 因此，要添加新任务，只需要编写两个函数： 新任务的初始化函数； 新任务的事件处理函数。 将新任务的初始化函数添加在 osalInitTasks 函数的最后，如下代码所示。 const pTaskEventHandlerFn tasksArr = macEventLoop, nwk_event_loop, Hal_ProcessEvent, #if defined( MT_TASK ) MT_ProcessEv

46、ent, #endif APS_event_loop, #if defined ( ZIGBEE_FRAGMENTATION ) APSF_ProcessEvent, #endif Viod*next Uint 16 len Uint 8 dest_id 用户自定义的消息 Void*next Uint 16 len Uint 8 dest- 用户自定义的消息 Void*next Uint 16 len Uint 8 dest_id 用户自定义的消息 http:/ 佳杰科技 ZDApp_event_loop, #if defined ( ZIGBEE_FREQ_AGILITY ) | defin

47、ed ( ZIGBEE_PANID_CONFLICT ) ZDNwkMgr_event_loop, #endif GenericApp_ProcessEvent/添加任务处理函数添加任务处理函数 ; 将事件处理函数的地址加入 tasksArr数组，如下代码所示。 void osalInitTasks( void ) uint8 taskID = 0; tasksEvents = (uint16 *)osal_mem_alloc( sizeof( uint16 ) * tasksCnt); osal_memset( tasksEvents, 0, (sizeof( uint16 ) * task

48、sCnt); macTaskInit( taskID+ ); nwk_init( taskID+ ); Hal_Init( taskID+ ); #if defined( MT_TASK ) MT_TaskInit( taskID+ ); #endif APS_Init( taskID+ ); #if defined ( ZIGBEE_FRAGMENTATION ) APSF_Init( taskID+ ); #endif ZDApp_Init( taskID+ ); #if defined ( ZIGBEE_FREQ_AGILITY ) | defined ( ZIGBEE_PANID_CO

49、NFLICT ) ZDNwkMgr_Init( taskID+ ); #endif GenericApp_Init( taskID );/为自己的任务分配为自己的任务分配 ID 在此例中，将此前提到过的 GenericApp_ProcessEvent 函数添加到了数组的末尾，GenericApp_Init 函数在 osalInitTasks 中被调用。 需要注意两点： tasksArr数组里各事件处理函数的排列顺序要与 osalInitTasks 函数中调用各任务初始化函数的顺序保持一致， 只有这样才能够保证每个任务的事件处理函数能够接收到正确的任务 ID（在 osalInitTasks 函数

50、中分配） 。 为了保存osalInitTasks函数所分配的任务ID， 需要给每一个任务定义一个全局变量。如 在 Coordinator.c 中 定 义 了 一 个 全 局 变 量 GenericApp_TaskID ， 并 且 在GenericApp_Init 函数中进行了赋值。 6.2.5 OSAL 应用编程接口应用编程接口 既然 ZigBee 协议栈内嵌了操作系统来支持多任务运行，那么任务间同步、互斥等都需要相应的API来支持， 下面讲解一下OSAL提供的API （应用编程接口， Application Programming http:/ 佳杰科技 Interface） 。 总体而言，