ZigBee协议栈TI Z-Stack分析

ZigBee协议栈TI Z-Stack分析

2010-11-05 11:26

转载自  slcfhr

最终编辑  slcfhr

标签(TAG)： ZigBee   协议栈   Z-Stack   2007年4月，德州仪器推出业界领先的ZigBee协议栈（Z-Stack）。Z-Stack符合ZigBee 2006规范，支持多种平台，包括基于CC2420收发器以及TI MSP430超低功耗单片机的平台，CC2430的SOC平台C51RF-3-PK等。Z-Stack包含了网状网络拓扑的几近于全功能的协议栈，在竞争激烈的ZigBee领域占有很重要地位。 ZigBee stack应用开发相关概念 ZigBee术语 一、属性 属性Attribute是一个反映物理数量或状态的数据值，比如开关值（On/Off） ,温度值、百分比等。 二、群集 群集Cluster是包含一个或多个属性（attribute）的群组。简单的说，群集就是属性的集合。每个群集都被分配一个唯一的群集ID 且每个群集最多有65536个属性。  三、设备描述 设备描述Device Description是指一个大型目标应用的一部分，包括一个或多个群集，并且指定群集是输入还是输出。 四、端点 端点EndPoint是协议栈应用层的入口，也可以理解应用对象（Application Object）存在的地方，它是为实现一个设备描述而定义的一组群集。每个ZigBee设备可以最多支持240这样的端点，这也意味着在每个设备上可以定义240个应用对象。端点0被保留用于与ZDO接口而端点255被保留用于广播，端点241-254则被保留用于将来做扩展使用。 五、配置文件 配置文件Profile可以理解为共同促成交互式应用的多个设备描述项的集合。 ZigBee联盟已经定义了部分标准的配置文件，比如远程控制开关配置文件和光传感器配置文件等。任何遵循某一标准配置文件的节点都可以与实现相同配置文件的节点进行互操作。用户也可以创建自己的配置文件然后递交ZigBee联盟测试、审核批准。 配置文件是对逻辑设备及其接口描述的集合，是面向某个应用类别的公约、准则。设备描述符是为分布应用提供的描述项，多种描述项共同组成描述集合Profile。定义Profile的目的就是使得不同厂商生产的ZigBee设备能够实现互操作。 六、节点 节点Node也可以理解为一个容器，包含一组ZigBee设备，分享一个无线信道。每个节点有且只有一个无线信道使用。 七、绑定（Binding） ZigBee定义了一个称为端点绑定的特殊过程。绑定即在源节点的某个端点（ EndPoint）和目标节点的某个端点之间创建一条逻辑链路。绑定可以发生在两个或多个设备之间。协调器节点维护一个基本上包括两个或多个端点之间的逻辑链路的绑定表。 在绑定表中，包含如下信息，源节点和目的节点的IEEE地址、Endpoint号以及ClusterID。对于可以建立绑定关系的两个节点，它们的Cluster的属性必须一个选择“输入”，另一个选择“输出”，而且ClusterID值相等，只有这样，它们彼此才能建立绑定。如果目标设备的扩展地址是已知的，则调用zb_BindDeviceRequest( )函数可以创建一个绑定条目。 八、寻址（Addressing） 在ZigBee网络中，使用两种地址： 一种是64位的IEEE Address，也叫物理地址，64位地址在所有ZigBee设备之中是唯一，其中包含一个由IEEE分配、也是全球唯一的24位制造商特定组织标识符OUI（Organizationally Unique Identifier）。 另一种是16位的NWK Address即网络地址，当设备加入ZigBee网络时，从允许其加入的父设备上获取16位网络地址。该地址在ZigBee网络中唯一，用于数据传输和数据包路由。 在ZigBee中，数据包可以单点传送（unicast），多点传送（multicast）或者广播传送（broadcast），所以必须有地址模式参数。一个单点传送数据包只发送给一个设备，多点传送数据包则要传送给一组设备，而广播数据包则要发送给整个网络的所有节点。当应用程序需要将数据包发送给网络上的一组设备时，还可以使用组寻址方式（Group Addressing）。 TI Z-Stack协议栈架构分析 协议栈定义通信硬件和软件在不同级如何协调工作。在网络通信领域，在每个协议层的实体们通过对信息打包与对等实体通信。在通信的发送方，用户需要传递的数据包按照从高层到低层的顺序依次通过各个协议层，每一层的实体按照最初预定消息格式向数据信息中加入自己的信息，比如每一层的头信息和校验等终抵达最低的物理层，变成数据位流，在物理连接间传递。在通信的接收方数据包依次向上通过协议栈，每一层的实体能够根据预定的格式准确的提取需要在本层处理的数据信息，最终用户应用程序得到最终的数据信息进行处理。 ZigBee无线网络的实现，是建立在ZigBee协议栈的基础上的，协议栈采用分层的结构协议分层的目的是为了使各层相对独立，每一层都提供一些服务，服务由协议定义，程序员只需关心与他的工作直接相关的那些层的协议，它们向高层提供服务，并由低层提供服务。 在ZigBee协议栈中，PHY、MAC层位于最低层，且与硬件相关；NWK、APS, APL层以及安全层建立在PHY和MAC层之上，并且完全与硬件无关。分层的结构脉络清晰、一目了然，给设计和调试带来极大的方便。 整个Z-Stack采用分层的软件结构，硬件抽象层（HAL）提供各种硬件模块的驱动，包括定时器Timer，通用I/O口GPIO，通用异步收发传输器UART，模数转换ADC的应用程序接口API，提供各种服务的扩展集。操作系统抽象层OSAL实现了一个易用的操作系统平台，通过时间片轮转函数实现任务调度，提供多任务处理机制。用户可以调用OSAL提供的相关API进行多任务编程，将自己的应用程序作为一个独立的任务来实现。 Z-stack OSAL API 介绍 OSAL层是与协议栈独立的，但是整个协议都要基于OS才能运行。OSAL提供如下服务和管理：信息管理、任务同步、时间管理、中断管理、任务管理、内存管理、电源管理以及非易失存储管理。 一、信息管理API 信息管理为任务间的信息交换或者外部处理事件（例如：中断服务程序或一个控制循环内的函数调用等）提供一种管理机制。包括允许任务分配或不分配信息缓存、发送命令信息到其他任务、接受应答信息等API函数。 二、同步任务API 该API允许一个任务等待某个事件的发生并返回等待期间的控制。该API的功能是为某个任务设置事件，一旦任何一个事件被设置就修改该任务。 三、时间管理API 该API允许定时器被内部（Z-Stack）任务和外部任务使用。该API提供开始和停止一个定时器的功能，这些定时器能用毫秒（ms）设置。 四、中断管理API 这些API是外部中断和任务的接口。这些API函数允许一个任务为每个中断分配指定服务程序。这些中断能被允许或禁止。在服务程序内，可为其他的任务设置事件。 五、任务管理API 该API用在管理OSAL中的任务，包括系统任务和用户自定义任务的创建、管理和信息处理等。  六、内存管理API 该API描绘了简单的存储分配系统。这些函数允许动态存储分配。 七、电源管理API 这里描写了OSAL的电源管理系统。当OSAL安全地关闭接收器与外部硬件并使处理器进入休眠模式时，该系统提供向应用/任务通告该事务的方式。