zigbee学习笔记Word文件下载.docx
- 文档编号:8185062
- 上传时间:2023-05-10
- 格式:DOCX
- 页数:14
- 大小:254.23KB
zigbee学习笔记Word文件下载.docx
《zigbee学习笔记Word文件下载.docx》由会员分享,可在线阅读,更多相关《zigbee学习笔记Word文件下载.docx(14页珍藏版)》请在冰点文库上搜索。
解决这几个问题这个项目就算完成了。
现在猜想:
一、开发一个新的应用应该做什么呢?
1获取模板标识符,簇标识符,设备标识符的相关信息,我要进一步了解这两个关键的概念。
2在1基础上我要能注册application,taskID,endpoint,以建立自己应用与操作系统交互。
这是一个关键的点。
二、必须弄懂传感器采集的原理,代码。
三、必须弄懂串口的原理,代码。
关键的概念
1、PAN标识符,PANID
2、模板标识符,profileID
3、簇标识符,clusterID8bit
4、节点,ieee地址(扩展地址)网络地址(短地址)64bit/16bit
5、端点,endpoint8bit
6、设备标识符,DeviceDescription16bit
7、应用任务ID,taskID
8、属性Attribute16bit
9、Taskeventsenvents16bit
申请到模板标识符后,可以为模板定义设备描述符、簇标识符、服务类型(KVP或MSG)属性(Attribute)。
模板三种类型:
私有、公开、公用。
属性
属性Attribute是一个反映物理数量或状态的数据值,比如开关值(On/Off)
温度值、百分比等。
群集
群集Cluster是包含一个或多个属性(attribute)的群组。
简单的说,群集就是属性的集合。
每个群集都被分配一个唯一的群集ID
且每个群集最多有65536个属性。
描述
设备描述DeviceDescription是指一个大型目标应用的一部分,包括一个或多个群集,并且指定群集是输入还是输出。
端点
端点EndPoint是协议栈应用层的入口,也可以理解应用对象(ApplicationObject)存在的地方,它是为实现一个设备描述而定义的一组群集。
每个ZigBee设备可以最多支持240这样的端点,这也意味着在每个设备上可以定义240个应用对象。
端点0被保留用于与ZDO接口而端点255被保留用于广播,端点241-254则被保留用于将来做扩展使用。
节点
节点Node也可以理解为一个容器,包含一组ZigBee设备,分享一个无线信道。
每个节点有且只有一个无线信道使用。
信息源:
1飞比论坛的资料:
1)葵花宝典
2)中文资料总索引
3)小峰笔记
4)奥特曼笔记
2TI官方网站查找板子相关手册。
重要信息:
ZigBee协议的体系结构
Z-Stack在开发ZigBee中起到的作用,使用Z-Stack开发ZigBee我们需要做什么?
如刚才的ZigBee协议体系图所示,ZigBee中包括很多的层和各个层之间的数据管理信息传输。
如此庞大的体系,如果人为手动编写程序将是一个很浩大的工程。
而Z-Stack则在其系统中为我们提供了详细的各个子模块的工作程序。
那么我们在开发ZigBee项目的时候,其实我们只需要添加三个文件:
主文件,主文件的头文件,操作系统接口文件。
一般情况下,用回只需额外添加三个文件就可以个一个项目FI,一个主文件,存放具体的任务事件处理函数(osal开头文件中的SampleApp_processEvent),一个主文件的头文件,一个操作系统接口文件,是专门存放任务处理函数数组(tasksArr[idx])的文件。
ZDO位于应用框架和应用支持子层之间,它满足zigBee协议栈所有应用操作的一般要求。
AF
ZigBee应用层框架是应用设备和ZigBee设备连接的环境。
在应用层框架中,应用对象发送和接收数据通过APSDE.SAP,而对应用对象的控制和管理则通过ZDO公用接口来实现。
APSDE.SAP提供的数据服务包括请求、确认、响应以及数据传输的指示信息。
有240个不同的应用对象能够被定义,每个终端节点的接口标识从l到240,还有两个附加的终端节点为了APSDE.SAP的使用。
标识0被用于ZDO的数据接口,255则用于所有应用对象的广播数据接口,而241.254予以保留。
使用APSDE-SAP提供的服务,应用层框架提供了应用对象的两种数据服务类型:
主值对服务(KeyValuePairservice,KVP)和通用信息服务(GenericMessageService,MSG)。
两者传输机制一样,不同的是MSG并不采用应用支持子层(APS)数据帧的内容,而是留给profile应用者自己去定义。
栈配置
栈参数的集合需要被配置为一定的值,连同这些值在一起被称之为栈配置。
ZigBee联盟定义了这些由栈配置组成栈参数。
网络中的所有设备必须遵循同样的栈配置。
为了促进互用性这个目标,ZigBee联盟为ZigBee2006规范定义了栈配置。
所有遵循此栈配置的设备可以在其他开发商开发的遵循同样栈配置的网络中。
栈配置是指对分布式应用的描述。
它根据应用必须处理的数据包和必须执行的操作来描述分布式应用。
使用描述符对配置文件进行描述,描述符仅仅是各种值的复杂结构。
此配置文件使ZigBee
设备可以互操作。
ZigBee
联盟已经定义了很多标准的配置文件,比如远程控制开关配置文件和光传感器配置文件等。
任何遵循某一标准配置文件的节点都可以与其他实现相同配置文件的节点进行互操作。
每个配置文件可以定义最多256
个群集,而且和我们在前面所看到的一样,每个群集可以最多有65536
个属性。
此灵活性允许节点有大量的属性(或I/O
点)。
AF层为各个用户自定义的应用对象提供了模板式的活动空间,为每个应用对象提供了KVM和MSG服务
AF中,应用程序可以通过APSDE-SAP发送、接收数据,通过ZDO公共接口实现应用对象的控制与管理。
APSDE-SAP提供的服务:
数据请求、确认、指示等原语。
请求:
用在对等实体间实现数据传输
确认原语报告数据请求原语执行的结果,而指示原语用来指示APS向目的应用对象的数据传送。
APSDE_SAP保留两个附加端点。
端点0作为ZDO的数据接口,端点255保留作为向所有应用对象的数据广播。
241-254保留。
为适应APSDE_SAP提供的数据服务,应用框架可以为应用对象提供两种数据服务:
价值匹配服务(KVP)和一般信息服务(MSG)。
通信方式:
1、直接:
关键在于短地址的获得。
无需绑定。
2、间接:
必须绑定。
绑定的方法:
1、间接绑定:
2、直接绑定(OTA):
可用第三方节点进行绑定。
3、直接绑定(通过串口):
用的较少
绑定条件:
ENDPOINT描述信息中ClusterID必须相等,且属性方向相反。
绑定后的通信方式:
通过endpoint和cluster信息进行通信。
通信部分消息帧有:
KVP与MSG两种方式,其中MSG方式的帧格式可以用户自定义。
MSG不对APS帧做任何假设,而将帧中的相应域保留,由模板开发者进行定义。
ZDO提供应用对象,模板和APS之间的接口,表示一类基本的功能。
它处在应用框架和APS之间,满足Zigbee协议中所有的应用操作的公共需求。
这些公共接口在应用框架中提供设备地址管理、发现、绑定和安全功能。
ZDO提供的五种管理:
1、发现管理:
设备发现、服务发现
2、网络管理
3、绑定管理:
可选
4、安全管理:
5、节点管理:
端点由应用程序开发者决定的,要保证结构简单,能够满足服务发现的需求。
应用程序被安置在端点,它有一个简单的描述符。
正是通过简单描述符和服务发现机制才能实现服务发现、绑定,功能互补的设备之间的信息交换更为容易。
需要注意:
服务发现是建立在模板标识符、输入簇标识符表、输出簇标识符表的基础上的。
绑定:
绑定是一种两个或者多个应用设备之间信息流的控制机制。
在最新版的Z-STACK版本中,它被称为资源绑定,所有的设备都必须执行绑定机制。
Profile是这样一种规范,它规定不同设备对消息帧的处理行为,使不同的设备之间可以通过发送命令、数据请求来实现互操作。
端点:
是一种网络通信中的数据通道,它是无线通信节点的一个通信部件,如果选择绑定方式实现节点的通信,那么可以直接面对端点操作,而不需要知道绑定两个节点的地址信息。
它是zigbee无线通信中的一个重要参数。
为什么zigbee控制器和效应器的简单描述符endpointID要相同
Endpoint说明了通信参数。
可以理解为类似端口号的东西,一定要匹配才能通信。
在一个网络中可以有若干个通道通信。
描述符:
Zigbee设备使用描述符数据结构描述其自身。
包含在这些描述符中的实际数据被定义在每个设备描述中。
Zigbee总共有五个描述符:
节点描述符、节点功率描述符、简单描述符、复杂描述符和用户描述符。
节点和节点功率描述符应用于整个节点。
其他描述符由节点中所定义的端点指定。
简单描述符:
简单描述符包含的信息指定了包括在节点中的每个端点,对存在于节点中的每个端点而言,它是强制的。
描述符是按照上面出现的顺序发送。
AF帧格式,这个帧是一个关键点。
这个帧的帧类型中可以选择KVP或MSG。
此后的事件中的事件数据域是KVP帧格式或MSG帧格式。
KVP命令帧的使用
CC2530内置温度传感器的设置方法:
(详情参见CC2530原理手册.pdf,网上也能找到,我改了手册名称。
)
ToconfigureaPort0pintobeusedasanADCinput,thecorrespondingbitintheAPCFGregistermustbesetto1.ThedefaultvaluesinthisregisterselectthePort0pinsasnon-ADCinput
由此可见,PO口可以通过把APCFGregister中相应位置1才将其配置成AD输入。
theoutputofanon-chiptemperaturesensorcanbeselectedas
aninputtotheADCfortemperaturemeasurements.Inordertodoso,theregistersTR0.ADCTMandATEST.ATESTCTRLmustbesetasdescribedintheregisterdescriptionsinSection12.2.10and
Section23.15.3(CC253x)
Channelnumbers12through15representGND(12),temperaturesensor(14),and
AVDD5/3(15),withchannel13beingreserved.ThesevaluesareusedintheADCCON2.SCHandADCCON3.SCHfields.
初始化
代码分析部分:
OSAL_Timers.c
osal_set_event
OSAL_Clock.c
osalTimerUpdate
OSAL.c
osalTimeUpdate()
osal_start_system()
ZMain.c(main)
关键函数的理解:
osal_start_system操作系统循环主体
osal_set_event设置事件标志位
osal_start_timerEx过一段事件设置相应的事件标志位
关键数据结构:
tasksEvents
taskArr
任务处理机制:
tasksEvents每位的数据结构,如tasksEvents[0]:
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
16位数据中的每一位都能代表一个事件。
工作流程:
事件(按键按下事件)发生,将tasksEvent中的相应位置1;
osal_start_system中轮查到事件发生(tasksEvent非零),然后通过events=(tasksArr[idx])(idx,events)来执行相应的任务。
下面介绍一下按键工作流程:
首先想,判断按键是否按下,哪个按键被按下的处理函数在哪呢?
由于按键是硬件,所以到HAL中看看,在里面的Target里面有hal_key.c文件,到里面寻找轮查函数。
显然voidHalKeyInit(void)这个函数里面没有,往下找,在voidHalKeyConfig(boolinterruptEnable,halKeyCBack_tcback)这个函数中我们发现了惊喜:
osal_start_timerEx(Hal_TaskID,HAL_KEY_EVENT,HAL_KEY_POLLING_VALUE);
从函数的结构上我们可以看出每隔HAL_KEY_POLLING_VALUE时间,置一个HAL_KEY_EVENT事件。
问题来了,一、这个函数是否会得到执行,一般来说一定会的,二、这个函数是否通过置一个键盘事件让后面的处理函数扫描键盘,确定是否有按键被按下。
先解决第一个问题,通过搜索HalKeyConfig,我们能发现这个函数在Oboard.c的voidInitBoard(bytelevel)这个函数中得到执行,也就是初始化中执行。
由此我们可以得出,在初始化的时候置了一个HAL_KEY_EVENT事件。
第二个问题,就是在对HAL_KEY_EVENT事件进行处理的过程中是否进行了键盘扫描,判断是否有按键被按下。
至此,有一个问题出来了,HAL_KEY_EVENT在哪得到处理的?
通过搜索HAL_KEY_EVENT,我们找到,这个事件在hal_drivers.c的uint16Hal_ProcessEvent(uint8task_id,uint16events)这个函数中得到处理。
找到HAL_KEY_EVENT这个函数的到处理的位置,我们上面的问题得到解决,回到我们的第二个问题。
看看在对HAL_KEY_EVENT事件进行处理的过程中是否进行了键盘扫描,判断是否有按键被按下。
我们从找到的对HAL_KEY_EVENT事件进行处理的代码中有下面关键的语句:
if(events&
HAL_KEY_EVENT)
{
#if(definedHAL_KEY)&
&
(HAL_KEY==TRUE)
/*Checkforkeys*/这个注释似乎告诉我们按键检测在这里,我们还等什么,看吧。
HalKeyPoll();
/*ifinterruptdisabled,donextpolling*/这个注释似乎告诉我们如果按键不是已中断方式进行触发,而是轮查方式,则在100ms后将置一个HAL_KEY_EVENT事件。
想必你也可以看出,每隔100ms,这个函数将得到一次执行。
随之上面的HalKeyPoll()也一起执行。
if(!
Hal_KeyIntEnable)
osal_start_timerEx(Hal_TaskID,HAL_KEY_EVENT,100);
}
先看红字部分
找到HalKeyPoll(),我们从上面的注释中似乎感到,我们上面的第二个问题得到了解决。
从具体代码中我们看到,这个函数在做键盘扫描工作,判断是否有相关的按键被按下,如果有按键按下,则调相应的程序进行处理。
至此第二个问题得到解决。
在此我们做一下小结:
这是什么样的过程呢?
通过初始化置了一个HAL_KEY_EVENT事件,通过OSAL的分配机制找到相应的处理函数对HAL_KEY_EVENT进行了处理。
处理的过程就是判断是否有按键被按下,哪个被按下,并交给相应的程序处理。
由此呢,我们也可以看出HAL_KEY_EVENT具体是一个什么事件了。
在对HAL_KEY_EVENT进行处理的过程中,我们说到,通过判断哪个键值被按下,交给相应的程序处理(上面红字),这是如何做到的呢?
我们继续看HalKeyPoll中的代码,在最后的部分我们又发现了惊喜:
/*InvokeCallbackifnewkeysweredepressed*/如果有按键按下,回调函数。
if(keys&
(pHalKeyProcessFunction))
(pHalKeyProcessFunction)(keys,HAL_KEY_STATE_NORMAL);
我们感到,(pHalKeyProcessFunction)(keys,HAL_KEY_STATE_NORMAL)这个函数将实现对不同键值的不同处理。
通过搜索pHalKeyProcessFunction,我们发现,这是一个回调函数,在hal_key.c的voidHalKeyInit(void)中得到初始化,代码如下:
/*Initializecallbackfunction*/
pHalKeyProcessFunction=NULL;
但是这个不是我们想要的,我们想知道这个回调函数到底指向了哪。
所以我们继续寻找。
我们发现在voidHalKeyConfig(boolinterruptEnable,halKeyCBack_tcback)函数中,有以下语句:
pHalKeyProcessFunction=cback;
但是cback指向哪呢?
我们看到cback是函数的形参,所以我们只要找到调用HalKeyConfig的地方,就可以找到cback。
搜索HalKeyConfig,我们在Onboard.c的voidInitBoard(bytelevel)中发现以下语句:
HalKeyConfig(OnboardKeyIntEnable,OnBoard_KeyCallback);
说明什么呢?
回调函数pHalKeyProcessFunction最后调用的是OnBoard_KeyCallback,在Onboard.c中我们找到voidOnBoard_KeyCallback(uint8keys,uint8state),至此我们可能会感到些什么,如果没有发现我复制个东西到这里对比下看看:
(pHalKeyProcessFunction)(keys,HAL_KEY_STATE_NORMAL);
发现了吧!
在调用这个函数对相应的按键值做出响应时,实际上调用的是voidOnBoard_KeyCallback(uint8keys,uint8state)。
那么下面我们就看一下这个函数吧。
在这个函数中,我们看到了一个函数OnBoard_SendKeys(keys,shift)。
我们马上进行追踪,发现了osal_msg_send(registeredKeysTaskID,(uint8*)msgPtr)这个关键的函数,想必大家对这个强大的函数有所了解,它的作用就是给相应的taskid发送一个消息(哪个按键被按下了)。
如果我们感到好奇,可以追踪这个函数,在这个函数中我们发现下面两个主要语句:
//queuemessage
osal_msg_enqueue(&
osal_qHead,msg_ptr);
//Signalthetaskthatamessageiswaiting
osal_set_event(destination_task,SYS_EVENT_MSG);
什么意思呢?
将消息加到消息队列中;
然后通知相应的任务对其消息进行处理。
也就是用下面这条语句把相应的任务(destination_task)对应的事件(SYS_EVENT_MSG)置1。
在上面的红字部分我们留下了一个问题,这个相应的taskid到底是谁呢?
从OnBoard.c中的osal_msg_send(registeredKeysTaskID,(uint8*)msgPtr)这个函数,我们可以知道,是将消息发给了registeredKeysTaskID这个任务进行处理,我们搜索它的定义,出现了staticbyteregisteredKeysTaskID=NO_TASK_ID,很遗憾没有解决,但是我们知道它一定被赋其他值了,所以我们要进行全工程搜索。
我们发现,在OnBoard.c的byteRegisterForKeys(bytetask_id)这个函数中我们看到下面语句:
registeredKeysTaskID=task_id;
很显然,在注册按键任务的时候对其进行了赋值,但是我们从这里还不能看到,我们继续搜索RegisterForKeys,在sapi.c的voidSAPI_Init(bytetask_id)函数中我们看到以下语句:
RegisterForKeys(sapi_TaskID);
呵呵,是不是应该一阵狂喜?
到此,我们能看到什么呢?
osal_msg_send(registeredKeysTaskID,(uint8*)msgPtr)这个函数是将一个按键信息发送给了应用层进行处理。
也就是说,当判断有按键被按下时,我们将哪个按键被按下的信息发送给了应用层任务进行处理。
当然我们在应用层可以找到相应的处理函数对相应的按键值进行处理。
至此我们可以对按键工作流程进行总结了:
OSAL分配给相应的任务处理
相应函数处理,并在此过程中扫描是否有按下,如果有将按键值给相应函数处理,并且在100um后设置一个HAL_KEY_EVENT
初始化发出一个HAL_KEY_EVENT事件
1初始化的时候出发一个HAL_KEY_EVENT,在相应程序对这个事件进行处理的过程中,进行了键盘扫描,确定是否有按键按下,如果有按键按下,回调相应的处理函数。
并且有设置了一个HAL_KEY_EVENT事件在100后处理,这是什么过程?
呵呵,对比上边的工作流程图,是不是很兴
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- zigbee 学习 笔记