ZigBee2006入门_3.doc_第1页
ZigBee2006入门_3.doc_第2页
ZigBee2006入门_3.doc_第3页
ZigBee2006入门_3.doc_第4页
ZigBee2006入门_3.doc_第5页
已阅读5页,还剩8页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

专业尙阳 2011-1-12ZigBee入门之第二章Z-Stack 简介指导Z-Stack 指导 1首先来看看 Z-Stack 的结构。 第一次打开工程印象最深刻的就是左边一排文件夹,如图 所示。 其实这个还是很容易理解的: APP(Application Programming):应用层目录,这是用户创建各种不同工程的区域,在这个目录中包含了应用层的内容和这个项目的主要内容,在协议栈里面一般是以操作系统的任务实现的。 HAL(Hardware (H/W) Abstraction Layer):硬件层目录,包含有与硬件相关的配置和驱动及操作函数。 MAC:MAC 层目录,包含了 MAC 层的参数配置文件及其 MAC 的 LIB 库的函数接口文件。 MT(Monitor Test):实现通过串口可控各层,于各层进行直接交互。 (这个很重要哦)NWK(ZigBee Network Layer):网络层目录,含网络层配置参数文件及网络层库的函数接口文件,APS 层库的函数接口OSAL(Operating System (OS) Abstraction Layer):协议栈的操作系统。 Profile:AF(Application work) 层目录,包含 AF 层处理函数文件。 Security:安全层目录,安全层处理函数,比如加密函数等。 Services:地址处理函数目录,包括着地址模式的定义及地址处理函数。 Tools:工程配置目录,包括空间划分及 ZStack 相关配置信息。 ZDO(ZigBee Device Objects):ZDO 目录。 ZMac: MAC 层目录,包括 MAC 层参数配置及 MAC 层 LIB 库函数回调处理函数。ZMain:主函数目录,包括入口函数及硬件配置文件。 Output:输出文件目录,这个 EW8051 IDE 自动生成的。 那么知道各个文件夹大概是什么功能,分布在 ZIGBEE 的哪一层,那么在以后的工作中无论是查询某些功能函数还是修改某些功能函数,甚至是添加或删除某些功能函数就能顺利的找到在什么地方了,当然要想真的顺利还需要花更多的时间熟悉这个协议栈了!了解 Z-Stack 结构后那么就能看看它的功能。不用问,这个是针对 ZIGBEE 无线网络写的协议栈,呵呵!那么就要先大概了解下 ZIGBEE 这个技术。我这里就不介绍理论了,就从 Z-Stack 实际的角度介绍些实用的概念。 1、Zigbee 网络中的节点 在 ZB 网络中,每个节点都有指定的配置参数,从而确定其设备类型,不同的设备类型,在网络中有着不一样网络任务。在属于多跳网络的 ZB 网络中,两个节点需要完成数据传输,可能需要经过其他中间节点的协助,所以节点的类型参数配置是非常必要的。对每个节点有两个任务: (i)执行指定的网络功能函数 (ii)配置确定的参数到指定的值。 网络功能的设置确定了该节点的类型,参数配置和指定的值确定了堆栈的模式。 节点类型 在 ZB 中,设备类型分为三类:协调器,路由器和终端设备。 就是这三种设备类型组成的一个典型网络。 其中黑色节点为协调器, 红色节点为路由器, 白色节点为终端设备 那么这个就是一个典型的网状网络 MESH(网状)。 协调器-是一个 ZB 网络的第一个开始的设备,或者是一个 ZB 网络的启动或建立网络的设备。协调器节点选择一个信道和网络标志符(也叫PAN ID),然后开始建立一个网络。协调器设备在网络中还可以有其他作用,比如建立安全机制、网络中的绑定的建立等等。 注意:协调器主要的作用是建立一个网络和配置该网络的性质参数。一旦这些完成,该协调器就如同一个路由器,网络中的其他操作并不依赖该协调器,因为ZB 是分布式网络。 路由器-一个路由器的功能有(1)作为普通设备加入网络(2)多跳路由(3)辅助其它的子节点完成通信。 一般来说,路由器需要一直处于工作状态,所以需要主干线供电(区别于电池供电)。但是在某指定的网络结构中可以采用电池供电,如“串树型”网络模式中,允许路由器周期的运行操作,所以可以采用电池供电。 终端设备-为了维持网络最基本的运行,对于终端设备没有指定的责任。也就是说,在一个基本网络中,终端设备没有必不可缺少性。所以它可以根据自己功能需要休眠或唤醒,因此为电池供电设备。一般来说,该设备需要的内存较少(特别是内部RAM) 堆栈模式(Stack Profile)-需要被配置为指定值的堆栈参数,连同这些值被称为堆栈模式。这些堆栈模式参数被ZB联盟定义指定。在同一个网络中的设备必须符合同一个堆栈模式(同一个网络中所有设备的堆栈模式配置参数必须一致)。为了互操作性,ZB联盟为06协议栈定义了一个堆栈模式,所有的设备只要遵循该模式的参数配置,即使在不同厂商买的不同设备同样可以形成网络。如果应用开发者改变了这些参数配置,那么他的产品将不能与遵循ZB联盟定义模式的产品组成网络,也就是说该开发者开发的产品具有特殊性,我们称之为“关闭的网络”,也就是说它的设备只有在自己的产品中使用,不能与其他产品通信。该协议模式标志符在设备通信的信标传输中被匹配,如果不匹配,那么该设备将不能加入网络。“关闭网络”的堆栈模式有一个 0ID,而 06 协议栈模式有一个1ID。该堆栈模式被配置在 nwk_globals.h 文件中的 STACK_PROFILE_ID 参数。如:#define STACK_PROFILE_ID HOME_CONTROLS。 2、Zigbee 网络中的地址 地址类型 ZB 设备有两种地址类型,一个是 64 位 IEEE 地址(也可以叫 MAC 地址或扩展地址),一个是 16 位网络地址(也可以叫逻辑地址或短地址)。 64 位地址是全球唯一的,作为设备(产品)的终生地址被分配。它通常被开发商或安装的时候被指定。该地址由 IEEE 分配指定,该地址的信息和获得该地址的方法见:开发板使用手册,16位地址在设备加入网络的时候被分配,由这个网络自动分配。该地址只能用与本网络中,标志不同的设备间传递信息。 网络地址分配 ZB 分布式网络中地址分配是唯一的。为了不使网络中设备混乱,为每个设备指定确定的地址是非常必要的。 在 分 配 地 址 之 前,一 些 参 数 必 须 被 设 置 :MAX_DEPTH, MAX_ROUTERS 和MAX_CHILDREN 。 这些参数都是 ZB 协议模式的一部分,在 06ZS 模式中这些参数设置为 :(MAX_DEPTH = 5, MAX_CHILDREN = 20, MAX_ROUTERS = 6). 参数设置 MAX_DEPTH 决定了网络的最大深度。协调器的深度是 0,它的子设备的深度是1,他们的子设备的深度是 2,依次类推。所以 MAX_DEPTH 参数限制了网络物理上的“长度” ,MAX_CHILDREN 参数决定了一个路由器(或一个协调器)能承载子设备的最大数目。MAX_ROUTERS 参数决定了一个路由器(或一个协调器)能承载路由器的最大数目。这 个 参 数 实 际 上 是 MAX_CHILDREN 参 数 的 一 个 子 集 , 剩 下 的(MAX_CHILDREN-MAX_ROUTERS)地址空间属于终端设备。 开发者自定义 如果开发者想改变这些值,那么需要做如下几步: 首先得保证这些参数新的值是合法的。既然整个地址空间被限制在 2-16 内,那么 这 些 参 数 的 大 小 就 已 经 有 了 限 制 。 分 布 在 release ( 在 文 件 夹 ProjectszstackTools 中)的 Cskip.xls 文件能校验这些参数是否合法。在键入这些参数的值后大概这个电子表格,如果非法,一个错误信息将给出。之后选择合法的值,开发者需要确保不使用标准的协议栈模式,而用指定的协议栈模式代替(用 NETWORK_SPECIFIC 替换 STACK_PROFILE_ID 当前的值)。然后在“nwk_globals.h”文件中的 MAX_DEPTH 参数根据需要设置为适当的值。 另外,nwk_globals.c 文件中排列的 CskipChldrn 和 CskipRtrs 必须被设置,这些排列是z-stack 中的寻址 为了在网络中发送数据到一个设备,应用层一般用 AF_DataRequest()函数。而被发送的目的设备的地址类型 afAddrType_t 被定义在“ZComDef.h”中: typedef struct union uint16 shortAddr; ZLongAddr_t extAddr; addr; byte addrMode; zAddrType_t; 地址模式参数 注意:除这个网络地址之外,地址模式参数也需要被指定。目的地址模式可能是如下值之一(AF 地址模式被定义在“AF.h”中): typedef enum afAddrNotPresent = AddrNotPresent, afAddr16Bit = Addr16Bit, afAddrGroup = AddrGroup, afAddrBroadcast = AddrBroadcast afAddrMode_t; 地址模式参数是需要的,因为在 ZB 中,数据包能被点传输、多点传输或者广播传输。点传输被发送到单个设备,多点传输一定发送到一组设备,广播传输一般被发送到网络中的所有设备。如下是更详细的说明。 点到传输 (Unicast) 这是标准地址模式,被用于发送一个数据包到网络中单个已知地址的设备。这个addrMode 参数被设置为 Addr16Bit,目的网络地址在数据包中一同被发送。 间接寻址 数据包中的最终目的地址不识别的时候使用。该模式被 AddrNotPresent 设置,而且目的地址没有被指定。代替目的地址的是:一个存储在发送设备协议栈的“绑定表格”,该表格中有被绑定设备的地址。这个特性被调用是源于绑定。(看后面关于绑定部分)当被发送的信息包下载到协议栈时,从这个绑定表格中寻找使用的目的地址。然后该信息包被有规则的处理为点对点数据包。如果有多个(大于 1)目的地址在绑定表格中被发现,那么该数据包将被拷贝成对应的份数分别发送给他们。 在(ZigBee04)版本之前,在协调器中有一个存储绑定表格的选项。因此,发送设备发送数据包到这个协调器,然后协调器在它的绑定表格中查找最终的目的地址,对数据包进行在一次发送。该选项特性在协调器绑定被调用 广播传输 该模式在应用层想发送一个数据包到所有网络中的所有设备时被使用。该地址模式被 AddrBroadcast 被设置,目的地址被设置为下列值之一: NWK_BROADCAST_SHORTADDR_DEVALL (0xFFFF)-信息将被发送到网络中的所有设备(包括休眠的设备)。对于休眠的设备,这个信息将被保持在它的父节点,直到 该 休 眠 设 备 获 得 该 信 息 或 者 该 信 息 时 间 溢 出 ( 在 f8wConfig.cfg 中 的NWK_INDIRECT_MSG_TIMEOUT 选项)。NWK_BROADCAST_SHORTADDR_DEVRXON (0xFFFD) 该信息将被发送到网络中有接收器并处于 IDLE(RXONWHENIDLE)状态下的所有设备。也就是说,除了休眠模式设备的所有设备。 NWK_BROADCAST_SHORTADDR_DEVZCZR (0xFFFC) 该信息被发送到所有路由器(包括协调器) 。 组地址 该模式用于应用层想发送一个数据包到一个设备组的时候。该地址模式被afAddrGroup 设置这个组标志符。用 该 特 性 之 前,在 网 络 中 , 组 不 得 不 被 定 义 看 ZStack API 文 档 中 的 aps_AddGroup() 注意:组能与间接寻址一起结合使用。该目的地址在绑定表格中发现,可以作为点对点或一个组地址。也要注意广播地址可以当作是组被提前设置,一个简单的组寻址的特例。例子代码对于一个设备添加它自己到一个组标志符 1: aps_Group_t group; / Assign yourself to group 1 group.ID = 0x0001; 0 = 0; / This could be a human readable string aps_AddGroup( SAMPLEAPP_ENDPOINT, &group ); 重要设备地址 一个应用可以能想知道它自身和父节点的地址,用下面的函数可以得到设备的地址(被定义在 ZStack API 文档中): NLME_GetShortAddr() 返回该设备的 16 位网络地址 NLME_GetExtAddr() 返回该设备的 64 位扩展地址. 用下面的函数可以得到该设备的父节点的地址(被定义在 ZStack API 文档中)。注意该函数在协调器中不被涉及到,但是被设备父节点代替(MAC 协调器): NLME_GetCoordShortAddr() 返回本设备的父亲设备的16位网络地址NLME_GetCoordExtAddr() 返回本设备的父亲设备的64位扩展地址先介绍这两个概念:节点和地址。Z-Stack 指导 2 上节介绍了很大一部分 Z-Stack 的基础知识,这里接着忽悠。虽然说的不是很专业也不是很通俗,但是我尽力了,希望有人能看明白!本人英文水平有限,翻译的不好请谅解! 3、绑定 绑定是控制信息从一个应用层到另一个应用层流动的一种机制。在 zigbee06 版本中,绑定机制在所有的设备中被执行。 绑定允许应用层发送信息不需要带目的地址,APS 层确定目的地址从他的绑定表格中,然后在信息前端加上这个目的地址或组。 注意:在 zigbee1.0 版本中,所有绑定条目存储在协调器中。现在所有绑定条目存储在发送数据的设备中。 3.1 绑定一个绑定表格 有三种方式建立一个绑定表格: ZDO 绑定请求 - 一个试运转工具能告诉这个设备制作一个绑定报告。 ZDO 终端设备绑定请求 -一 个设备能告诉协调器他们想建立绑定表格报告。该协调器将使协调并在这两个设备上创建绑定表格条目 设备应用 在设备上的应用能建立或管理一个绑定表格 。 任何一个设备或应用能在网络中发送一个 ZDO 信息到另一个设备,用来建立一个绑定报告。这是调用绑定帮助并且它将建立一个绑定条目为发送设备。 3.1.1 ZDO 绑定请求 通过调用函数 ZDP_BindReq()(在ZDProfile.h)发送一个绑定请求。第一个参数(dstAddr)是绑定的源地址的短地址。 这之前应该确定允许绑定,在 ZDConfig.h 文件中有参数ZDO_BIND_UNBIND_REQUEST允许绑定。 能用同样的参数调用函数 ZDP_UnbindReq()移除绑定。 目标设备将调用函数 ZDApp_BindRsp()或 ZDApp_UnbindRsp(),反馈绑定或移除绑定的响应,返回其操作状态为 ZDP_SUCCESS, ZDP_TABLE_FULL 或 ZDP_NOT_SUPPORTED. 3.1.2 ZDO 终端设备绑定请求 该机制是用一个按钮按下或其他类似的动作来选择设备在指定时间内被绑定。在规定时间内,该终端设备绑定请求信息被收集到协调器,并创建一个基于模式(profile) ID 和串(cluster) ID 的规定的绑定表格条目。默认的终端设备绑定超时时间(APS_DEFAULT_MAXBINDING_TIME)为 16000(定义在 ZGlobals.h中),但是能被改变发送绑定请求 在所有的应用例子中有一个处理键盘事件的函数例如在 TransmitApp.c 文件中的 TransmitApp_HandleKeys()函数。在该函数中,调用了函数 ZDApp_SendEndDeviceBindReq()在 ZDApp.c 中,它将收集应用的终端设备的所有信息并调用函数 ZDP_EndDeviceBindReq() ZDProfile.c,发送一个绑定信息到协调器。或者,在 SampleLight 和 SampleSwitch 例子中,直接调用 ZDP_EndDeviceBindReq()函数就实现点亮/关闭灯的功能。 (严重注意:我在协议里面搜索TransmitApp_HandleKeys函数,根本搜索不到?,协议栈似乎没有包含TransmitApp.c函数进来)接收绑定请求 协调器将接收ZDP_IncomingData() 在 ZDProfile.c这些信息并分析处理ZDO_ProcessEndDeviceBindReq() 在 ZDObject.c这些信息并调用函数 ZDApp_EndDeviceBindReqCB() in ZDApp.c,它将调用ZDO_MatchEndDeviceBind() ZDObject.c处理这个请求, 当协调器接收到 2 个匹配终端色后备的绑定请求时,它将启动在绑定设备上创建源绑定条目的处理过程。该协调器有如下处理过程: 解除绑定 1. 发送一个 ZDO 解除绑定请求到第一个设备。终端设备绑定切换处理,所以解除绑定首先被发送到移除一个存在的绑定条目。 2. 等待 ZDO 解除绑定响应,如果响应状态为 ZDP_NO_ENTRY, 发送一个 ZDO 绑定请求,在源设备上制作一个绑定条目。如果该响应为 ZDP_SUCCESS, 为第一个设备继续到 move on to the cluster ID for the first device (the unbind removed the entry toggle)。 3. 等待 ZDO 绑定响应. When received, move on to the next cluster IDfor the first device。 4. 当第一个设备完成时,对第二个设备做同样的处理。 5. 当第二个设备完成时,发送 ZDO 终端设备绑定响应信息到第一个和第二个设备 3.1.3 设备应用绑定管理 在设备上其他进入绑定条目的方式是应用层管理绑定表格。 意思是说,应用层将调用下列函数进入和移除绑定表格条目:bindAddEntry() 增加绑定表格条目bindRemoveEntry() 从绑定表格中移除条目bindRemoveClusterIdFromList() 从一个存在的绑定表格项目中移除一个串 ID 。bindAddClusterIdToList()向一个已经存在的绑定记录中增加一个群IDbindRemoveDev()删除所有地址引用的记录bindRemoveSrcDev()删除所有源地址引用的记录bindUpdateAddr()将记录更新为另一个地址bindFindExisting()查找一个绑定表记录bindIsClusterIdInList()在表记录中检查一个已经存在的群IDbindNumBoundTo()拥有相同地址(源或者目的)的记录的个数bindNumEntries()表中记录的个数bindCapacity()最多允许的记录个数bindWriteNV()在NV中更新表3.2 配置源绑定 允许绑定源的编译选项 REFLECTOR 在 f8wConfig.cfg 文件中。在文件f8wConfig.cfg,中查看这两个绑定配置参数(DNWK_MAX_BINDING_ENTRIES & DMAX_BINDING_CLUSTER_IDS)。DNWK_MAX_BINDING_ENTRIES 绑定表格中最大的绑定实体数量参数;DMAX_BINDING_CLUSTER_IDS 是在每个绑定实体中最大的串ID 数量。 绑定表在静态RAM 中(未分配),因此绑定表中记录的个数,每条记录中群ID的个数都实际影响着使用 RAM 的数量。每一条绑定记录是 8 字节多(MAX_BINDING_CLUSTER_IDS * 2 字节)。除了绑定表使用的静态 RAM 的数量,绑定配置项目也影响地址管理器中的记录的个数。 4、路由 4.1 预览- overview 在 MESH 网络中,为了使分布的节点间能够很好的通信,路由是非常重要的一个环节。 在应用层上路由是完全透明的。一个简单的应用数据发送到任意设备,下至协议栈,协议栈将负责发现一个路由路线。这个方式,应用层是不知道该操作在多跳网络中完成的事实。 路由使ZB网络具有“自动复原”的特性。如果一个无线连接断了,路由功能将自动的发现一个新的路由路线,该路线是避开(绕过)坏了的那个连接节点。这就提高了无线网络的可靠性,这也是 ZigBee 关键特点之一。4.2 路由协议 ZigBee 执行的路由协议是基于 AODV(Ad hoc On demand Distance Vector)的路由协议。作为一个简单的应用-传感器网络,ZB 路由协议支持环境中的移动节点,连接失败和丢包功能。 当一个路由器接收到一个点对点信息包时,从他的应用或者从其他设备,NWK层将继续向前依照下面的进程。如果目的是路由器邻节点(包括它的子设备)之一,该信息包将直接传输到目的设备。另外的就是,路由器将检查它的路由表格,检查相应的信息包目的条目。如果在路由表格中有一个活跃的路由路线到该目的设备,那么该信息包将被转播到下一跳节点地址存储依照路由条目。如果没有活跃的条目发现,那么一个路由发现被启动并且该信息被缓存直到该过程完成。 ZigBee 终端设备路由 ZigBee终端设备不能执行任何路由功能。一个终端设备想发送一个信息包到任何设备都要向前到它的父设备,然后在由其父设备进行路由操作。类似的,任何设备想发送信息包到终端设备,都将发起一个路由发现操作,当然该操作都由终端设备的父设备响应。 注意:ZigBee地址分配方案使基于它的地址发起一个路由到任何目的成为可能。在 Z-Sstack,这个机制被用于万一正规的路由程序不能被启动,作为一个自动退却(一般情况是由于路由表格空间不够)。 z-stack 路由 在 z-stack,执行的路由是已经被优化的路由存储表格。一般情况,对于每一个目的设备路由表格条目是需要的。但是通过综合携带父节点所有条目的特定父节点的终端设备的所有条目,没有任何功能丢失的存储已经被优化。 ZB 路由器,包括协调器,执行如下路由功能 (i)路由发现和选择 (ii) 路由维护(iii) 4.2.1 路由发现和选择 路由发现 是网络设备协作发现和建立路由的一个过程。一个路由操作总是针对某个目的,通过任何一个路由器启动。该路由发现机制在源设备和目的设备间搜寻所有可能的路由并试图选择最好的路由路线。路由选择 通过选择最小消耗的路由路线。每个设备在连接到邻节点几乎保持不变的“连接消耗”。该连接消耗是接收信号的强度的一个典型功能。沿着路由路线加起所有的连接消耗,就是整个路由的“连接消耗”。路由算法试图选择这个路由最小的“路由消耗”。 路由请求 路由通过请求/响应信息包被发现。一个源设备为了一个目的地址,通过发送一个广播路由请求(RREQ)信息到它的邻设备请求一个路由。当一个节点接收到一个 RREQ 信息时,它将依次转播这个 RREQ 信息。但是在做这个之前,它更新 RREQ 信息的消耗域,通过增加连接消耗为了最后的连接。这样,RREQ 信息将携带向前传输的所有的连接消耗。这个重复过程直到 RREQ 到达这个目的设备。RREQ的一些复制可能经过不同的路径重复到达目的设备。该目的设备选择最好的 RREQ 信息并发送一个路由答复(RREP)返回到源设备。 路由响应 RREP 是沿着唯一的相反的路径返回到最初的请求节点。 作为 RREP 信息传播回源节点,中间的节点更新他们的路由表格,指出路由路线到目的设备。 一旦一个路由被创建,数据包能被发送。当一个节点丢失到它下一个节点的连通性时(发送数据包时,它不能接收一个 MAC 应答 ACK),这

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论