国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
ZigBee四種綁定方式在TI Z-Stack協(xié)議棧中應(yīng)用

KuangJunBin:本文是作者根據(jù)TI Z-Stack開發(fā)文檔,ZigBee Specification-2007,《Zigbee Wireless Networking》等英文資料整合和翻譯而成,采用中英雙語對照方便讀者理解,文中翻譯不當之處,望廣大同行不吝賜教。推廣ZigBee技術(shù),提高國內(nèi)電子行業(yè)的國際影響力,是我們無線通訊工程師的愿景。本文歡迎轉(zhuǎn)載,請保留作者信息和出處,作為支持我繼續(xù)努力前行的動力,謝謝!

ZigBee2006版本中規(guī)定,在全部節(jié)點中實現(xiàn)綁定機制,并將其稱為源綁定。綁定機制允許一個應(yīng)用服務(wù)在不知道目標地址的情況下向?qū)Ψ剑ǖ膽?yīng)用服務(wù))發(fā)送數(shù)據(jù)包。發(fā)送時使用的目標地址將由應(yīng)用支持子層從綁定表中自動獲得,從而能使消息順利被目標節(jié)點的一個或多個應(yīng)用服務(wù),乃至分組接收。

Binding Table
綁定表

1.   綁定表存放的位置是內(nèi)存中預(yù)先定義的塊,如果編譯選項NV_RESTORE被激活,也能保存在Flash里。
2.   綁定表放置在源節(jié)點(需要激活編譯選項REFLECTOR)。
3.   綁定表的條目把需要發(fā)送的消息映射到它們的目標地址上。
4.   綁定表中每個條目包括以下內(nèi)容:
5.   綁定表條目結(jié)構(gòu)體的定義

typedef struct
{
uint16 srcIdx; //源地址索引
uint8 srcEP; //源端點
uint8 dstGroupMode; //指定尋址模式
uint16 dstIdx; //目標地址索引或者分組號
uint8 dstEP; //目標端點
uint8 numClusterIds; //在簇標識符表中簇標識符的個數(shù)
uint16 clusterIdList[MAX_BINDING_CLUSTER_IDS]; //簇標識符表
}BindingEntry_t;


Simple Description --- How to bind devices
概述---怎樣綁定節(jié)點
綁定指的是兩個節(jié)點在應(yīng)用層上建立起來的一條邏輯鏈路。在同一個節(jié)點上可以建立多個綁定服務(wù),分別對應(yīng)不同種類的數(shù)據(jù)包。此外,綁定也允許有多個目標節(jié)點(一對多綁定)。

舉個例子,在一個燈光網(wǎng)絡(luò)中,有多個開關(guān)和燈光設(shè)備,每一個開關(guān)可以控制一個或以上的燈光設(shè)備。在這種情況下,需要在每個開關(guān)中建立綁定服務(wù)。這使得開關(guān)中的應(yīng)用服務(wù)在不知道燈光設(shè)備確切的目標地址時,可以順利地向燈光設(shè)備發(fā)送數(shù)據(jù)包。

一旦在源節(jié)點上建立了綁定,其應(yīng)用服務(wù)即可向目標節(jié)點發(fā)送數(shù)據(jù),而不需指定目標地址了(調(diào)用zb_SendDataRequest(),目標地址可用一個無效值0xFFFE代替)。這樣,協(xié)議棧將會根據(jù)數(shù)據(jù)包的命令標識符,通過自身的綁定表查找到所對應(yīng)的目標設(shè)備地址。

在綁定表的條目中,有時會有多個目標端點。這使得協(xié)議棧自動地重復(fù)發(fā)送數(shù)據(jù)包到綁定表指定的各個目標地址。同時,如果在編譯目標文件時,編譯選項NV_RESTORE被打開,協(xié)議棧將會把綁定條目保存在非易失性存儲器里。因此當意外重啟(或者節(jié)點電池耗盡需要更換)等突發(fā)情況的發(fā)生時,節(jié)點能自動恢復(fù)到掉電前的工作狀態(tài),而不需要用戶重新設(shè)置綁定服務(wù)。

    配置設(shè)備綁定服務(wù),有兩種機制可供選擇。如果目標設(shè)備的擴展地址(64位地址)已知,可通過調(diào)用zb_BindDeviceRequest()建立綁定條目。如果目標設(shè)備的擴展地址未知,可實施一個“按鍵”策略實現(xiàn)綁定。這時,目標設(shè)備將首先進入一個允許綁定的狀態(tài),并通過zb_AllowBindResponse()對配對請求作出響應(yīng)。然后,在源節(jié)點中執(zhí)行zb_BindDeviceRequest()(目標地址設(shè)為無效)可實現(xiàn)綁定。

    此外,使用節(jié)點外部的委托工具(通常是協(xié)調(diào)器)也可實現(xiàn)綁定服務(wù)。請注意,綁定服務(wù)只能在“互補”設(shè)備之間建立。那就是,只有分別在兩個節(jié)點的簡單描述結(jié)構(gòu)體(simple descriptor structure)中,同時注冊了相同的命令標識符(command_id)并且方向相反(一個屬于輸出指令“output”,另一個屬于輸入指令“input”),才能成功建立綁定。

There are 4 ways to build a binding table:
建立一個綁定表格有四種方法可供選擇:

第一種方法:自動綁定

使用函數(shù):ZDP_MatchDescReq()
一、    負責發(fā)送消息的設(shè)備在網(wǎng)絡(luò)上廣播帶有如下參數(shù)的“個人公告”(Personal Advertisement):
(1) 地址,配置文件標識符,簇集合列表;
(2)描述符匹配請求- ZDP_MatchDescReq()。
二、    匹配的設(shè)備會作出響應(yīng)。
三、    由ZDO處理和驗證響應(yīng)
四、    負責發(fā)送消息的設(shè)備建立綁定表并保存綁定記錄。
五、    這種方法有時也稱“服務(wù)發(fā)現(xiàn)”,“自動找尋”或者“自動匹配”。

第二種方法:輔助綁定

    使用函數(shù):ZDP_BindReq()

ZigBee設(shè)備對象綁定請求-一種告訴目標設(shè)備建立綁定記錄的委托工具,也稱輔助綁定。

任何一個設(shè)備或應(yīng)用服務(wù),都能通過無線信道向網(wǎng)絡(luò)上的另一個設(shè)備發(fā)送一個ZDO消息,幫助其建立一個綁定記錄。這稱為輔助綁定,在消息發(fā)向的設(shè)備上會建立一個綁定條目。

委托綁定的申請:

任一個應(yīng)用服務(wù),通過ZDP_BindReq()[defined in ZDProfile.h] 向綁定記錄所需要的應(yīng)用服務(wù)入口提供參數(shù)(地址和端點)以及簇標識號(cluster ID),即可啟動委托綁定的申請。第一個參數(shù)(消息發(fā)送目標地址)是綁定源節(jié)點的短地址(即保存綁定記錄的節(jié)點地址,這是因為ZDP需委托應(yīng)用框架AF輔助實現(xiàn)綁定,如果節(jié)點本身是REFLECTOR,并且希望保存綁定記錄,則此消息發(fā)送的目標地址就是本地的AF,這與目標節(jié)點的地址DestinationAddr of Receiving device不同)。

注意事項:

確保[ZDConfig.h]中ZDO_BIND_UNBIND_REQUEST特性已經(jīng)打開!

你可以通過ZDP_UnbindReq()(使用相同參數(shù))來移除綁定記錄。

被請求輔助綁定的目標設(shè)備會返回的ZDO申請綁定或者解除綁定的應(yīng)答消息。此ZDO消息會被解析并通過調(diào)用ZDApp_BindRsp()或ZDApp_UnbindRsp()告知ZDApp.c此次請求的結(jié)果。

對于申請綁定的應(yīng)答消息,從協(xié)調(diào)器返回的狀態(tài)可能有ZDP_SUCCESS,ZDP_TABLE_FULL or ZDP_NOT_SUPPORTED。

對于解除綁定的應(yīng)答消息,從協(xié)調(diào)器返回的狀態(tài)可能有ZDP_SUCCESS,ZDP_NO_ENTRY or ZDP_NOT_SUPPORTED。

綁定是由外部的設(shè)備發(fā)起(“外部”的意思是發(fā)起綁定的不是綁定的對象之一)。

外部設(shè)備應(yīng)用程序以兩個應(yīng)用服務(wù)(地址和端點)和簇標識符作為參數(shù)調(diào)用ZDP_BindReq ()發(fā)起綁定。第一個參數(shù)就是綁定記錄保存的設(shè)備地址。

確保編譯選項REFLECTOR已經(jīng)打開!


函數(shù)解析:
ZDP_BindReq()實際上是調(diào)用ZDP_BindUnbindReq()的一個宏。這一調(diào)用會產(chǎn)生并發(fā)送一個綁定的請求,使得ZigBee協(xié)調(diào)器根據(jù)簇標識號clusterID對相應(yīng)的應(yīng)用服務(wù)實施綁定。

函數(shù)原型:
afStatus_t ZDP_BindReq(zAddrType_t*dstAddr,byte*SourceAddr,byte SrcEPIntf,byte ClusterID,byte*DestinationAddr,byte DstEPIntf,byte SecuritySuite);

參數(shù)細節(jié):
DstAddr-消息發(fā)送地址 (負責綁定的設(shè)備地址)
SourceAddr–源節(jié)點的64位IEEE地址
SrcEPIntf–源節(jié)點應(yīng)用服務(wù)的端點
ClusterID–需要綁定的簇標識符
DestinationAddr–目標節(jié)點的64位IEEE地址
DstEPIntf–目標節(jié)點應(yīng)用服務(wù)的端點
SecuritySuite-安全機制模式
返回值:afStatus_t–此函數(shù)需要借助AF發(fā)送(AF_DataRequest())生成的消息,因此返回值是AF狀態(tài)值。

第三種方法:集中式綁定

使用函數(shù):ZDApp_SendEndDeviceBindReq()

ZigBee設(shè)備對象終端節(jié)點綁定請求-兩個設(shè)備可向協(xié)調(diào)器告知他們想建立一個綁定表記錄。協(xié)調(diào)器通過安排配對并分別在這兩個設(shè)備上建立綁定表條目,也稱集中式綁定。

    這一機制規(guī)定在指定的時限內(nèi),通過按鍵或者其他類似動作對指定的設(shè)備實施綁定。在規(guī)定的時限內(nèi),協(xié)調(diào)器負責收集終端設(shè)備綁定請求消息,然后根據(jù)相同的配置文件標識號和簇標識號建立相應(yīng)的綁定表格條目。默認的終端節(jié)點綁定時限(APS_DEFAULT_MAXBINDING_TIME)是16秒(在nwk_globals.h中定義),若要修改可在f8wConfig.cfg中新增數(shù)值。

    所有例子的應(yīng)用服務(wù)中都有一個響應(yīng)按鍵事件的函數(shù)(例如,TransmitApp.c中的TransmitApp_HandleKeys())。這一響應(yīng)函數(shù)調(diào)用ZDApp_SendEndDeviceBindReq()[在 ZDApp.c中]收集該應(yīng)用服務(wù)端點的所有信息,然后再調(diào)用ZDP_EndDeviceBindReq()[在ZDProfile.c中]把信息發(fā)送給協(xié)調(diào)器。或者,像SampleLight和SampleSwitch例程中,按鍵后直接調(diào)用ZDP_EndDeviceBindReq(),僅把與開關(guān)燈函數(shù)相關(guān)的簇標識號發(fā)送出去。

這一消息將會被協(xié)調(diào)器接收[ZDP_IncomingData()in ZDProfile.c]和解析[ZDO_ProcessEndDeviceBindReq()in ZDObject.c],然后讓回調(diào)函數(shù)ZDApp_EndDeviceBindReqCB()[in ZDApp.c]調(diào)用ZDO_MatchEndDeviceBind()[ZDObject.c]處理這一請求。

    當協(xié)調(diào)器接收到第一個綁定請求時,他會在一定的時限內(nèi)保留這一請求并等待第二個請求的出現(xiàn)。(默認的最長時間間隔是16秒)。

    一旦協(xié)調(diào)器接收到兩個需要匹配的終端設(shè)備綁定請求時,它就會啟動綁定過程,為發(fā)出請求的設(shè)備建立源綁定條目。假設(shè)在ZDO終端設(shè)備綁定請求中找到匹配,協(xié)調(diào)器將采取以下步驟:

1.     協(xié)調(diào)器發(fā)送一個ZDO解除綁定請求給第一個設(shè)備。終端設(shè)備綁定是一個切換過程,所以解除綁定請求需要發(fā)送給第一個設(shè)備,以便移除一個已有的綁定條目。
2.     等待ZDO解除綁定的應(yīng)答,如果返回的狀態(tài)是ZDP_NO_ENTRY,協(xié)調(diào)器可以發(fā)送一個ZDO綁定請求,在源設(shè)備(ZDP_EndDeviceBindReq()第一個參數(shù)指定的地址)中建立綁定條目。假如此時返回的狀態(tài)是ZDP_SUCCESS,可繼續(xù)處理第一個設(shè)備的簇標識符(解除綁定指令已經(jīng)移除了綁定條目,即已經(jīng)切換完成)。
3.     等待ZDO綁定應(yīng)答。收到以后,繼續(xù)處理第一個設(shè)備的下一個簇標識符。
4.     等第一個設(shè)備完成了以后,在第二個設(shè)備上實行同樣的過程。
5.     等第二個設(shè)備也完成了,協(xié)調(diào)器向兩個設(shè)備發(fā)送ZDO終端設(shè)備綁定應(yīng)答消息。

注意打開編譯選項:REFLECTOR和ZDO_COORDINATOR


ZDApp_SendEndDeviceBindReq()

優(yōu)點:

1.     綁定信息保存在網(wǎng)絡(luò)反射設(shè)備(例如協(xié)調(diào)器、路由器)中,可以節(jié)省目標設(shè)備的內(nèi)存空間。
2.     網(wǎng)絡(luò)反射設(shè)備總是處于監(jiān)聽網(wǎng)絡(luò)的狀態(tài)。所以,如果其中一個被綁定的節(jié)點廣播網(wǎng)絡(luò)地址改變的消息,網(wǎng)絡(luò)反射設(shè)備就可以馬上更新相應(yīng)的綁定表條目。這樣,其他被綁定的節(jié)點即使處于休眠狀態(tài)(沒有收到該節(jié)點網(wǎng)絡(luò)地址改變的消息),隨后向該節(jié)點(網(wǎng)絡(luò)地址已改變)發(fā)送的消息,(在)網(wǎng)絡(luò)反射設(shè)備(協(xié)助下)仍能準確定位。

缺點:
1.     一個與多個設(shè)備綁定的節(jié)點不能只向一個或若干個配對的設(shè)備發(fā)送消息。網(wǎng)絡(luò)反射設(shè)備會向全部已綁定的設(shè)備本別發(fā)送單播消息。
2.     發(fā)送消息的設(shè)備無法收到目標設(shè)備接收情況的通告。(沒有像AF_ACK_REQUEST標志位那樣返回接收情況的功能?。?br style="LINE-HEIGHT: 28px">3.     所有的消息必須經(jīng)過網(wǎng)絡(luò)反射設(shè)備傳輸,降低了網(wǎng)絡(luò)的帶寬。

進一步分析:

    與六個設(shè)備綁定的某個設(shè)備,向網(wǎng)絡(luò)反射器發(fā)送一個消息后,會導(dǎo)致反射器發(fā)送六個單播消息。假設(shè)一個網(wǎng)絡(luò)被分成兩個相等的地理區(qū)域A和B,網(wǎng)絡(luò)反射器在兩區(qū)之間的中央。如果發(fā)送消息的設(shè)備在A區(qū)的深處,接收消息的(六個)設(shè)備在B區(qū)的深處,那么每次通過綁定(向反射器)發(fā)送一個消息,A區(qū)的網(wǎng)絡(luò)流量將會是對六個接收設(shè)備分別發(fā)送消息時的六分之一。(這是優(yōu)點?。┑绻l(fā)送和接收的設(shè)備都鄰近在一個區(qū)的深處(假設(shè)離反射器很遠),那么(其中一個設(shè)備通過反射器的綁定功能想其他設(shè)備發(fā)送一個消息)該區(qū)的網(wǎng)絡(luò)流量將會是對六個接收設(shè)備分別發(fā)送單跳消息的許多倍。(這是缺點!)

第四種方法:應(yīng)用API函數(shù)綁定

設(shè)備的應(yīng)用服務(wù)-設(shè)備上的一個應(yīng)用服務(wù)可以建立或者維護一個綁定表。進入設(shè)備上綁定條目的另一種方法是由應(yīng)用服務(wù)本身去管理綁定表。

    這意味著應(yīng)用服務(wù)通過調(diào)用以下的綁定表管理函數(shù),可以在本地進入或者移除綁定表的條目。

管理綁定表使用的API:

bindAddEntry()–綁定表中加條目

bindRemoveEntry()–綁定表中移除條目

bindRemoveClusterIdFromList()–從一個已有的綁定表條目中移除一個簇標識符

bindAddClusterIdToList()–在一個已有的綁定表條目中加入一個簇標識符

bindRemoveDev()–移除某目標地址的所有條目

bindRemoveSrcDev()–移除某源地址的所有條目(協(xié)調(diào)器中)

bindUpdateAddr()–更新條目到新的地址

bindFindExisting()–查找一個綁定條目

bindIsClusterIDinList()–在綁定條目中查找一個已有的簇標識符

bindNumBoundTo()–某一地址(源地址或目標地址)綁定條目的個數(shù)

bindNumOfEntries()–綁定表條目的個數(shù)

bindCapacity()–允許的最大綁定條目數(shù)

BindWriteNV()–在NV中保存新的綁定表


Which Binding Method To Use?

我們應(yīng)該選擇哪一種綁定方式?

Automatic自動綁定的特點:

+no user interaction required無需用戶交互

+no tool cost               沒有工具成本

-development time knowledge開發(fā)時,需要知道詳細應(yīng)用?

-non-configurable            不可靈活配置

Assisted輔助綁定的特點:

+install-time decisions(site-specific knowledge) 安裝時決定(具體現(xiàn)場知識)

+analysis,maintenance,modification,visualization分析,維修,改裝,可視化

can be under installers control可用安裝程序控制

-cost of tool工具成本

Centralized集中綁定的特點:

+allows user to decide允許用戶決定

+cost of tool minimal成本最小的工具

-few,if any,configurable parameters可配置參數(shù)很少

-requires a user interface on each device用戶需要介入每個設(shè)備

Application應(yīng)用API函數(shù)綁定的特點:

+maximum flexibility最大的靈活性

-you must write all the code你必須編寫所有代碼


來自TI E2E社區(qū)的進一步討論:

一、“終端設(shè)備綁定請求”這一命名有誤導(dǎo)的嫌疑。這一請求不僅僅適用于終端設(shè)備,而且適用于對希望在協(xié)調(diào)器上綁定的兩個設(shè)備中匹配的簇實施綁定。一旦這個函數(shù)被調(diào)用,將假設(shè)REFLECTOR這一編譯選項在所有希望使用這一服務(wù)的節(jié)點中都已經(jīng)打開。具體操作如下:

(1)       (Bind Req) Device 1 --> Coordinator <--- Device 2 (Bind Req)

協(xié)調(diào)器首先找出包含在綁定請求中的簇,然后對比每一設(shè)備的IEEE地址,如果簇可以匹配,而且這幾個設(shè)備沒有已經(jīng)存在的綁定表,那他將發(fā)送一個綁定應(yīng)答給每一個設(shè)備。

(2)      Device 1 <--- NWK Addr Req ------ Coordinator ------- NWK addr Req ----> Device 2

(3)       Device 1 ----> NWK Addr Rsp ---> Coordinator <---- NWK addr Rsp <--- Device 2

(4)       Device 1 <----- Bind Rsp <----- Coordinator -----> Bind Rsp ----> Device 2

二、“描述符匹配”為源設(shè)備的服務(wù)發(fā)現(xiàn)提供了一種靈巧的方法。下面是具體的操作,這一過程并沒有通過協(xié)調(diào)器。

(1)       Device 1 ----> Match Descriptor request (broadcast or unicast) Device 2

(2)       Device 1 <---- Match Descriptor response (if clusters, application profile id match) that includes src endpoint, src address <---- Device 2

1號設(shè)備需要維護一個端點和地址的記錄。

許多應(yīng)用服務(wù)最終都會使用第二種方法。

3、綁定 
       綁定是控制信息從一個應(yīng)用層到另一個應(yīng)用層流動的一種機制。在 zigbee06 版本中,綁定機制在所有的設(shè)備中被執(zhí)行。 綁定允許應(yīng)用層發(fā)送信息不需要帶目的地址,APS 層確定目的地址從他的綁定表格中,然后在信息前端加上這個目的地址或組。 注意:在 zigbee1.0 版本中,所有綁定條目存儲在協(xié)調(diào)器中?,F(xiàn)在所有綁定條目存儲在發(fā)送數(shù)據(jù)的設(shè)備中。 
3.1 綁定一個綁定表格 
        有三種方式建立一個綁定表格: 
ZDO 綁定請求 -- 一個試運轉(zhuǎn)工具能告訴這個設(shè)備制作一個綁定報告。 
ZDO 終端設(shè)備綁定請求 --一 個設(shè)備能告訴協(xié)調(diào)器他們想建立綁定表格報告。該協(xié)調(diào)器將使協(xié)調(diào)并在這兩個設(shè)備上創(chuàng)建綁定表格條目 
設(shè)備應(yīng)用 – 在設(shè)備上的應(yīng)用能建立或管理一個綁定表格 。 
        任何一個設(shè)備或應(yīng)用能在網(wǎng)絡(luò)中發(fā)送一個 ZDO 信息到另一個設(shè)備,用來建立一個綁定報告。這是調(diào)用綁定幫助并且它將建立一個綁定條目為發(fā)送設(shè)備。 
3.1.1 ZDO 綁定請求 
       通過調(diào)用函數(shù) ZDP_BindReq()(在ZDProfile.h)發(fā)送一個綁定請求。第一個參數(shù)(dstAddr)是綁定的源地址的短地址。 這之前應(yīng)該確定允許綁定,在 ZDConfig.h 文件中有參數(shù)[ZDO_BIND_UNBIND_REQUEST]允許綁定。 能用同樣的參數(shù)調(diào)用函數(shù) ZDP_UnbindReq()移除綁定。 目標設(shè)備將調(diào)用函數(shù) ZDApp_BindRsp()或 ZDApp_UnbindRsp(),反饋綁定或移除綁定的響應(yīng),返回其操作狀態(tài)為 ZDP_SUCCESS, ZDP_TABLE_FULL 或 ZDP_NOT_SUPPORTED. 
3.1.2 ZDO 終端設(shè)備綁定請求 
      該機制是用一個按鈕按下或其他類似的動作來選擇設(shè)備在指定時間內(nèi)被綁定。在規(guī)定時間內(nèi),該終端設(shè)備綁定請求信息被收集到協(xié)調(diào)器,并創(chuàng)建一個基于模式(profile) ID 和串(cluster) ID 的規(guī)定的綁定表格條目。默認的終端設(shè)備綁定超時時間(APS_DEFAULT_MAXBINDING_TIME)為 16000(定義在 ZGlobals.h中),但是能被改變

發(fā)送綁定請求

       在所有的應(yīng)用例子中有一個處理鍵盤事件的函數(shù)[例如在 TransmitApp.c 文件中的 TransmitApp_HandleKeys()函數(shù)]。在該函數(shù)中,調(diào)用了函數(shù) ZDApp_SendEndDeviceBindReq()[在 ZDApp.c 中],它將收集應(yīng)用的終端設(shè)備的所有信息并調(diào)用函數(shù) ZDP_EndDeviceBindReq() [ZDProfile.c],發(fā)送一個綁定信息到協(xié)調(diào)器?;蛘?,在 SampleLight 和 SampleSwitch 例子中,直接調(diào)用 ZDP_EndDeviceBindReq()函數(shù)就實現(xiàn)點亮/關(guān)閉燈的功能。 (嚴重注意:我在協(xié)議里面搜索TransmitApp_HandleKeys函數(shù),根本搜索不到?,協(xié)議棧似乎沒有包含TransmitApp.c函數(shù)進來)
接收綁定請求 
       協(xié)調(diào)器將接收[ZDP_IncomingData() 在 ZDProfile.c]這些信息并分析處理[ZDO_ProcessEndDeviceBindReq() 在 ZDObject.c]這些信息并調(diào)用函數(shù) ZDApp_EndDeviceBindReqCB() [in ZDApp.c],它將調(diào)用ZDO_MatchEndDeviceBind() [ZDObject.c]處理這個請求, 當協(xié)調(diào)器接收到 2 個匹配終端色后備的綁定請求時,它將啟動在綁定設(shè)備上創(chuàng)建源綁定條目的處理過程。該協(xié)調(diào)器有如下處理過程: 
解除綁定 
      1. 發(fā)送一個 ZDO 解除綁定請求到第一個設(shè)備。終端設(shè)備綁定切換處理,所以解除綁定首先被發(fā)送到移除一個存在的綁定條目。 
      2. 等待 ZDO 解除綁定響應(yīng),如果響應(yīng)狀態(tài)為 ZDP_NO_ENTRY, 發(fā)送一個 ZDO 綁定請求,在源設(shè)備上制作一個綁定條目。如果該響應(yīng)為 ZDP_SUCCESS, 為第一個設(shè)備繼續(xù)到 move on to the cluster ID for the first device (the unbind removed the entry – toggle)。
       3. 等待 ZDO 綁定響應(yīng). When received, move on to the next cluster IDfor the first device。
       4. 當?shù)谝粋€設(shè)備完成時,對第二個設(shè)備做同樣的處理。 
      5. 當?shù)诙€設(shè)備完成時,發(fā)送 ZDO 終端設(shè)備綁定響應(yīng)信息到第一個和第二個設(shè)備 
3.1.3 設(shè)備應(yīng)用綁定管理 
       在設(shè)備上其他進入綁定條目的方式是應(yīng)用層管理綁定表格。 意思是說,應(yīng)用層將調(diào)用下列函數(shù)進入和移除綁定表格條目:

bindAddEntry() ——增加綁定表格條目

bindRemoveEntry() —— 從綁定表格中移除條目

bindRemoveClusterIdFromList() —— 從一個存在的綁定表格項目中移除一個串 ID 。

bindAddClusterIdToList()——向一個已經(jīng)存在的綁定記錄中增加一個群ID

bindRemoveDev()——刪除所有地址引用的記錄

bindRemoveSrcDev()——刪除所有源地址引用的記錄

bindUpdateAddr()——將記錄更新為另一個地址

bindFindExisting()——查找一個綁定表記錄

bindIsClusterIdInList()——在表記錄中檢查一個已經(jīng)存在的群ID

bindNumBoundTo()——擁有相同地址(源或者目的)的記錄的個數(shù)

bindNumEntries()——表中記錄的個數(shù)

bindCapacity()——最多允許的記錄個數(shù)

bindWriteNV()——在NV中更新表
3.2 配置源綁定 
       允許綁定源的編譯選項 REFLECTOR 在 f8wConfig.cfg 文件中。在文件f8wConfig.cfg,中查看這兩個綁定配置參數(shù)(DNWK_MAX_BINDING_ENTRIES & DMAX_BINDING_CLUSTER_IDS)。DNWK_MAX_BINDING_ENTRIES 綁定表格中最大的綁定實體數(shù)量參數(shù);DMAX_BINDING_CLUSTER_IDS 是在每個綁定實體中最大的串ID 數(shù)量。 綁定表在靜態(tài)RAM 中(未分配),因此綁定表中記錄的個數(shù),每條記錄中群ID的個數(shù)都實際影響著使用 RAM 的數(shù)量。每一條綁定記錄是 8 字節(jié)多(MAX_BINDING_CLUSTER_IDS * 2 字節(jié))。除了綁定表使用的靜態(tài) RAM 的數(shù)量,綁定配置項目也影響地址管理器中的記錄的個數(shù)。

本站僅提供存儲服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
ZigBee四種綁定 在TI Z
zstack開發(fā)指南
Z
SimpleApp例程中兩種綁定機制程序流程
SimpleApp和GenericApp實例綁定程序流程
玩轉(zhuǎn)Wi-Fi的不傳之秘
更多類似文章 >>
生活服務(wù)
分享 收藏 導(dǎo)長圖 關(guān)注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服