資深移動通信工程師學(xué)習zigbee心得

201*-11-12

物理層的PIB是什么概念?有什么用?201*-11-18

物理層的CCA.物理層是怎么知道信道的被占用情況.

AODV+ENY是什么概念?

AODVjr協(xié)議[2]在考慮了無線節(jié)點的有限移動性之后，以最大限度降低節(jié)點功耗為目的，

對AODV協(xié)議進行了簡化。AODVjr協(xié)議僅保留了AODV協(xié)議按需路由的動態(tài)特性，而將HELLO消息、路由錯誤信息、問詢序列號等AODV協(xié)議為了適應(yīng)節(jié)點移動性提出的優(yōu)化措施統(tǒng)統(tǒng)省略，對AODV協(xié)議進行了最大限度的簡化。受益于這樣的簡化，AODVjr協(xié)議在能耗方面極大地優(yōu)于AODV協(xié)議，因此AODVjr協(xié)議被廣泛應(yīng)用于各種無線傳感器網(wǎng)絡(luò)。AODVjr協(xié)議最大的問題是沒有考慮路由的安全性，不僅數(shù)據(jù)在傳輸過程中極有可能被篡改或故意丟棄，路徑信息本身也有可能被更改。

為了維持路徑的可用性，路徑的生命期只有在收到數(shù)據(jù)包時才進行更新，而發(fā)送數(shù)據(jù)包不進行路徑更新。

Zigbee和adhoc網(wǎng)絡(luò)不同.在adhoc網(wǎng)絡(luò)中各個結(jié)點間的地位是相同的.而zigbee中網(wǎng)元間的地位是不一樣的.

建網(wǎng)過程中,協(xié)調(diào)器對信道的主導(dǎo)掃描是干什么?發(fā)出信標請求又是干什么?PANID又是根據(jù)什么機制確定的?64為IEEE地址的作用是什么?

一個終端節(jié)點第一開機,檢測信道,如果有1個以上信道上有信標,這個節(jié)點怎么做選擇呢?是不是所以拓撲結(jié)構(gòu)的地址分配算法都是:An=Ak+Cship(d)*Rm+n?還是,只是樹狀拓撲結(jié)構(gòu)時,按這個算法分配地址呢?

官方的網(wǎng)絡(luò)層的路由協(xié)議是什么?是AODVjr和Cluster-Tree都有嗎?RF4CE是什么?

GTS是什么概念?

Beacon的一個作用是注冊/識別一個PAN?是什么概念?

路由表入口是什么概念?

CAPcontentionaccessperiodCFPcontentionfreeperiodGTSGuaranteedtimeslot

201*年12月31日星期五聽視頻Zigbee和藍牙紅外wifi是一個檔次的概念

201*年頒布第一個zigbee規(guī)范�，F(xiàn)在有zigbee201*201*各個版本。

802.15只定義了物理層和MAC層。Zigbee在802.15上又定義了網(wǎng)絡(luò)層和應(yīng)用層。應(yīng)用層上可以連240個應(yīng)用層設(shè)備。

201*年1月4日星期二

201*年2月15日星期二學(xué)習《Zigbee無線組網(wǎng)技術(shù)的研究》心得

1找到合適的信道后，協(xié)調(diào)器將為網(wǎng)絡(luò)選定一個網(wǎng)絡(luò)標識符(PANID，取值_

個PANID是16位短地址中的一個嗎?不是吧

2主動掃描和被動掃描有區(qū)別嗎？無論怎么樣，掃描一遍不行嗎？

201*年2月16日星期三

1本文通過減小每個節(jié)點加入網(wǎng)絡(luò)的時間及原語數(shù)來達到減小這種沖突的目的，從加入網(wǎng)絡(luò)的時間分析，加入網(wǎng)絡(luò)的絕大部分時間花費在主動掃描、信標周期和等待協(xié)調(diào)器處理時間上，而前兩者時間是固定不變的，但是等待協(xié)調(diào)器處理的時間卻是可變的，和協(xié)調(diào)器要處理的原語數(shù)量有關(guān)，可以通過減少原語的數(shù)量，減小協(xié)調(diào)器處理這些原語通信握手過程所需要的時間，這樣協(xié)調(diào)器就能更快的響應(yīng)節(jié)點的關(guān)聯(lián)加入。

2節(jié)點加入過程是個半盲目的過程。估計是為了減少接入時間和減少復(fù)雜度的原因吧。節(jié)點向協(xié)調(diào)器發(fā)Associationrequest后，協(xié)調(diào)器會發(fā)一個ACK。這個ACK只是用來說”哦“。

然后節(jié)點要等，再做一個CSMA？這里做CSMA估計是為了防沖突吧，估計不是必須要做的。接著，節(jié)點再去問協(xié)調(diào)器要地址等信息。這些信息應(yīng)該在Associationresponse里。

如果節(jié)點等了一段時間，協(xié)調(diào)器不通過信令給他分配信息，節(jié)點會自己從協(xié)調(diào)器的信標里提取響應(yīng)命令（？比較神奇）這個響應(yīng)命令里會有地址信息嗎？

傳統(tǒng)MAC設(shè)計目標是：最大化吞吐量、最小時延、公平性

ZIGBEEMAC設(shè)計目標是：最小化能耗、自組織能力。所以速率、時延、公平性都要做犧牲。

S-MAC提出用3種方法來減少能耗并支持自組織：1節(jié)點定期睡眠以減少空閑監(jiān)聽

2鄰近節(jié)點組成虛擬簇，使睡眠調(diào)度時間自動同步3用消息傳遞方法來減少時延

在星型網(wǎng)拓撲結(jié)構(gòu)中，網(wǎng)絡(luò)協(xié)調(diào)者定義了整個網(wǎng)絡(luò)的時分復(fù)用和多址接入方式。

根據(jù)業(yè)務(wù)流性質(zhì)，zigbee應(yīng)用可以分成連續(xù)性、周期性（如流速計）和間斷性（如家電控制）

三種。

Zigbee協(xié)議棧只要8位處理器再加4kbrom和32kbrom就可以了。SD和BI長度是由網(wǎng)絡(luò)協(xié)調(diào)器決定的。

超幀的的活躍期間劃分為3個階段：信標發(fā)送時段、競爭訪問時段CAP、非競爭訪問時段CFP。超幀的活躍期被劃分成（默認16）個等長的時隙。時隙個數(shù)、時隙長度等參數(shù)有協(xié)調(diào)者決定，并通過信標幀廣播

在超幀的競爭訪問階段，節(jié)點使用帶時隙的CSMA-CA訪問機制，并且任何通信都必須在競爭訪問時段結(jié)束前完成。

GTS,在非競爭時段，這個時段被分成若干個GTS。每個GTS又由多個時隙組成。

2種通信模式：1帶信標帶時隙的CSMA-CA

2不帶信標使用非時隙的CSMA-CA機制訪問信道確認幀不需要使用CSMA-CA機制

MAC幀通用結(jié)構(gòu)：幀頭、負荷、幀尾幀頭：幀控制域幀號地址域

負荷：是可變的，具體內(nèi)容由幀類型決定幀尾：16位CRC校驗嗎

16位地址是一個zigbee網(wǎng)的內(nèi)部節(jié)點，是協(xié)調(diào)者來分配的，在一個網(wǎng)內(nèi)是唯一的。也就意為著一個網(wǎng)做多有65000個左右的端點。PAN標識也是16位的。

64為地址是，設(shè)備的出廠地址，是全球唯一的。類似每個計算機網(wǎng)卡的MAC地址。

信標幀其中的待發(fā)送數(shù)據(jù)目標地址字段的作用是：在協(xié)調(diào)器要給某個節(jié)點用間接發(fā)送方式時，節(jié)點會去監(jiān)聽信標幀的這個字段。如果在這個字段里有我的地址，那節(jié)點會隨后發(fā)起向

協(xié)調(diào)器要數(shù)據(jù)的流程。

樓老師膠片中的和藍牙比較中，zigbee有254個節(jié)點設(shè)備。這個256是怎么來的？一個主節(jié)點下可以聯(lián)256個節(jié)點。簡單理解，在星型拓撲模式下，一個FFD可以聯(lián)254個RFD。

擴展閱讀：zigbee總結(jié)zigbee和GSC CDMA 學(xué)習筆記

關(guān)于ZIGBEE技術(shù)

Zigbee的由來

在藍牙技術(shù)的使用過程中，人們發(fā)現(xiàn)藍牙技術(shù)盡管有許多優(yōu)點，但仍存在許多缺陷。對工業(yè)，家庭自動化控制和遙測遙控領(lǐng)域而言，藍牙技術(shù)顯得太復(fù)雜，功耗大，距離近，組網(wǎng)規(guī)模太小等，而工業(yè)自動化對無線通信的需求越來越強烈。正因此，經(jīng)過人們長期努力，Zigbee協(xié)議在201*年中通過后，于201*正式問世了。

Zigbee是什么

Zigbee是一個由可多到65000個無線數(shù)傳模塊組成的一個無線數(shù)傳網(wǎng)絡(luò)平臺，十分類似現(xiàn)有的移動通信的CDMA網(wǎng)或GSM網(wǎng)，每一個Zigbee網(wǎng)絡(luò)數(shù)傳模塊類似移動網(wǎng)絡(luò)的一個基站，在整個網(wǎng)絡(luò)范圍內(nèi)，它們之間可以進行相互通信；每個網(wǎng)絡(luò)節(jié)點間的距離可以從標準的75米，到擴展后的幾百米，甚至幾公里；另外整個Zigbee網(wǎng)絡(luò)還可以與現(xiàn)有的其它的各種網(wǎng)絡(luò)連接。例如，你可以通過互聯(lián)網(wǎng)在北京監(jiān)控云南某地的一個Zigbee控制網(wǎng)絡(luò)。

不同的是，Zigbee網(wǎng)絡(luò)主要是為自動化控制數(shù)據(jù)傳輸而建立，而移動通信網(wǎng)主要是為語音通信而建立；每個移動基站價值一般都在百萬元人民幣以上，而每個Zigbee—基站‖卻不到1000元人民幣;每個Zigbee網(wǎng)絡(luò)節(jié)點不僅本身可以與監(jiān)控對對象，例如傳感器連接直接進行數(shù)據(jù)采集和監(jiān)控，它還可以自動中轉(zhuǎn)別的網(wǎng)絡(luò)節(jié)點傳過來的數(shù)據(jù)資料;除此之外，每一個Zigbee網(wǎng)絡(luò)節(jié)點（FFD）還可在自己信號覆蓋的范圍內(nèi)，和多個不承擔網(wǎng)絡(luò)信息中轉(zhuǎn)任務(wù)的孤立的子節(jié)點（RFD）無線連接。

每個Zigbee網(wǎng)絡(luò)節(jié)點（FFD和RFD）可以可支持多到31個的傳感器和受控設(shè)備，每一個傳感器和受控設(shè)備終可以有8種不同的接口方式�？梢圆杉�和傳輸數(shù)字量和模擬量。Zigbee技術(shù)的應(yīng)用領(lǐng)域

Zigbee技術(shù)的目標就是針對工業(yè)，家庭自動化，遙測遙控，汽車自動化、農(nóng)業(yè)自動化和醫(yī)療護理等,例如燈光自動化控制，傳感器的無線數(shù)據(jù)采集和監(jiān)控，油田，電力，礦山和物流管理等應(yīng)用領(lǐng)域。另外它還可以對局部區(qū)域內(nèi)移動目標例如城市中的車輛進行定位.

通常，符合如下條件之一的應(yīng)用，就可以考慮采用Zigbee技術(shù)做無線傳輸：1．需要數(shù)據(jù)采集或監(jiān)控的網(wǎng)點多；

2．要求傳輸?shù)臄?shù)據(jù)量不大，而要求設(shè)備成本低；3．要求數(shù)據(jù)傳輸可性高，安全性高；

4．設(shè)備體積很小，不便放置較大的充電電池或者電源模塊；5．電池供電；

6．地形復(fù)雜，監(jiān)測點多，需要較大的網(wǎng)絡(luò)覆蓋；7．現(xiàn)有移動網(wǎng)絡(luò)的覆蓋盲區(qū)；

8．使用現(xiàn)存移動網(wǎng)絡(luò)進行低數(shù)據(jù)量傳輸?shù)倪b測遙控系統(tǒng)。

9．使用GPS效果差，或成本太高的局部區(qū)域移動目標的定位應(yīng)用。Zigbee技術(shù)的特點

省電：兩節(jié)五號電池支持長達6個月到2年左右的使用時間。

可靠：采用了碰撞避免機制，同時為需要固定帶寬的通信業(yè)務(wù)預(yù)留了專用時隙，避免了發(fā)送數(shù)據(jù)時的競爭和沖突；節(jié)點模塊之間具有自動動態(tài)組網(wǎng)的功能，信息在整個Zigbee網(wǎng)絡(luò)中通過自動路由的方式進行傳輸，從而保證了信息傳輸?shù)目煽啃浴?/p>

時延短：針對時延敏感的應(yīng)用做了優(yōu)化，通信時延和從休眠狀態(tài)激活的時延都非常短。

網(wǎng)絡(luò)容量大：可支持達65000個節(jié)點。

安全：ZigBee提供了數(shù)據(jù)完整性檢查和鑒權(quán)功能，加密算法采用通用的AES-128。

高保密性：64位出廠編號和支持AES-128加密。Zigbee的發(fā)展前景

Zigbee技術(shù)和RFID技術(shù)在201*年就被列為當今世界發(fā)展最快，市場前景最廣闊的十大最新技術(shù)中的兩個。關(guān)于這方面的報道，你只需在百度，或GOOGLE搜索欄中鍵入—Zigbee‖,你就會看到大量的有關(guān)報道。總之，今后若干年，都將是Zigbee技術(shù)飛速發(fā)展的時期。Zigbee技術(shù)在我國的應(yīng)用情況

盡管，國內(nèi)不少人已經(jīng)開始關(guān)注Zigbee這們新技術(shù)，而且也有不少單位開始涉足Zigbee技術(shù)的開發(fā)工作，然而，由于Zigbee本身是一種新的系統(tǒng)集成技術(shù)，應(yīng)用軟件的開發(fā)必須和網(wǎng)絡(luò)傳輸，射頻技術(shù)和底層軟硬件控制技術(shù)結(jié)合在一起。因而深入理解這個來自國外的新技術(shù)，再組織一個在這幾個方面都有豐富經(jīng)驗的配套的隊伍，本身就不是一件容易的事情，因而，到目前為止，國內(nèi)目前除了成都西谷曙光數(shù)字技術(shù)有限公司，真正將Zigbee技術(shù)開發(fā)成產(chǎn)品，并成功地用于解決幾個領(lǐng)域的實際生產(chǎn)問題而外，尚未見到其它報道。Zigbee和現(xiàn)有移動網(wǎng)（GPRS，CDMA-1X）的比較

1．無網(wǎng)絡(luò)使用費：使用移動網(wǎng)需要長期支付網(wǎng)絡(luò)使用費，而且是按節(jié)點終端的數(shù)量計算的，而Zigbee沒有這筆費用；

2．設(shè)備投入低：使用移動網(wǎng)需要購買移動終端設(shè)備，每個終端的價格在人民幣1000元上下，而使用Zigbee網(wǎng)絡(luò)，不僅Zigbee網(wǎng)絡(luò)節(jié)點模塊（相當于基站）費用每只人民幣不到1000元，而且，主要使用的網(wǎng)絡(luò)子節(jié)點（相當于手機）的價格還要低得多；

3．通信更可靠：由于現(xiàn)有移動網(wǎng)主要是為手機通信而設(shè)計的，盡管CDMA-1X和GPRS可以進行數(shù)據(jù)通信，但實踐發(fā)現(xiàn)，不僅通信數(shù)率比設(shè)計速率低很多，而且數(shù)據(jù)通信的可靠信也存在一定的問題。而Zigbee網(wǎng)絡(luò)則是專門為控制數(shù)據(jù)的傳輸而設(shè)計的,因而控制數(shù)據(jù)的傳輸具有相當?shù)谋ＷC。

4．高度的靈活性和低成本：首先，通過使用覆蓋距離不同,功能不同的Zigbee網(wǎng)絡(luò)節(jié)點，以及其它非Zigbee系統(tǒng)的低成本的無線收發(fā)模塊，建立起一個Zigbee局部自動化控制網(wǎng)，（這個網(wǎng)絡(luò)可以是星型，樹狀，網(wǎng)狀及其共同組成的復(fù)合網(wǎng)結(jié)構(gòu)）再通過互聯(lián)網(wǎng)或移動網(wǎng)與遠端的計算機相連，從而實現(xiàn)低成本，高效率的工業(yè)自動化遙測遙控；

5．比起現(xiàn)有的移動網(wǎng)來，盡管Zigbee僅僅只是一個局域網(wǎng)，覆蓋區(qū)域有限，但它卻可以與現(xiàn)有的移動網(wǎng)，互聯(lián)網(wǎng)和其它通信網(wǎng)絡(luò)相連接，將許多Zigbee局域網(wǎng)相互連成為一個整體。有效的解決移動網(wǎng)的盲區(qū)覆蓋問題：我們知道，現(xiàn)有移動網(wǎng)絡(luò)在許多地方存在盲區(qū)，特別是鐵路，公路，油田，礦山等野外，更是如此。而增加一個移動基站或直放站的費用是相當可觀的，此時使用Zigbee網(wǎng)絡(luò)進行盲區(qū)覆蓋不僅經(jīng)濟有效，而且往往是現(xiàn)在唯一可行手段。Zigbee與現(xiàn)有數(shù)傳電臺的比較

1．可靠性高：由于Zigbee模塊的集成度遠比一般數(shù)傳電臺高，分離元器件少，因而可靠性更高；

2．使用方便安全：因為集成度高，比起一般數(shù)傳電臺來，Zigbee收法模塊體積可以做得很小，而且功耗低，例如成都西谷公司遠距離傳輸模塊（2-5公里），最大發(fā)射電流比一個CDMA手機還要小許多，因而很容易集成或直接安放在到設(shè)備之中，不僅使用方便，而且在戶外使用時，不容易受到破壞；

3．抗干擾力強，保密性好，誤碼率低：Zigbee收發(fā)模塊使用的是2.4G直序擴頻技術(shù)，比起一般FSK,ASK和跳頻的數(shù)傳電臺來，具有更好的抗干擾能力，和更遠的傳輸距離；參閱我們網(wǎng)站中有關(guān)CDMA直序擴頻技術(shù)的優(yōu)越性討論，和Cypress公司有關(guān)實驗報道。

4．免費頻段：Zigbee使用的是免費頻段，而許多數(shù)傳電臺所使用的頻段不僅需要申請，而且每年都需要向國家無委會交納相當?shù)念l率使用費。

5．價格低：Zigbee數(shù)傳模塊的價格只有具有類似功能的數(shù)傳電臺的幾分之一；(2.4G,250kps,3-5公里距離DSSS數(shù)傳模塊每只不到200元人民幣)

提供低成本，高可靠性的無線數(shù)傳互聯(lián)網(wǎng)平臺（包括軟件和硬件）,以及相關(guān)技術(shù)支持，以滿足不同客戶的具體需要，就是我們的服務(wù)宗旨。

學(xué)習Zstack之1

Zstack情況：

本人采用的是TI的Zstack1.4.3協(xié)議，據(jù)說這個需要IAR7.30B及以上版本，而目前市面上又沒有破解，所以用的人很少，這也是我的機會！呵呵�。ㄉ敌τ悬c多，關(guān)鍵是WORD里沒有表情符號，不能正常表達我此時的心情�。�

正式開始：

開始之前在說一句：從TI網(wǎng)站上下載的Zstack的方法就不介紹了。否則就是從-1開始了而不是從0開始了-----------------我是這么覺得的！

第一步：安裝Zstack

從TI官方網(wǎng)站上下載的Zstack為：swrc072c.zip，我想這個壓縮包大家都認識。解壓之后為：ZStack-CC2430-1.4.3.exe文件。這個安裝文件大家都會了。默認安裝路徑為：C:\\TexasInstruments\\ZStack-1.4.3。安裝之后在C:\\TexasInstruments\\ZStack-1.4.3目錄下有各PDF文檔為：GettingStartedGuideCC2430.pdf，不用多說，這個肯定是要看的。既然把它放到這么前面，說明它是入門中的入門文檔。下面就簡單介紹下這個文檔：

1、介紹了安裝ZStack-CC2430-1.4.3.exe需要的硬件軟件條件:需要電腦、操作系統(tǒng)為Windows201*或WindowsXP。至于更高或更低版本的本人沒有嘗試。2、講了安裝流程。這個有點多余了，這年月哪個有電腦的沒有安裝上百上千次的軟件��？但是需要強調(diào)的是安裝路徑----默認就好！3、接下來就是讓我們看的第一個文檔為：

Start->Programs->TexasInstruments->ZStack-1.4.3->Z-StackUser’sGuide,既然讓我看我就來看看這個文檔��！

第二步：Z-Stack用戶指導(dǎo)

這個文檔的更新時間為：201*年12月21日----應(yīng)該還是比較新的版本。由于本人英文的卻有限，就不翻譯了，瀏覽一遍，把大概意思說下就可以了：1、介紹

1.1、適用范圍

本文檔適用于CC2430ZigBee開發(fā)板----CC2430ZDK。2、產(chǎn)品包描述（TI提供的CC2430ZDK工具包）2.1、安裝包內(nèi)容

這個就是上面提到的的ZStack-CC2430-1.4.3.exe安裝之后的所有內(nèi)容了。說白了就是包含Zstack開發(fā)所需要的所有軟件和文檔資料等。2.2、開發(fā)板介紹

兩塊SmartRF04EB評估版，每個都可以用于CC2430EM評估模塊。如圖1-1所示：

Figure1:ChipconSmartRF04EBEvaluationBoardwithCC2430EM5塊CC2430DB評估板，如圖1-2所示：

Figure2:ChipconCC2430DBDevelopmentBoard

10個SOC_BB評估板，每個都可以用于CC2430EM或CC2431EM。如圖1-3所示：

Figure3:ChipconSOC_BBBatteryBoard2.3、電纜

也就是包含開發(fā)包所需要的電纜，如RS232串口線，USB線等等附屬配件。3、安裝配置3.1、主機配置

一臺個人計算機----也就是電腦哈。我想玩嵌入式的應(yīng)該都有，而現(xiàn)今不過時的配置就可以：下面是最低配置.NET1.1架構(gòu)WindowsXPServicePack1(i如果是WindowsXP)1個串口（也就是RS232接口）s1USB接口

個人認為要求已經(jīng)相當?shù)土�，如果你的電腦沒有這配置，個人強烈建議馬上扔掉！不過如今筆記本電腦很少有串口的，所以建議使用臺式電腦，而且裝機的時候一定要把串口引出，否則就比較麻煩了！3.2、目標板需求

其實也是開發(fā)環(huán)境需求---IAREW8051。目前需要的版本為7.30B及以上。要求還是比較高的，因為目前這個版本沒有破解的。但是在上有30天評估版下載。這個版本使用一定要小心，因為如果30天之后僅僅是卸載IAR重新安裝是沒有用的，一般最笨的辦法是重新安裝操作系統(tǒng)。解決這個問題最好的辦法就是買正版，呵呵，我想絕大多數(shù)像我這樣的中國人都不會買的。除此之外最好的辦法就是破解，但是目前這個破解極少，都是需要收費的，而且都是國外網(wǎng)站才有，所以我們就只好期望中國的高人抓緊破解并公開了！當然其他解決辦法就相對來說很多了，比如安裝后弄個還原點什么的；或者安裝后我不停地使用（每天24小時），30天之后我覺得你也學(xué)會了，就不用IAR這個版本了，說不定就移植到低版本上去了；等等類似之法我覺得都可以的。本人采用的是本辦法中相對比較聰明的，也是一位高人告訴我的：裝個虛擬操作系統(tǒng)，在虛擬操作系統(tǒng)下時間可以隨時更改，讓它一直停留在某個時間，主要30天的試用就比較慢長了，只要你不要忘記改那時間。4、產(chǎn)品安裝過程4.1、安裝Z-Stack

這個也就是安裝ZStack-CC2430-1.4.3.exe的過程。4.2、IAR安裝

一般來說安裝選擇默認路徑，但是自定義路徑也不會出問題的。注意IAR版本7.30B及以上版本才可以運行1.4.3協(xié)議。4.3、設(shè)備IEEE地址

每個CC2430DB,CC2430EM,和CC2431EM都已經(jīng)排列了一個唯一的64位物理地址（IEEE地址），這個地址已經(jīng)寫到了CC2430內(nèi)部FLASH里面，在CC2430DB,CC2430EM,和CC2431EM板的底部有這個地址標簽。

這個地址被寫入到FLASH的0x1FFF8地址中，注意這個地址也可以更改的，通過些FLASH軟件，一般0xFFFFFFFFFFFFFFFF地址被認為是無效地址。5、配置并試用Z-Stack5.1、配置Z-Stack

這個詳見5.3節(jié)。5.2、邏輯類型

這里主要是介紹了ZIGBEE協(xié)議中的三種設(shè)備類型：

ZigBee協(xié)調(diào)者(ZC)：這個設(shè)備被配置為初始化并建立一個PAN網(wǎng)絡(luò)

ZigBee路由器(ZR)：該設(shè)備被配置為加入一個存在的網(wǎng)絡(luò)，可以加入一個協(xié)調(diào)求或路由器，然后允許其他設(shè)備加入它，在網(wǎng)絡(luò)中路有數(shù)據(jù)信息。

ZigBee終端節(jié)點(ZED)：該設(shè)備被配置為加入一個存在的網(wǎng)絡(luò)，可以加入一個協(xié)調(diào)求或路由器。

5.3、建立樣品應(yīng)用設(shè)備：SampleApp

基本上就是采用SampleApp應(yīng)用中的Demo例子來演示整個流程，就是采用一個協(xié)調(diào)器和一個或多個路由器來形成一個ZigBee網(wǎng)絡(luò)演示。在該例子中主要通過SmartRF04EB板上的某些跳線來完成設(shè)備類型的選型，當然這個方法在程序中是需要判斷哪個按鍵被拉低或拉高，對于做個設(shè)計的來說應(yīng)該是相當好理解的。

申明：由于本人很窮，所以沒錢買TI原裝開發(fā)包，當然也就沒有上面提到的硬件，本人采用的是某家公司（為了避免廣告，這里就不說明了）的硬件系統(tǒng)。5.4、建立一個SampleLight協(xié)調(diào)器設(shè)備

至于提到的硬件連接這里一律省略。

無疑：首先要打開對應(yīng)工程，如圖1-4所示：

圖1-4

在工作窗口中選擇DemoEB，如圖1-5所示：圖1-5

然后選擇工程菜單（Project）下的全部編譯（RebuildAll）選項，如圖1-6所示：

圖1-6

然后選擇工程菜單（Project）下的調(diào)試（Debug）選項，如圖1-7所示：

圖1-7

下載完之后就可以退出調(diào)試狀態(tài)，通過選中調(diào)試菜單下的停止調(diào)試選項，如圖1-8所示：

圖1-8

按照此種方法下載至少兩個CC2430EM模塊，就可以進行Demo演示了。6、Z-Stack示范

略

至于詳細的示范流程，這里先不說了，因為本人采用的硬件與原裝有點差異，即使按照這個方法下載仍然不能演示，因為我這個不能用跳線來選擇設(shè)備類型。

所以我必須進入程序把跳線判斷程序進行簡單必要的修改才能演示。該文檔介紹的演示結(jié)果及現(xiàn)象都是基于CHIPCON原廠評估板。7.PanID和通道（Channel）選擇

ZigBee協(xié)議規(guī)范規(guī)定，一個14位的個域網(wǎng)標志符（PANID）來標識唯一的一個網(wǎng)絡(luò)。Z-Stack可以用兩種方式由用戶自己選擇其PANID，當ZDAPP_CONFIG_PAN_ID值設(shè)置不為0xFFFF時，那么設(shè)備建立或加入網(wǎng)絡(luò)的PANID由ZDAPP_CONFIG_PAN_ID指定；如果設(shè)置ZDAPP_CONFIG_PAN_ID為0xFFFF；那么設(shè)備就將建立或加入它發(fā)現(xiàn)網(wǎng)絡(luò)中的—最好‖的網(wǎng)絡(luò)。關(guān)于這里提到的—最好‖的網(wǎng)絡(luò)，我覺得可能是有些參數(shù)評估，只不過這里沒有詳細的介紹，在后續(xù)文檔中應(yīng)該有介紹的。

在2.4G頻段上，IEEE802.15.4/ZIGBEE規(guī)范規(guī)定了16各頻道。用戶可以通過選擇DEFAULT_CHANLIST不同的值可以選擇不同的頻道，其頻道如圖1-9所示。改協(xié)議默認頻道為0xB及0x00000800。

圖1-9

DEFAULT_CHANLIST和ZDAPP_CONFIG_PAN_ID都作為IARIDE中的編譯選項可以進行設(shè)置，在應(yīng)用文件中的…\\Projects\\Tools\\CC2430DB目錄下的f8wConfig.cfg文件中有相應(yīng)設(shè)置，如圖1-10所示。

圖1-10

學(xué)習Zstack之2

上節(jié)基本上初步認識了Zstack的一些情況，今天繼續(xù)我的學(xué)習，打開Sample例子看看，究竟ZIGBEE是怎么回事。

毫無疑問：如果是第一次打開這個例子工程，肯定很迷糊，因為此時我迷糊了。對圖2-1我簡直是相當迷糊。圖2-1

這么多文件夾，打開之后又有那么多文件，從何看起？不要著急，特別是有些人拿到之后，啥都不知道的人第一個問題就是：我要實現(xiàn)XXX，在哪修改或者在哪添加我的函數(shù)呢？凡是我遇到這樣的客戶，我就可以肯定他技術(shù)部咋的。就連我這個外行都知道，不把這些弄明白，就是實現(xiàn)XXX只需要修改一個字母，那也不知道在哪改啊？所以我不急，但是我也理解很多客戶，因為有時候項目催的比較急，畢竟老板都是外行嘛！

兩條路：1就是先看主函數(shù)，2就是看看TI提供例子說明文檔沒有。我這里先看看主函數(shù)再說哈！因為我就知道從主函數(shù)看起.

沒辦法大概每個文件夾找啊，主函數(shù)的特征還是比較明明顯的，見圖2-2所示：

圖2-2

下面把主函數(shù)復(fù)制過來簡單看下：ZSEGintmain(void){

//Turnoffinterrupts------------關(guān)閉中斷osal_int_disable(INTS_ALL);

//InitializeHAL-----------初始化HAL，關(guān)于HAL是什么我想后面會有介紹的。HAL_BOARD_INIT();

//Makesuresupplyvoltageishighenoughtorun----電壓檢測，最好是能保證芯片能正常工作的電壓zmain_vdd_check();

//Initializestackmemory-------------初始化stack存儲區(qū)zmain_ram_init();//InitializeboardI/O------------初始化板載IOInitBoard(OB_COLD);

//InitialzeHALdrivers-------------初始化HAL驅(qū)動HalDriverInit();

//InitializeNVSystem--------------初始化NV系統(tǒng)，NV是什么后面我想也會有介紹的

osal_nv_init(NULL);

//Determinetheextendedaddress------------確定擴展地址（64位IEEE/物理地址）zmain_ext_addr();

//InitializebasicNVitems----------------初始化基本NV條目zgInit();

//InitializetheMAC----------------初始化MACZMacInit();

#ifndefNONWK

//SincetheAFisn"tatask,callit"sinitializationroutineafInit();#endif

//Initializetheoperatingsystem----------初始化操作系統(tǒng)，看樣子這里面還有OS，麻煩了……..！osal_init_system();

//Allowinterrupts-------------允許中斷osal_int_enable(INTS_ALL);

//Finalboardinitialization------------------最后的版在初始化InitBoard(OB_READY);

//Displayinformationaboutthisdevice---------------顯示設(shè)備信息zmain_dev_info();

/*DisplaythedeviceinfoontheLCD*/------------液晶支持顯示#ifdefLCD_SUPPORTEDzmain_lcd_init();#endif

osal_start_system();//NoReturnfromhere-------------------這里沒有返回，大概是進入OS了。}//main()

可以看到基本上都是初始化函數(shù)，因為函數(shù)名稱都基本上帶了init字樣的，呵呵，個人覺得TI的變成習慣比我好，一看名稱就知道大概功能了。所以這里也奉勸各位像我這樣菜鳥級的初學(xué)者，一開始一定就要養(yǎng)成規(guī)范化編程的習慣，據(jù)說這樣維護以及以后升級或者移植兼容性都比較好。我就先不管各個初始化函數(shù)是怎么實現(xiàn)的，我先看看各個功能是什么，現(xiàn)掌握整體功能在細化，我覺得這樣的學(xué)習方法比較好，因為代碼是在太多了，從一開始就逐句看，我敢保證沒幾個人有耐心看完看明白！

幸好每個初始化函數(shù)都有一句說明，雖然是英文的，但是理解起來一點都不難的。關(guān)于每個函數(shù)的功能我就直接寫在上面的程序里面，節(jié)省紙張哈！

一句話：主函數(shù)的功能就是初始化！

主函數(shù)看完了又開始模糊了，又從何看起呢？在無從下手之際，只有去尋求TI說明文檔的幫助了。上節(jié)不是漏掉了內(nèi)容，是關(guān)于演示結(jié)果的，這里做上補充，怕因為缺調(diào)一點后面遇到什么不理解的就慘了！Sample例子演示演示現(xiàn)象：

1、認識硬件------------按鍵和LED

上節(jié)提到了EM和DB兩個板子，其硬件是不一樣的。按鍵EM就有5各SW1~SW5，而DB只有1各方向鍵，但是他們有個對應(yīng)關(guān)系，如圖2-3所示.

圖2-3

LED數(shù)量和顏色也不一樣，EM有四個LED，如圖2-4；而DB只有兩個，如圖2-5。

如圖2-4

如圖2-5

關(guān)于上面幾個圖2-4/5中出現(xiàn)的LEDx實際上是程序中出現(xiàn)的關(guān)鍵字。2、初始化64位IEEE地址

實際上在主函數(shù)中有這么個初始化函數(shù)的：zmain_ext_addr()。這里說如果地址復(fù)位為0xFFFFFFFFFFFFFFFF的話，那么就會不停的閃爍LED1，一直等到按鍵SW5按下后程序才能繼續(xù)運行，意思就是說按下SW5后就把無效的地址初始化為有效地物理地址了，這個應(yīng)該是程序上實現(xiàn)的，那么就來看看對應(yīng)的程序zmain_ext_addr。

/*********************************************************************

*@fnzmain_ext_addr

*@briefMakesextendedaddressifnoneexists.確定擴展地址是有效的*@returnnone

*********************************************************************/

staticZSEGvoidzmain_ext_addr(void){

uint8i;uint8led;uint8tmp;uint8*xad;uint16AtoD;

//InitializeextendedaddressinNV初始化NV里的擴載地址

osal_nv_item_init(ZCD_NV_EXTADDR,Z_EXTADDR_LEN,NULL);

osal_nv_read(ZCD_NV_EXTADDR,0,Z_EXTADDR_LEN,&aExtendedAddress);//Checkforuninitializedvalue(erasedEEPROM=0xFF)檢查是否為無效值（地址）xad=(uint8*)&aExtendedAddress;for(i=0;i

if(*xad++!=0xFF)return;-----如果有一個字節(jié)不為0xFF，那么該地址有效返回#ifdefZDO_COORDINATORtmp=0x10;#else

tmp=0x20;#endif

//Initializewithasimplepattern----------------簡單初始化擴展地址xad=(uint8*)&aExtendedAddress;

for(i=0;i

//FlashLED1untiluserhitsSW5---------閃爍LED1直到SW5按下led=HAL_LED_MODE_OFF;

while(HAL_KEY_SW_5!=HalKeyRead())---------------------SW5循環(huán)檢測{

MicroWait(62500);

HalLedSet(HAL_LED_1,led^=HAL_LED_MODE_ON);//ToggletheLEDMicroWait(62500);}

HalLedSet(HAL_LED_1,HAL_LED_MODE_OFF);//PlugAtoDdataintolowerbytes

AtoD=HalAdcRead(HAL_ADC_CHANNEL_7,HAL_ADC_RESOLUTION_10);xad=(uint8*)&aExtendedAddress;*xad++=LO_UINT16(AtoD);*xad=HI_UINT16(AtoD);

#if!defined(ZTOOL_PORT)||defined(ZPORT)||defined(NV_RESTORE)//IfnosupportforZ-ToolserialI/O,

//Writetemporary64-bitaddresstoNV些臨時的64位物理地址進入NV

osal_nv_write(ZCD_NV_EXTADDR,0,Z_EXTADDR_LEN,&aExtendedAddress);#endif}

從程序中可以看出，一開始就檢測FLASH中的物理地址，因為這個地址在FLASH中是固定的存儲空間，一旦為有效地址就退出函數(shù)，一旦為無效地址（0xFFFFFFFFFFFFFFFF）,那么就對其物理地址進行簡單的初始化并檢測SW5按鍵。還是比較好理解的！3、運行例子

在這里提到了跳線，由于本人采用的非TI原裝硬件，沒有該跳線，所以必須對程序進行修改，否則檢測不到跳線，連ZIGBEE的設(shè)備類型都不能確定，肯定不能正常運行了。所以這里就先暫時不說了，這里要說的是一切都正常的情況下，例子的驗尸結(jié)果。小小跳躍一下。不然學(xué)習一直沒有進展很麻煩的！

協(xié)調(diào)器：上電運行，地址檢測如上面介紹的情況，通過之后呢-------就進行通道掃描，此時LED1閃爍，一旦協(xié)調(diào)器成功建立網(wǎng)絡(luò)，此時LED1停止閃爍，而LED3被點亮。

路由器：上電運行，仍然是地址檢測在前。之后就是通道掃描尋求是否又存在的網(wǎng)絡(luò)，此時LED1閃爍，一旦檢測到存在網(wǎng)絡(luò)并成功加入該網(wǎng)絡(luò)，LED1將停止閃爍，被替換的是LED3別點亮，也就表明路由器成功加入了網(wǎng)絡(luò)。

那么此時能進行的操作控制是什么呢，也是最簡單的表現(xiàn)手法---按鍵無線控制LED：

周期（5S）發(fā)送信息到網(wǎng)絡(luò)中每個設(shè)備SW1按下，發(fā)送一個信息到組1的設(shè)備SW2按下，退出/加入組1這個我是經(jīng)過驗證的。如：

按下協(xié)調(diào)器SW1，路由器的LED1狂閃幾下；按下路由器的SW1，那么協(xié)調(diào)器的LED1也就狂閃幾下；當然我是只有兩個節(jié)點。

如果按1下協(xié)調(diào)器的SW2，在按下路由器的SW1，此時協(xié)調(diào)器就沒有反應(yīng)，表明協(xié)調(diào)器已經(jīng)退出組1；但是再按下協(xié)調(diào)器SW2在按路由器的SW1就與上一步類似了。路由器與此類似可以通過SW2退出/加入組1.

終于把演示弄完了，接下來就來看看程序。在此之前還是來看看TI提供的Sample指導(dǎo)文檔。這個文檔個人覺得寫的不錯，要是沒看之前就看程序的卻很郁悶的！

但是本人英文很差，所以需要慢慢看，等點時間放上來！

Z-Stack之3

SampleApplication分析（上）1、Z-StackCC2430DBandCC2430EBSampleApplication1.1、介紹

該文檔時介紹TI協(xié)議入門的一個例子SampleApp的，適用EM和DB開發(fā)板。

1.1.1、描述

這個例子是非常簡單的演示，每個設(shè)備都可以發(fā)送和接收兩個信息

周期信息-----加入該網(wǎng)絡(luò)的所有設(shè)備每隔10S（可能會加上一個隨機數(shù)的mS）都發(fā)送一個周期信息，該信息的數(shù)據(jù)載荷為發(fā)送信息次數(shù)的計數(shù)。

閃爍控制信息---------通過按下SW1可以發(fā)送一個控制燈閃爍的廣播信息，該廣播信息只針對組1的所有設(shè)備。

所有設(shè)備初始化為加入組1，所以網(wǎng)絡(luò)一旦成功建立/加入就可以進行閃爍控制�？梢酝ㄟ^按下設(shè)備的SW2退出組1，所以可以通過退出組1可以不接受閃燈信息。通過按下SW2也可以讓不在組1的設(shè)備加入近組1，從而又可以接受閃燈信息了。

這個理解應(yīng)該不困難的，反正我理解沒有什么障礙！1.1.1.1、按鍵

SW1：發(fā)送閃爍信息到組1所有設(shè)備SW2：轉(zhuǎn)換推出/加入組1狀態(tài)1.1.2、用戶應(yīng)用開發(fā)

這里我基本上能看明白是什么，但是我不打算寫出來，因為涉及到一些ZIGBEE的關(guān)鍵術(shù)語，不是很明白。

大概就是簡單介紹了下用戶怎么利用例子做自己的應(yīng)用，但是實用價值不高，說的太籠統(tǒng)，全是概念性的說明。1.2、OSAL任務(wù)1.2.1、初始化

因為Z-Stack是在OS下運行的，所以在之前必須調(diào)用osalAddTasks()初始化任務(wù)。1.2.2、組織

關(guān)于OS的API函數(shù)介紹請看文檔：Z-StackOSALAPI(F8W-201*-0002)，應(yīng)該說協(xié)議棧的每層或者說每部分都有相關(guān)的API說明文檔。osalAddTasks()初始化任務(wù)，osalTaskAdd()函數(shù)添加任務(wù)，都可以到API文檔或程序中詳細分析函數(shù)功能。

1.2.3、系統(tǒng)服務(wù)

OSAL和APL系統(tǒng)服務(wù)是唯一的，因為比如按鍵和串口類似事件處罰就只能用唯一的一個任務(wù)標識。這兩個硬件都留給了用戶自己定義使用。1.2.4、應(yīng)用設(shè)計

用戶可能為每一個應(yīng)用對象都創(chuàng)建一個任務(wù)，或者為所有的應(yīng)用對象只創(chuàng)建一個任務(wù)。當選擇上述的設(shè)計的時候，下面是一些設(shè)計思路：1.2.4.1、為許多應(yīng)用對象創(chuàng)建一個OSAL任務(wù)

下面是正面和反面（pros&cons）的一些敘述：

-Pro：接受一個互斥任務(wù)事件（開關(guān)按下或串口）時，動作是單一的。-Pro：需要堆棧空間保存一些OSAL任務(wù)結(jié)構(gòu)。

-Con：接收一個AF信息或一個AF數(shù)據(jù)確認時，動作是復(fù)雜的-----在一個用戶任務(wù)上，分支多路處理應(yīng)用對象的信息事件。-Con：通過匹配描述符（如：自動匹配）去發(fā)現(xiàn)服務(wù)的處理過程更復(fù)雜-----為了適當?shù)膶�ZDO_NEW_DSTADDR信息起作用，一個靜態(tài)標志必須被維持。1.2.4.2、為一個應(yīng)用對象創(chuàng)建一個OSAL任務(wù)

一對一設(shè)計的反面和正面（pros&cons）是與上面一對多設(shè)計相反的：-Pro：在應(yīng)用對象試圖自動匹配時，僅僅一個ZDO_NEW_DSTADDR被接收。

-Pro：已經(jīng)被協(xié)議棧下層多元處理后的一個AF輸入信息或一個AF數(shù)據(jù)確認。

-Con：需要堆�？臻g保存一些OSAL任務(wù)結(jié)構(gòu)。

-Con：如果兩個或更多應(yīng)用對象用同一個唯一的資源，接收一個互斥任務(wù)事件的動作就更復(fù)雜。1.2.5、強制方法

任何一個OSAL任務(wù)必須用兩種方法執(zhí)行：一個是初始化，另一個是處理任務(wù)事件。

1.2.5.1、任務(wù)初始化

在例子中調(diào)用如下函數(shù)執(zhí)行任務(wù)初始化：—ApplicationName‖_Init（如SAPI_Init）。該任務(wù)初始化函數(shù)應(yīng)該完成如下功能：

變量或相應(yīng)應(yīng)用對象特征初始化，為了使OSAL內(nèi)存管理更有效，在這里應(yīng)該分配永久堆棧存儲區(qū)。

在AF層登記相應(yīng)應(yīng)用對象（如：afRegister()）。

登記可用的OSAL或HAL系統(tǒng)服務(wù)（如：RegisterForKeys()）1.2.5.2、任務(wù)事件處理

調(diào)用如下函數(shù)處理任務(wù)事件：

—ApplicationName‖_ProcessEvent(e.g.SAPI_ProcessEvent()).除了強制的事件之外，任一OSAL任務(wù)能被定義多達15個任務(wù)事件。1.2.6、強制事件

一個任務(wù)事件SYS_EVENT_MSG(0x8000),被保留必須通過OSAL任務(wù)設(shè)計。

2.2.6.1、SYS_EVENT_MSG(0x8000)

任務(wù)事件管理者應(yīng)該處理如下的系統(tǒng)信息子集，下面只列出了部分信息，但是是最常用的幾個信息處理，推薦根據(jù)例子復(fù)制到自己項目中使用。1.2.6.1.1、AF_DATA_CONFIRM_CMD

調(diào)用AF_DataRequest()函數(shù)數(shù)據(jù)請求成功的指示。Zsuccess確認數(shù)據(jù)請求傳輸成功，如果數(shù)據(jù)請求設(shè)置AF_ACK_REQUEST標志位，那么，只有最終目的地址成功接收后，Zsuccess確認才返回。如果如果數(shù)據(jù)請求沒有設(shè)置AF_ACK_REQUEST標志位，那么，數(shù)據(jù)請求只要成功傳輸?shù)较绿��?jié)點就返回Zsuccess確認信息。

1.2.6.1.2、AF_INCOMING_MSG_CMD

AF信息輸入指示1.2.6.1.3、KEY_CHANGE

鍵盤動作指示

1.2.6.1.4、ZDO_NEW_DSTADDR

匹配描述符請求（MatchDeorRequest）響應(yīng)指示。（例如：自動匹配）1.2.6.1.5、ZDO_STATE_CHANGE

網(wǎng)絡(luò)狀態(tài)改變指示1.3、網(wǎng)絡(luò)格式化

示例應(yīng)用程序編譯為協(xié)調(diào)器的在default_chanlist指定的通道上形成一個網(wǎng)絡(luò)，協(xié)調(diào)器將建立一個隨機編號源于自身的IEEE地址或由zdapp_config_pan_id指定的網(wǎng)絡(luò)PANID（如果zdapp_config_pan_id不為0xFFFF）。

示例應(yīng)用程序編譯為路由器或結(jié)束設(shè)備的將嘗試加入網(wǎng)絡(luò)在default_chanlist指定的通道上，如果zdapp_config_pan_id沒有定義為0xFFFF，路由器將受到限制，只有加入?yún)��?shù)zdapp_config_pan_id規(guī)定的網(wǎng)絡(luò)PANID。1.3.1、自動啟動

設(shè)備自動開始嘗試組建或加入網(wǎng)絡(luò)。如果設(shè)備設(shè)置為等待計時器或其他外部事件發(fā)生后才啟動，那么HOLD_AUTO_START必須被定義。為了稍后以手動啟動方式啟動設(shè)備，那么需要調(diào)用ZDApp_StartUpFromApp(函數(shù)

1.3.2、軟件啟動

為了在形成網(wǎng)絡(luò)過程中節(jié)省所需的設(shè)備類型，那么所有的路由器設(shè)備可以被通過soft_star定義作為一個協(xié)調(diào)器。如果自動啟動是需要的話，那么auto_soft_start必須被定義。1.3.3、網(wǎng)絡(luò)恢復(fù)

通過設(shè)置NV_RESTORE和/或NV_INIT，可以讓設(shè)備斷電或者意外掉電重新啟動后重新回復(fù)網(wǎng)絡(luò)。1.3.4、加入通告

當設(shè)備形成或加入網(wǎng)絡(luò)后會發(fā)通報到ZDO_STATE_CHANGE信息事件。

學(xué)Z-Stack之4

SampleApplication分析（下）

上節(jié)介紹了建立一個應(yīng)用需要做的幾個必須的事情，現(xiàn)在就來通過分析SampleApplication來具體看看需要做哪些事情，才能建立一個ZIGBEE應(yīng)用功能。當然這里只是做點簡單的必須的工作。TheSampleApplication(SampleApp)1、介紹

主要是介紹一個應(yīng)用建立的結(jié)構(gòu)及需要進行的程序流程。1.1、程序流程1.1.1、初始化

首先需要調(diào)用初始化函數(shù)SampleApp_Init()。SampleApp_TaskID=task_id;初始化應(yīng)用建立的任務(wù)ID號，其實用過OS的人都應(yīng)該曉得這個是干啥的，我沒用過，不是很理解，但是我知道是必須的，就相當于一個任務(wù)的標識，這樣才能區(qū)分運行過程中不同任務(wù)中的不同事件。我是這么認為的，ID說白了就是給該任務(wù)取了各名字，就向人名字一樣，區(qū)分不同的人，就是一個代號。人名可以重復(fù)，重復(fù)了有時候叫起來就容易混淆；所以才程序中為了避免這種混淆，就強制性的規(guī)定任務(wù)ID不能重復(fù)。要是哪天國家或者聯(lián)合國姓名管理委員會規(guī)定，人民不能重復(fù)，那么這個人名就需要全球統(tǒng)一管理了。那給娃取個名字就要向聯(lián)合國姓名管理委員會申請了。呵呵！

SampleApp_NwkState=DEV_INIT;

初始化應(yīng)用設(shè)備的網(wǎng)絡(luò)狀態(tài)。怎么說呢，據(jù)說是設(shè)備類型的改變都要產(chǎn)生一個事件，叫ZDO_STATE_CHANGE，從字面理解為ZDO狀態(tài)發(fā)生了改變。所以在設(shè)備初始化的時候一定要把它初始化為什么狀態(tài)都沒有。那么它就要去檢測整個環(huán)境，看是否能重新建立或者加入存在的網(wǎng)絡(luò)。但是有一種情況例外，就是當NV_RESTORE被設(shè)置的時候（NV_RESTORE是把信息保存在非易失存儲器中），那么當設(shè)備斷電或者某種意外重啟時，由于網(wǎng)絡(luò)狀態(tài)存儲在非易失存儲器中，那么此時就只需要恢復(fù)其網(wǎng)絡(luò)狀態(tài)，而不需要重新建立或者加入網(wǎng)絡(luò)了。我也是從文檔中這么理解的，至于為什么只有有待進一步考證。

SampleApp_DstAddr.addrMode=(afAddrMode_t)AddrNotPresent;SampleApp_DstAddr.endPoint=0;

SampleApp_DstAddr.addr.shortAddr=0;看見這幾句話從字面理解為：初始化不標設(shè)備地址模式及目標設(shè)備EP號和網(wǎng)絡(luò)地址。從代碼可以看出，這些地址或EP均為0。也就是說目標設(shè)備為協(xié)調(diào)者的ZDO，這個意義就很明顯了，就是設(shè)備建立后可以直接與協(xié)調(diào)器的ZDO交互信息。

SampleApp_epDesc.endPoint=SAMPLEAPP_ENDPOINT;-----SampleAppEP描述符的EP號

SampleApp_epDesc.task_id=&SampleApp_TaskID;------SampleAppEP描述符的任務(wù)ID

SampleApp_epDesc.simpleDesc=------------------SampleAppEP簡單描述符SimpleDeionFormat_t*)&SampleApp_SimpleDesc;SampleApp_epDesc.latencyReq=noLatencyReqs;//在AF層中登記注冊改應(yīng)用EPafRegister(&SampleApp_epDesc);

這里其實是對SampleApp的EP描述符進行初始化。

本人理解：要對改應(yīng)用進行初始化并在AF進行登記，告訴應(yīng)用層有這么一個EP已經(jīng)可以使用，那么下層要是有關(guān)于改應(yīng)用的信息或者應(yīng)用要對下層做哪些操作，就自動得到下層的配合，至于這個配合是怎么回事，那么就需要好好研究下層的協(xié)議了。當然在這里肯定是沒那時間精力和能力研究了！

其實在這個應(yīng)用中，只是讓AF配合SAMPLEAPP_PROFID/SAMPLEAPP_ENDPOINT這兩個應(yīng)用。那么通過什么呢，通過發(fā)送OSALSYS_EVENT_MSG消息中的(AF_INCOMING_MSG_CMD)事件到SampleApp任務(wù)ID。

RegisterForKeys(SampleApp_TaskID);

登記按鍵事件到SampleApp_TaskID，在前面已經(jīng)說了按鍵這個是唯一的，也就是所有任務(wù)中有且只有各任務(wù)能登記鍵盤事件。前面還說了還有一個也是唯一，你猜是什么？

SampleApp_Group.ID=0x0001;

osal_memcpy(SampleApp_Group.name,—Group1‖);

aps_AddGroup(SAMPLEAPP_ENDPOINT,&SampleApp_Group);閃燈信息被發(fā)送到組1，同樣也只有在組1的設(shè)備才能接收這個信息。設(shè)備啟動時已經(jīng)被設(shè)定為組1設(shè)備了，但是可以通過按SW1推出/加入組1。這里提到了組的概念，我反正暫時不是很清楚這個是什么東西，在程序中怎么實現(xiàn)也很模糊，但是應(yīng)用中的好處還是不難想象的，不外呼是就是想控制誰可以事先規(guī)定好，還可以動態(tài)更改。1.2、事件處理

玩過OS的人都知道，OS中最重要的概念不外呼就是任務(wù)啦，消息啦，事件啦等。從我們自己平時的工作中也不難想象，如果老板安排了某項工作，那么我們就需要做的，這個工作可能是預(yù)先計劃好的，也有可能是臨時的，那么這些預(yù)先定好或者臨時的工作可以稱之為事件。而老板讓您做的方式，比如通過文件下達，或者叫：某某你把XXX做下。那么讓老板下達的文件內(nèi)容或者說的內(nèi)容我這里可以稱之為消息。老板給了你不同的消息那么就需要干不同的事件，至于任務(wù)可以理解為公司的不同的員工，呵呵！我簡直是理解的天才，這樣舉例居然也能忽悠通過�。�！o(∩_∩)o…哈哈

在Z-Stack中，每個應(yīng)用任務(wù)都通過SampleApp_ProcessEvent()函數(shù)來處理任務(wù)中的事件。一旦SampleApp_TaskID任務(wù)的某個OSAL事件發(fā)生，那么就可以通過調(diào)用SampleApp_ProcessEvent()函數(shù)來處理。在SampleApp_ProcessEvent()中有一個事件處理循環(huán)，循環(huán)檢測是哪個事件發(fā)生。if(events&SYS_EVENT_MSG){

MSGpkt=(afIncomingMSGPacket_t*)osal_msg_receive(SampleApp_TaskID);while(MSGpkt){

可以看到是通過檢測SYS_EVENT_MSG是否有事件信息發(fā)生。switch(MSGpkt->hdr.event)

這里是判斷SYS_EVENT_MSG事件類型，不同的SYS_EVENT_MSG類型需要不同的處理。caseKEY_CHANGE:

SampleApp_HandleKeys(((keyChange_t*)MSGpkt)->state,((keyChange_t*)MSGpkt)->keys);break;

比如這里判斷是否是鍵盤事件，如果鍵盤事件就調(diào)用鍵盤處理函數(shù)。

如果一個OSAL任務(wù)已經(jīng)被登記組側(cè)，那么任何鍵盤事件都將接受一個KEY_CHANGE事件信息�？赡苡腥缦聨追N方式得到鍵盤事件信息

1）、HAL檢測到鍵盤按下（中斷或者查詢檢測）2）、HAL的OSAL任務(wù)檢測到一個鍵盤狀態(tài)改變調(diào)用回叫函數(shù)產(chǎn)生3）、OSAL鍵盤改變回叫函數(shù)發(fā)送一個OSAL系統(tǒng)事件信息（KEY_CHANGE）。

caseAF_DATA_CONFIRM_CMD:

//ThestatusisofZStatus_ttype[definedinZComDef.h]//ThemessagefieldsaredefinedinAF.h

afDataConfirm=(afDataConfirm_t*)MSGpkt;sentEP=afDataConfirm->endpoint;sentStatus=afDataConfirm->hdr.status;sentTransID=afDataConfirm->transID;

任何AF_DataRequest()數(shù)據(jù)請求函數(shù)調(diào)用后，都通過AF_DATA_CONFIRM_CMD系統(tǒng)事件信息回叫返回成功Zsuccess。caseZDO_STATE_CHANGE:

SampleApp_NwkState=(devStates_t)(MSGpkt->hdr.status);if((SampleApp_NwkState==DEV_ZB_COORD)||(SampleApp_NwkState==DEV_ROUTER)

||(SampleApp_NwkState==DEV_END_DEVICE)){

//UpdatetheLCD’snetworkindicator

//Startsending"the"messageinaregularinterval.

osal_start_timer(SAMPLEAPP_SEND_PERIODIC_MSG_EVT,SAMPLEAPP_SEND_PERIODIC_MSG_TIMEOUT);}

break;

這里就是前面介紹的設(shè)備狀態(tài)改變事件處理了。只要網(wǎng)絡(luò)狀態(tài)發(fā)生改變，那么通過ZDO_STATE_CHANGE事件通知所有的任務(wù)。注意：在這個例子中，一旦設(shè)備成功加入網(wǎng)絡(luò)，是通過定時運行的方式運行的。一旦網(wǎng)絡(luò)狀態(tài)為加入‖JOINED‖,那么它可能不需要任何的認為操作就能綁定其他設(shè)備，因為設(shè)置為自動發(fā)現(xiàn)并綁定的。//Releasethememory

osal_msg_deallocate((uint8*)MSGpkt);釋放存儲空間。

if(events&SAMPLEAPP_SEND_PERIODIC_MSG_EVT){

//Send"the"message

SampleApp_SendPeriodicMessage();//Setuptosendmessageagain

osal_start_timer(SAMPLEAPP_SEND_PERIODIC_MSG_EVT,SAMPLEAPP_SEND_MSG_TIMEOUT);//returnunprocessedevents

return(events^SAMPLEAPP_SEND_PERIODIC_MSG_EVT);}

這里檢測事件是否為周期發(fā)送信息事件。

在SampleApp.h中定義了：

#defineSAMPLEAPP_SEND_PERIODIC_MSG_EVT0x0001

在這個應(yīng)用中，調(diào)用了osal_start_timer()函數(shù)來定時產(chǎn)生發(fā)送周期信息事件。而定時器的運行是設(shè)備一旦加入網(wǎng)絡(luò)就不停的在運行。從上面可以看到，用函數(shù)SampleApp_SendPeriodicMessage()發(fā)送周期信息，而用函數(shù)osal_start_timer(SAMPLEAPP_SEND_PERIODIC_MSG_EVT,SAMPLEAPP_SEND_MSG_TIMEOUT)來繼續(xù)運行定時器定時發(fā)送這個周期信息。關(guān)于這個osal_start_timer可以多了解下，第一個參數(shù)SAMPLEAPP_SEND_PERIODIC_MSG_EVT四信息時間，也就是事件到了產(chǎn)生一個什么事件。第二各參數(shù)SAMPLEAPP_SEND_MSG_TIMEOUT是需要定時的時間，這里就是發(fā)送周期信息的時間周期。1.3、消息流程

通過OSAL定時器，這個應(yīng)用定時發(fā)送一個周期信息：voidSampleApp_SendPeriodicMessage(void){

afAddrType_tdstAddr;

dstAddr.addrMode=afAddrBroadcast;

dstAddr.addr.shortAddr=0xFFFF;//廣播發(fā)送dstAddr.endpoint=SAMPLEAPP_ENDPOINT;

if(AF_DataRequest(&dstAddr,&SampleApp_epDesc,SAMPLEAPP_PERIODIC_CLUSTERID,(uint8)sampleAppPeriodicCounter++,(uint8*)&sampleAppPeriodCounter,&SampleApp_TransID,AF_DISCV_ROUTE,

AF_DEFAULT_RADIUS)==afStatus_SUCCESS){

//Successfullyrequestedtobesent.----發(fā)送成功處理}else{

//Erroroccurredinrequesttosend.---發(fā)送失敗處理}}

在這里調(diào)用了AF_DataRequest()函數(shù)用來發(fā)送數(shù)據(jù)。關(guān)于發(fā)送數(shù)據(jù)的具體過程這里就不做深入研究，不外乎就是把數(shù)據(jù)從應(yīng)用層傳到網(wǎng)絡(luò)層，在傳到MAC，在傳到無力層，最后通過OTA發(fā)送出去。接收數(shù)據(jù)就是相反的過程了，那么接收之后，在應(yīng)用層有什么反應(yīng)呢，最直觀的反應(yīng)就是會發(fā)送一個AF_INCOMING_MSG_CMD消息事件。caseAF_INCOMING_MSG_CMD:

SampleApp_MessageMSGCB(MSGpkt);break;

這里表示收到某個信息，然后在里面調(diào)用了收到信息的信息處理函數(shù)SampleApp_MessageMSGCB(MSGpkt)。

voidSampleApp_MessageMSGCB(afIncomingMSGPacket_t*pkt){

switch(pkt->clusterId){

caseSAMPLEAPP_PERIODIC_CLUSTERID:

//DisplayandincrementacounterontheLCDintheperiodicspacebreak;

caseSAMPLEAPP_FLASH_CLUSTERID:

flashTime=BUILD_UINT16(pkt->cmd.Data[1],pkt->cmd.Data[2]);HalLedBlink(HAL_LED_4,4,50,(flashTime/4));break;}}

這里判斷了兩種信息：周期信息閃燈信息

不同的信息就相當于收到了不同的命令，然后根據(jù)不同的命令做出了不同的處理。是個會寫程序都明白！�。�！

到這里，我就基本上把這個應(yīng)用文檔看完了，至于理解了多少我迷糊，理解正確了多少我更加迷糊，反正我按照我自己的方式理解了！

學(xué)Z-Stack之5

前面雖然寫了不少，但是回頭看看大多都是廢話，不過也沒辦法，沒有廢話的潤色就太枯燥了，太技術(shù)化了，這個不是我的本意。不知道前面寫的怎么樣，技術(shù)含量肯定是不高的。這個本人是相當清楚，但是我最大的期望就是錯誤不要太多！

突然想起來前面有個問題沒有解決，我想很多人看到那里都很郁悶的。就是設(shè)備類型的選擇，在TI原裝系統(tǒng)上是通過板載跳線來選擇的，但是我這里不是采用原裝，那么就需要通過程序來修改其設(shè)備類型，然后編譯下載。具體程序段如下：

#ifdefined(SOFT_START)if(readCoordinatorJumper())

zgDeviceLogicalType=ZG_DEVICETYPE_COORDINATOR;else

zgDeviceLogicalType=ZG_DEVICETYPE_ROUTER;#endif//SOFT_START

這里有個條件編譯，其條件編譯設(shè)置如圖5-1。圖5-1

既然這里設(shè)置了SOFT_START，那么上段程序就要被編譯。那么第一句程序if(readCoordinatorJumper())

就是檢測跳線，其實稍微知道編程的都了解怎么修改了，哈哈！屏蔽：

if(readCoordinatorJumper())

zgDeviceLogicalType=ZG_DEVICETYPE_COORDINATOR;else

這3句，那么就只剩下：zgDeviceLogicalType=ZG_DEVICETYPE_ROUTER;了

那么編譯自然該設(shè)備就為路由器了。簡單吧�。。。�？？！協(xié)調(diào)器我就不想多說怎么做了哈！�。。。。。。。。。�！

還有一個問題需要說下,就是Ti原裝的EM板子用到了LCD，所以在程序中可能在某個地方要對LCD初始化，那么如果沒有液晶的板子或者與TI那個不完全一樣的LCD就有可能運行不走，通俗的解決辦法是禁止LCD初始化等操作，Ti在這個方面做的很人性化，禁止LCD功能沒有必要在程序中找到LCD相關(guān)程序刪除，而是僅僅需要通過條件編譯來禁止。顯得相當簡單，如5-2圖就是禁止LCD的條件編譯。圖5-2

解決這個問題后一般都能夠運行程序了。也就是說到這里如果還把Demo程序運行不起來的話，那就證明我所有的東西都白寫了，反正我到這里我的Demo程序已經(jīng)運行如飛了。

那么接下來就是來看看Z-Stack具體的一些東西了，我打算先這樣看起：1、Z-Stack的結(jié)構(gòu)，因為打開Z-Stack的目錄可以看出還是比較復(fù)雜的，只有比較清楚了解其結(jié)構(gòu)之后呢，在程序運行或者修改中才能順利的找到自己想要的部分。

2、Z-Stack的應(yīng)用建立。就是怎么在TI提供的協(xié)議（裸協(xié)議）上建立一個應(yīng)用。這個層次要求就比較高了，我初步的設(shè)想是希望能分析完SAMPLE例子的應(yīng)用就能自己建立，而不需要太多的去了解下層的協(xié)議。但是往往希望與現(xiàn)實是有偏差的，走一步算一步了。

3、了解硬件相關(guān)設(shè)定、驅(qū)動。也就是說把例子跑通了，畢竟是基于TI的硬件，或者說基于開發(fā)系統(tǒng)的硬件，如果要做自己的應(yīng)用，那么必須要開發(fā)自己的硬件。怎么把自己的硬件驅(qū)動加入?yún)f(xié)議，這個我想也是需要解決的問題。

4、接下來可能就要深入分析協(xié)議了，這個目前我還不清楚從什么地方看起，因為畢竟對ZIGBEE這個協(xié)議本身就不太了解，但是在學(xué)習過程中應(yīng)該會慢慢對它有認識。所以到了這一步的時候說不定我就已經(jīng)摸索出一條方法了---畢竟俺是相當?shù)穆斆髀铮?/p>

5、需要解決的問題，需要了解的東西很多，對于不太了解這個東西的我來說，不可能非常有計劃并統(tǒng)籌安排這些事，走彎路是必然的，但是我一致認為走彎路才是經(jīng)驗的積累！學(xué)習Z-Stack之6

--------------Z-Stack指導(dǎo)

首先來看看Z-Stack的結(jié)構(gòu)。

第一次打開工程印象最深刻的就是左邊一排文件夾，如圖6-1所示。

其實這個還是很容易理解的：

APP（ApplicationProgramming）：應(yīng)用層目錄，這是用戶創(chuàng)建各種不同工程的區(qū)域，在這個目錄中包含了應(yīng)用層的內(nèi)容和這個項目的主要內(nèi)容，在協(xié)議棧里面一般是以操作系統(tǒng)的任務(wù)實現(xiàn)的。

HAL（Hardware(H/W)AbstractionLayer）：硬件層目錄，包含有與硬件相關(guān)的配置和驅(qū)動及操作函數(shù)。

MAC：MAC層目錄，包含了MAC層的參數(shù)配置文件及其MAC的LIB庫的函數(shù)接口文件。

MT（MonitorTest）：實現(xiàn)通過串口可控各層，于各層進行直接交互。NWK（ZigBeeNetworkLayer）：網(wǎng)絡(luò)層目錄，含網(wǎng)絡(luò)層配置參數(shù)文件及網(wǎng)絡(luò)層庫的函數(shù)接口文件，APS層庫的函數(shù)接口

OSAL（OperatingSystem(OS)AbstractionLayer）：協(xié)議棧的操作系統(tǒng)。Profile：AF（Applicationwork）層目錄，包含AF層處理函數(shù)文件。Security：安全層目錄，安全層處理函數(shù)，比如加密函數(shù)等。

Services：地址處理函數(shù)目錄，包括著地址模式的定義及地址處理函數(shù)。Tools：工程配置目錄，包括空間劃分及ZStack相關(guān)配置信息。ZDO（ZigBeeDeviceObjects）：ZDO目錄。

ZMac：MAC層目錄，包括MAC層參數(shù)配置及MAC層LIB庫函數(shù)回調(diào)處理函數(shù)。ZMain：主函數(shù)目錄，包括入口函數(shù)及硬件配置文件。Output：輸出文件目錄，這個EW8051IDE自動生成的。

那么知道各個文件夾大概是什么功能，分布在ZIGBEE的哪一層，那么在以后的工作中無論是查詢某些功能函數(shù)還是修改某些功能函數(shù)，甚至是添加或刪除某些功能函數(shù)就能順利的找到在什么地方了，當然要想真的順利還需要花更多的時間熟悉這個協(xié)議棧了！

了解Z-Stack結(jié)構(gòu)后那么就能看看它的功能。

不用問，這個是針對ZIGBEE無線網(wǎng)絡(luò)寫的協(xié)議棧，呵呵！那么就要先大概了解下ZIGBEE這個技術(shù)。我這里就不介紹理論了，就從Z-Stack實際的角度介紹些實用的概念。

1、Zigbee網(wǎng)絡(luò)中的節(jié)點

在ZB網(wǎng)絡(luò)中，每個節(jié)點都有指定的配置參數(shù)，從而確定其設(shè)備類型，不同的設(shè)備類型，在網(wǎng)絡(luò)中有著不一樣網(wǎng)絡(luò)任務(wù)。在屬于多跳網(wǎng)絡(luò)的ZB網(wǎng)絡(luò)中，兩個節(jié)點需要完成數(shù)據(jù)傳輸，可能需要經(jīng)過其他中間節(jié)點的協(xié)助，所以節(jié)點的類型參數(shù)配置是非常必要的。對每個節(jié)點有兩個任務(wù)：

（i）執(zhí)行指定的網(wǎng)絡(luò)功能函數(shù)

（ii）配置確定的參數(shù)到指定的值。

網(wǎng)絡(luò)功能的設(shè)置確定了該節(jié)點的類型，參數(shù)配置和指定的值確定了堆棧的模式。

節(jié)點類型

在ZB中，設(shè)備類型分為三類：協(xié)調(diào)器，路由器和終端設(shè)備。圖6-2就是這三種設(shè)備類型組成的一個典型網(wǎng)絡(luò)。

其中黑色節(jié)點為協(xié)調(diào)器紅色節(jié)點為路由器白色節(jié)點為終端設(shè)備

那么這個就是一個典型的網(wǎng)狀網(wǎng)絡(luò)MESH。

協(xié)調(diào)器

協(xié)調(diào)器是一個ZB網(wǎng)絡(luò)的第一個開始的設(shè)備，或者是一個ZB網(wǎng)絡(luò)的啟動或建立網(wǎng)絡(luò)的設(shè)備。協(xié)調(diào)器節(jié)點選擇一個信道和網(wǎng)絡(luò)標志符（也叫PANID），然后開始建立一個網(wǎng)絡(luò)。協(xié)調(diào)器設(shè)備在網(wǎng)絡(luò)中還可以有其他作用，比如建立安全機制、網(wǎng)絡(luò)中的綁定的建立等等。注意：協(xié)調(diào)器主要的作用是建立一個網(wǎng)絡(luò)和配置該網(wǎng)絡(luò)的性質(zhì)參數(shù)。一旦這些完成，該協(xié)調(diào)器就如同一個路由器，網(wǎng)絡(luò)中的其他操作并不依賴該協(xié)調(diào)器，因為ZB是分布式網(wǎng)絡(luò)。

路由器

一個路由器的功能有（1）作為普通設(shè)備加入網(wǎng)絡(luò)（2）多跳路由（3）輔助其它的子節(jié)點完成通信。

一般來說，路由器需要一直處于工作狀態(tài)，所以需要主干線供電（區(qū)別于電池供電）。但是在某指定的網(wǎng)絡(luò)結(jié)構(gòu)中可以采用電池供電，如—串樹型‖網(wǎng)絡(luò)模式中，允許路由器周期的運行操作，所以可以采用電池供電。

終端設(shè)備

為了維持網(wǎng)絡(luò)最基本的運行，對于終端設(shè)備沒有指定的責任。也就是說，在一個基本網(wǎng)絡(luò)中，終端設(shè)備沒有必不可缺少性。所以它可以根據(jù)自己功能需要休眠或喚醒，因此為電池供電設(shè)備。一般來說，該設(shè)備需要的內(nèi)存較少（特別是內(nèi)部RAM）

堆棧模式（StackProfile）

需要被配置為指定值的堆棧參數(shù)，連同這些值被稱為堆棧模式。這些堆棧模式參數(shù)被ZB聯(lián)盟定義指定。在同一個網(wǎng)絡(luò)中的設(shè)備必須符合同一個堆棧模式（同一個網(wǎng)絡(luò)中所有設(shè)備的堆棧模式配置參數(shù)必須一致）。

為了互操作性，ZB聯(lián)盟為06協(xié)議棧定義了一個堆棧模式，所有的設(shè)備只要遵循該模式的參數(shù)配置，即使在不同廠商買的不同設(shè)備同樣可以形成網(wǎng)絡(luò)。

如果應(yīng)用開發(fā)者改變了這些參數(shù)配置，那么他的產(chǎn)品將不能與遵循ZB聯(lián)盟定義模式的產(chǎn)品組成網(wǎng)絡(luò)，也就是說該開發(fā)者開發(fā)的產(chǎn)品具有特殊性，我們稱之為—關(guān)閉的網(wǎng)絡(luò)‖，也就是說它的設(shè)備只有在自己的產(chǎn)品中使用，不能與其他產(chǎn)品通信。

該協(xié)議模式標志符在設(shè)備通信的信標傳輸中被匹配，如果不匹配，那么該設(shè)備將不能加入網(wǎng)絡(luò)�！�關(guān)閉網(wǎng)絡(luò)‖的堆棧模式有一個0ID，而06協(xié)議棧模式有一個1ID。該堆棧模式被配置在nwk_globals.h文件中的STACK_PROFILE_ID參數(shù)。如：

#defineSTACK_PROFILE_IDHOME_CONTROLS。

2、Zigbee網(wǎng)絡(luò)中的地址地址類型

ZB設(shè)備有兩種地址類型，一個是64位IEEE地址（也可以叫MAC地址或擴展地址），一個是16位網(wǎng)絡(luò)地址（也可以叫邏輯地址或短地址）。

64位地址是全球唯一的，作為設(shè)備（產(chǎn)品）的終生地址被分配。它通常被開發(fā)商或安裝的時候被指定。該地址由IEEE分配指定，該地址的信息和獲得該地址的方法見：

16位地址在設(shè)備加入網(wǎng)絡(luò)的時候被分配，由這個網(wǎng)絡(luò)自動分配。該地址只能用與本網(wǎng)絡(luò)中，標志不同的設(shè)備間傳遞信息。

網(wǎng)絡(luò)地址分配

ZB分布式網(wǎng)絡(luò)中地址分配是唯一的。為了不使網(wǎng)絡(luò)中設(shè)備混亂，為每個設(shè)備指定確定的地址是非常必要的。

在分配地址之前，一些參數(shù)必須被設(shè)置：MAX_DEPTH,MAX_ROUTERS和MAX_CHILDREN。

這些參數(shù)都是ZB協(xié)議模式的一部分，在06ZS模式中這些參數(shù)設(shè)置為：(MAX_DEPTH=5,MAX_CHILDREN=20,MAX_ROUTERS=6).

參數(shù)設(shè)置

MAX_DEPTH決定了網(wǎng)絡(luò)的最大深度。協(xié)調(diào)器的深度是0，它的子設(shè)備的深度是1，他們的子設(shè)備的深度是2，依次類推。所以MAX_DEPTH參數(shù)限制了網(wǎng)絡(luò)物理上的—長度‖

MAX_CHILDREN參數(shù)決定了一個路由器（或一個協(xié)調(diào)器）能承載子設(shè)備的最大數(shù)目。MAX_ROUTERS參數(shù)決定了一個路由器（或一個協(xié)調(diào)器）能承載路由器的最大數(shù)目。這個參數(shù)實際上是MAX_CHILDREN參數(shù)的一個子集，剩下的（MAX_CHILDREN-MAX_ROUTERS）地址空間屬于終端設(shè)備。

開發(fā)者自定義

如果開發(fā)者想改變這些值，那么需要做如下幾步：

首先得保證這些參數(shù)新的值是合法的。既然整個地址空間被限制在2-16內(nèi)，那么這些參數(shù)的大小就已經(jīng)有了限制。分布在release（在文件夾Projects\\zstack\\Tools中）的Cskip.xls文件能校驗這些參數(shù)是否合法。在鍵入這些參數(shù)的值后大概這個電子表格，如果非法，一個錯誤信息將給出。

之后選擇合法的值，開發(fā)者需要確保不使用標準的協(xié)議棧模式，而用指定的協(xié)議棧模式代替（用NETWORK_SPECIFIC替換STACK_PROFILE_ID當前的值）。然后在—nwk_globals.h‖文件中的MAX_DEPTH參數(shù)根據(jù)需要設(shè)置為適當?shù)闹怠?/p>

另外，nwk_globals.c文件中排列的CskipChldrn和CskipRtrs必須被設(shè)置，這些排列是

z-stack中的尋址

為了在網(wǎng)絡(luò)中發(fā)送數(shù)據(jù)到一個設(shè)備，應(yīng)用層一般用AF_DataRequest()函數(shù)。而被發(fā)送的目的設(shè)備的地址類型afAddrType_t被定義在—ZComDef.h‖中：typedefstruct{union{

uint16shortAddr;ZLongAddr_textAddr;}addr;

byteaddrMode;}zAddrType_t;

地址模式參數(shù)

注意：除這個網(wǎng)絡(luò)地址之外，地址模式參數(shù)也需要被指定。目的地址模式可能是如下值之一（AF地址模式被定義在—AF.h‖中）：typedefenum{

afAddrNotPresent=AddrNotPresent,afAddr16Bit=Addr16Bit,afAddrGroup=AddrGroup,

afAddrBroadcast=AddrBroadcast}afAddrMode_t;

地址模式參數(shù)是需要的，因為在ZB中，數(shù)據(jù)包能被點傳輸、多點傳輸或者廣播傳輸。點傳輸被發(fā)送到單個設(shè)備，多點傳輸一定發(fā)送到一組設(shè)備，廣播傳輸一般被發(fā)送到網(wǎng)絡(luò)中的所有設(shè)備。如下是更詳細的說明。

點到傳輸（Unicast）

這是標準地址模式，被用于發(fā)送一個數(shù)據(jù)包到網(wǎng)絡(luò)中單個已知地址的設(shè)備。這個addrMode參數(shù)被設(shè)置為Addr16Bit，目的網(wǎng)絡(luò)地址在數(shù)據(jù)包中一同被發(fā)送。

間接尋址

數(shù)據(jù)包中的最終目的地址不識別的時候使用。該模式被AddrNotPresent設(shè)置，而且目的地址沒有被指定。代替目的地址的是：一個存儲在發(fā)送設(shè)備協(xié)議棧的—綁定表格‖，該表格中有被綁定設(shè)備的地址。這個特性被調(diào)用是源于綁定。（看后面關(guān)于綁定部分）當被發(fā)送的信息包下載到協(xié)議棧時，從這個綁定表格中尋找使用的目的地址。然后該信息包被有規(guī)則的處理為點對點數(shù)據(jù)包。如果有多個（大于1）目的地址在綁定表格中被發(fā)現(xiàn)，那么該數(shù)據(jù)包將被拷貝成對應(yīng)的份數(shù)分別發(fā)送給他們。

在(ZigBee04)版本之前，在協(xié)調(diào)器中有一個存儲綁定表格的選項。因此，發(fā)送設(shè)備發(fā)送數(shù)據(jù)包到這個協(xié)調(diào)器，然后協(xié)調(diào)器在它的綁定表格中查找最終的目的地址，對數(shù)據(jù)包進行在一次發(fā)送。該選項特性在協(xié)調(diào)器綁定被調(diào)用

廣播傳輸

該模式在應(yīng)用層想發(fā)送一個數(shù)據(jù)包到所有網(wǎng)絡(luò)中的所有設(shè)備時被使用。該地址模式被AddrBroadcast被設(shè)置，目的地址被設(shè)置為下列值之一：

NWK_BROADCAST_SHORTADDR_DEVALL(0xFFFF)-信息將被發(fā)送到網(wǎng)絡(luò)中的所有設(shè)備（包括休眠的設(shè)備）。對于休眠的設(shè)備，這個信息將被保持在它的父節(jié)點，直到該休眠設(shè)備獲得該信息或者該信息時間溢出（在f8wConfig.cfg中的NWK_INDIRECT_MSG_TIMEOUT選項）。

NWK_BROADCAST_SHORTADDR_DEVRXON(0xFFFD)該信息將被發(fā)送到網(wǎng)絡(luò)中有接收器并處于IDLE(RXONWHENIDLE)狀態(tài)下的所有設(shè)備。也就是說，除了休眠模式設(shè)備的所有設(shè)備。

NWK_BROADCAST_SHORTADDR_DEVZCZR(0xFFFC)該信息被發(fā)送到所有路由器（包括協(xié)調(diào)器）。

組地址

該模式用于應(yīng)用層想發(fā)送一個數(shù)據(jù)包到一個設(shè)備組的時候。該地址模式被afAddrGroup設(shè)置這個組標志符。

用該特性之前，在網(wǎng)絡(luò)中，組不得不被定義[看ZStackAPI文檔中的]aps_AddGroup()注意：組能與間接尋址一起結(jié)合使用。該目的地址在綁定表格中發(fā)現(xiàn)，可以作為點對點或一個組地址。也要注意廣播地址可以當作是組被提前設(shè)置，一個簡單的組尋址的特例，。例子代碼對于一個設(shè)備添加它自己到一個組標志符1：aps_Group_tgroup;

//Assignyourselftogroup1group.ID=0x0001;

group.name[0]=0;//Thiscouldbeahumanreadablestringaps_AddGroup(SAMPLEAPP_ENDPOINT,&group);

重要設(shè)備地址

一個應(yīng)用可以能想知道它自身和父節(jié)點的地址，用下面的函數(shù)可以得到設(shè)備的地址（被定義在ZStackAPI文檔中）：

NLME_GetShortAddr()返回該設(shè)備的16位網(wǎng)絡(luò)地址NLME_GetExtAddr()返回該設(shè)備的64位擴展地址.

用下面的函數(shù)可以得到該設(shè)備的父節(jié)點的地址（被定義在ZStackAPI文檔中）。注意該函數(shù)在協(xié)調(diào)器中不被涉及到，但是被設(shè)備父節(jié)點代替（MAC協(xié)調(diào)器）：

NLME_GetCoordShortAddr()returnsthisdevice’sparent’s16bitshortaddress.NLME_GetCoordExtAddr()returnsthisdevice’sparent’s64bitextendedaddress.先介紹這兩個概念：節(jié)點和地址。其余的就改天繼續(xù)！

學(xué)習Z-Stack之7--------------Z-Stack指導(dǎo)2

上節(jié)介紹了很大一部分Z-Stack的基礎(chǔ)知識，這里接著忽悠。雖然說的不是很專業(yè)也不是很通俗，但是我盡力了，希望有人能看明白！本人英文水平有限，翻譯的不好請諒解！3、綁定

綁定是控制信息從一個應(yīng)用層到另一個應(yīng)用層流動的一種機制。在ZB06版本中，綁定機制在所有的設(shè)備中被執(zhí)行。

綁定允許應(yīng)用層發(fā)送信息不需要帶目的地址，APS層確定目的地址從他的綁定表格中，然后在信息前端加上這個目的地址或組。

注意：在ZB1.0版本中，所有綁定條目存儲在協(xié)調(diào)器中�，F(xiàn)在所有綁定條目存儲在發(fā)送數(shù)據(jù)的設(shè)備中。3.1綁定一個綁定表格

有三種方式建立一個綁定表格：

ZDO綁定請求一個試運轉(zhuǎn)工具能告訴這個設(shè)備制作一個綁定報告。ZDO終端設(shè)備綁定請求2設(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.1ZDO綁定請求

通過調(diào)用函數(shù)ZDP_BindReq()發(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.2ZDO終端設(shè)備綁定請求

該機制是用一個按鈕按下或其他類似的動作來選擇設(shè)備在指定時間內(nèi)被綁定。在規(guī)定時間內(nèi)，該終端設(shè)備綁定請求信息被收集到協(xié)調(diào)器，并創(chuàng)建一個基于模式（profile）ID和串（cluster）ID的規(guī)定的綁定表格條目。默認的終端設(shè)備綁定超時時間（APS_DEFAULT_MAXBINDING_TIME）為16S（定義在nwk_globals.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é)調(diào)器將接收[ZDP_IncomingData()在ZDProfile.c]這些信息并分析處理[ZDO_ProcessEndDeviceBindReq()在ZDObject.c]這些信息并調(diào)用函數(shù)ZDApp_EndDeviceBindReqCB()[inZDApp.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ù)到moveontotheclusterIDforthefirstdevice(theunbindremovedtheentrytoggle).

3.等待ZDO綁定響應(yīng).Whenreceived,moveontothenextclusterIDforthefirstdevice.

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)存在的綁定記錄中增加一個群IDbindRemoveDev()刪除所有地址引用的記錄

bindRemoveSrcDev()刪除所有源地址引用的記錄bindUpdateAddr()將記錄更新為另一個地址bindFindExisting()查找一個綁定表記錄

bindIsClusterIdInList()在表記錄中檢查一個已經(jīng)存在的群IDbindNumBoundTo()擁有相同地址(源或者目的)的記錄的個數(shù)bindNumEntries()表中記錄的個數(shù)bindCapacity()最多允許的記錄個數(shù)bindWriteNV()在NV中更新表3.2配置源綁定

允許綁定源的編譯選項REFLECTOR在f8wConfig.cfg文件中。在文件f8wConfig.cfg,中查看這兩個綁定配置參數(shù)（NWK_MAX_BINDING_ENTRIES&MAX_BINDING_CLUSTER_IDS)。NWK_MAX_BINDING_ENTRIES綁定表格中最大的綁定實體數(shù)量參數(shù)；MAX_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ù)。4、路由4.1預(yù)覽

在MESH網(wǎng)絡(luò)中，為了使分布的節(jié)點間能夠很好的通信，路由是非常重要的一個環(huán)節(jié)。

在應(yīng)用層上路由是完全透明的。一個簡單的應(yīng)用數(shù)據(jù)發(fā)送到任意設(shè)備，下至協(xié)議棧，協(xié)議棧將負責發(fā)現(xiàn)一個路由路線。這個方式，應(yīng)用層是不知道該操作在多跳網(wǎng)絡(luò)中完成的事實。

路由使ZB網(wǎng)絡(luò)具有—自動復(fù)原‖的特性。如果一個無線連接斷了，路由功能將自動的發(fā)現(xiàn)一個新的路由路線，該路線是避開（繞過）壞了的那個連接節(jié)點。這就提高了無線網(wǎng)絡(luò)的可靠性，這也是ZB關(guān)鍵特點之一。4.2路由協(xié)議

ZB執(zhí)行的路由協(xié)議是基于AODV（AdhocOndemandDistanceVector）的路由協(xié)議。作為一個簡單的應(yīng)用---傳感器網(wǎng)絡(luò)，ZB路由協(xié)議支持環(huán)境中的移動節(jié)點，連接失敗和丟包功能。

當一個路由器接收到一個點對點信息包時，從他的應(yīng)用或者從其他設(shè)備，NWK層將繼續(xù)向前依照下面的進程。如果目的是路由器鄰節(jié)點（包括它的子設(shè)備）之一，該信息包將直接傳輸?shù)侥康脑O(shè)備。另外的就是，路由器將檢查它的路由表格，檢查相應(yīng)的信息包目的條目。如果在路由表格中有一個活躍的路由路線到該目的設(shè)備，那么該信息包將被轉(zhuǎn)播到下一跳節(jié)點地址存儲依照路由條目。如果沒有活躍的條目發(fā)現(xiàn)，那么一個路由發(fā)現(xiàn)被啟動并且該信息被緩存直到該過程完成。

ZB終端設(shè)備路由

ZB終端設(shè)備不能執(zhí)行任何路由功能。一個終端設(shè)備想發(fā)送一個信息包到任何設(shè)備都要向前到它的父設(shè)備，然后在由其父設(shè)備進行路由操作。類似的，任何設(shè)備想發(fā)送信息包到終端設(shè)備，都將發(fā)起一個路由發(fā)現(xiàn)操作，當然該操作都由終端設(shè)備的父設(shè)備響應(yīng)。

注意：ZB地址分配方案使基于它的地址發(fā)起一個路由到任何目的成為可能。在Z-Sstack，這個機制被用于萬一正規(guī)的路由程序不能被啟動，作為一個自動退卻（一般情況是由于路由表格空間不夠）。z-stack路由

在z-stack，執(zhí)行的路由是已經(jīng)被優(yōu)化的路由存儲表格。一般情況，對于每一個目的設(shè)備路由表格條目是需要的。但是通過綜合攜帶父節(jié)點所有條目的特定父節(jié)點的終端設(shè)備的所有條目，沒有任何功能丟失的存儲已經(jīng)被優(yōu)化。

ZB路由器，包括協(xié)調(diào)器，執(zhí)行如下路由功能(i)路由發(fā)現(xiàn)和選擇(ii)路由維護(iii)

4.2.1路由發(fā)現(xiàn)和選擇

路由發(fā)現(xiàn)是網(wǎng)絡(luò)設(shè)備協(xié)作發(fā)現(xiàn)和建立路由的一個過程。一個路由操作總是針對某個目的，通過任何一個路由器啟動。該路由發(fā)現(xiàn)機制在源設(shè)備和目的設(shè)備間搜尋所有可能的路由并試圖選擇最好的路由路線。

?路由選擇通過選擇最小消耗的路由路線。每個設(shè)備在連接到鄰節(jié)點幾乎保持不變的—連接消耗‖。該連接消耗是接收信號的強度的一個典型功能。沿著路由路線加起所有的連接消耗，就是整個路由的—連接消耗‖。路由算法試圖選擇這個路由最小的—路由消耗‖。路由請求

路由通過請求/響應(yīng)信息包被發(fā)現(xiàn)。一個源設(shè)備為了一個目的地址，通過發(fā)送一個廣播路由請求（RREQ）信息到它的鄰設(shè)備請求一個路由。當一個節(jié)點接收到一個RREQ信息時，它將依次轉(zhuǎn)播這個RREQ信息。但是在做這個之前，它更新RREQ信息的消耗域，通過增加連接消耗為了最后的連接。這樣，RREQ信息將攜帶向前傳輸?shù)乃�有的連接消耗。這個重復(fù)過程直到RREQ到達這個目的設(shè)備。RREQ的一些復(fù)制可能經(jīng)過不同的路徑重復(fù)到達目的設(shè)備。該目的設(shè)備選擇最好的RREQ信息并發(fā)送一個路由答復(fù)（RREP）返回到源設(shè)備。路由響應(yīng)

RREP是沿著唯一的相反的路徑返回到最初的請求節(jié)點。

作為RREP信息傳播回源節(jié)點，中間的節(jié)點更新他們的路由表格，指出路由路線到目的設(shè)備。

一旦一個路由被創(chuàng)建，數(shù)據(jù)包能被發(fā)送。當一個節(jié)點丟失到它下一個節(jié)點的連通性時（發(fā)送數(shù)據(jù)包時，它不能接收一個MAC應(yīng)答ACK），這個節(jié)點通過發(fā)送一個RERR到所有潛在的接收它RREP的節(jié)點，使該路由無效。在接收一個RREQ，RREP或RERR之上，這些節(jié)點都將更新他們的路由表格4.2.2路由維護

MESH網(wǎng)絡(luò)提供路由維護和自動修復(fù)。中間節(jié)點保持沿著連接傳輸失效的路徑。如故一個連接被確定壞了，逆流的節(jié)點將啟動路由修復(fù)那些連接的所有路由路線。這些工作通過啟動路由重新發(fā)送被做，為了路由下一次數(shù)據(jù)包接收。如果路由重新發(fā)現(xiàn)不能啟動，或者由于某些原因失敗了，一個路由錯誤（RERR）信息被發(fā)送到這個數(shù)據(jù)包的源設(shè)備，然后重新啟動新的路由發(fā)現(xiàn)。任意方式都使得該路由得到重新自動建立。4.2.3路由終結(jié)

為了建立路由，路由表格條目要被維護。如果一段時間沒有數(shù)據(jù)包沿著路由路線發(fā)送，該路由將被做終結(jié)記號。終止路由不是刪除直到空間需要時。因此沒有被刪除直到它完全需要時。自動路由終結(jié)時間能被配置—在f8wconfig.cfg"文件中‖。設(shè)置ROUTE_EXPIRY_TIME參數(shù)為終結(jié)時間（秒）。設(shè)置0為了關(guān)閉路由終結(jié)。4.3表格存儲

路由功能需要路由器維護一些表格：路由表格

路由發(fā)現(xiàn)表格4.3.1路由表格

每一個路由器包括協(xié)調(diào)器都包含一個路由表。設(shè)備在路由表中保存數(shù)據(jù)包參與路由所需的信息。每一條路由表記錄都包含有目的地址，下一級節(jié)點和連接狀態(tài)。所有的數(shù)據(jù)包都通過相鄰的一級節(jié)點發(fā)送到目的地址。同樣，為了回收路由表空間，可以終止路由表中的那些已經(jīng)無用的路徑記錄。

路由表的容量表明一個設(shè)備路由表擁有一個自由路由表記錄或者說它已經(jīng)有一個與目標地址相關(guān)的路由表記錄。在文件—f8wConfig.cfg‖文件中配置路由表的大小。將MAX_RTG_ENTRIES設(shè)置為表的大小(不能小于4)。4.3.2路由發(fā)現(xiàn)表格

路由器設(shè)備致力于路徑發(fā)現(xiàn)，保持維護路徑發(fā)現(xiàn)表。這個表用來保存路徑發(fā)現(xiàn)過程中的臨時信息。這些記錄只在路徑發(fā)現(xiàn)操作期間存在。一旦某個記錄到期，則它可以被另一個路徑發(fā)現(xiàn)使用。這個值決定了在一個網(wǎng)絡(luò)中，可以同時并發(fā)執(zhí)行的路徑發(fā)現(xiàn)的最大個數(shù)。這個可以在f8wConfig.cfg文件中配置MAX_RREQ_ENTRIES。4.4、路徑設(shè)置快速參考

設(shè)置路由表大小MAX_RTG_ENTRIES，這個值不能小于4(f8wConfig.cfg文件)

設(shè)置路徑期滿時間ROUTE_EXPIRY_TIME，單位秒。設(shè)置為零則關(guān)閉路徑期滿(f8wConfig.cfg文件)

設(shè)置路徑發(fā)現(xiàn)表大小MAX_RREQ_ENTRIES，網(wǎng)絡(luò)中可以同時執(zhí)行的路徑發(fā)現(xiàn)操作的個數(shù)

學(xué)習ZStack之8

近段時間比較忙，幾乎都快荒廢了Z-Stack的學(xué)習了，把以前學(xué)的都快忘記了，這就是非專業(yè)技術(shù)的痛苦�。�！學(xué)習剛好有點眉目，突然意外中斷停下，當再一次學(xué)習的時候突然發(fā)現(xiàn)：以前學(xué)的都忘了8成了！郁悶�。〗裉煺娌恢�道從什么地方下手學(xué)習了，所以就針對最近客戶比較關(guān)心的問題做點介紹，這樣有針對性、有目的性的學(xué)習可能最適合現(xiàn)在的我了，不然從頭把以前那些所謂的筆記看一遍，可能今天晚上又沒了，指不定明晚以及后晚以及后后晚…都沒時間，不然老是看以前的筆記沒有進展就麻煩了！呵呵！

今天只解決1個問題：TI提供的例子程序的表演及功能介紹。

因為最近問這些的客戶比較多，特別又是剛?cè)胧值呐笥眩瑢�Z-Stack非常迷糊的時期，如果能夠跑通幾個例子、看幾個演示，那么可以大大提高學(xué)習興趣；另外如果知道某個例子的大致功能及實現(xiàn)，那么在去看具體實現(xiàn)過程目的性就非常明確。

首先來看看TI究竟有哪些例子：

可以看出其例子是非常豐富的。

GenericApp，Location，SampleApp，SimpleApp，HomeAutomation，SerialApp，Transmit，

ZLOAD。這樣看來還是不少的。其中SampleApp例子已經(jīng)在前面的學(xué)習中有所涉及，可以說前面的所有學(xué)習都是基于這個例子的，所以這里就不測試它了。Location是定位的測試例子，這里我的硬件是不夠的，所以也不做測試。其他我都做點測試，能成功的就成功，不能成功的就失敗，這個我也沒辦法，呵呵�。。。。。。�！1、GenericApp

工程打開等我就不多說了，自己去找，如果連這些我都還說，那么我以前的東西是白學(xué)了。硬件連接中

當我用兩個節(jié)點分別燒寫入DB的協(xié)調(diào)器和路由器，從我的經(jīng)驗看來，他們分別能建立網(wǎng)絡(luò)和加入網(wǎng)絡(luò)，但是從表象上幾乎看不見數(shù)傳現(xiàn)象，盡管我按了每個節(jié)點的按鍵，也僅僅是本節(jié)點的LED在改變。唯獨有點數(shù)傳感覺的是：按鍵右鍵對方有反應(yīng)就是了，至于具體什么反映我覺得沒必要說明白，大家試試就知道了。

所以還決定看看程序來判斷這個例子的功能。

大約瀏覽了下，這個例子似乎還與設(shè)備的綁定有關(guān)系，因為在按建處理程序中發(fā)現(xiàn)：

if(keys&HAL_KEY_SW_2){

HalLedSet(HAL_LED_4,HAL_LED_MODE_OFF);

//InitiateanEndDeviceBindRequestforthemandatoryendpointdstAddr.addrMode=Addr16Bit;

dstAddr.addr.shortAddr=0x0000;//Coordinator

ZDP_EndDeviceBindReq(&dstAddr,NLME_GetShortAddr(),GenericApp_epDesc.endPoint,GENERICAPP_PROFID,GENERICAPP_MAX_CLUSTERS,(cId_t*)GenericApp_ClusterList,GENERICAPP_MAX_CLUSTERS,(cId_t*)GenericApp_ClusterList,FALSE);}

很明顯這里按鍵2（右鍵）是發(fā)送綁定請求的命令。if(keys&HAL_KEY_SW_4){

HalLedSet(HAL_LED_4,HAL_LED_MODE_OFF);

//InitiateaMatchDeionRequest(ServiceDiscovery)dstAddr.addrMode=AddrBroadcast;

dstAddr.addr.shortAddr=NWK_BROADCAST_SHORTADDR;

ZDP_MatchDescReq(&dstAddr,NWK_BROADCAST_SHORTADDR,GENERICAPP_PROFID,

GENERICAPP_MAX_CLUSTERS,(cId_t*)GenericApp_ClusterList,GENERICAPP_MAX_CLUSTERS,(cId_t*)GenericApp_ClusterList,FALSE);}

顯然按鍵4（左）是初始化一個匹配描述符請求，也就是發(fā)現(xiàn)服務(wù)，或者叫自動尋求匹配設(shè)備。這就不怪我按鍵有反映了！

而且在發(fā)送數(shù)據(jù)和接收數(shù)據(jù)處理函數(shù)發(fā)現(xiàn)：voidGenericApp_SendTheMessage(void){

chartheMessageData[]="HelloWorld";

if(AF_DataRequest(&GenericApp_DstAddr,&GenericApp_epDesc,GENERICAPP_CLUSTERID,

(byte)osal_strlen(theMessageData)+1,(byte*)&theMessageData,&GenericApp_TransID,AF_DISCV_ROUTE,AF_DEFAULT_RADIUS)==afStatus_SUCCESS){

//Successfullyrequestedtobesent.}else{

//Erroroccurredinrequesttosend.}}

居然發(fā)送的是一個字符串—HelloWorld‖。

voidGenericApp_MessageMSGCB(afIncomingMSGPacket_t*pkt){

switch(pkt->clusterId){

caseGENERICAPP_CLUSTERID://"the"message

#ifdefined(LCD_SUPPORTED)

HalLcdWriteScreen((char*)pkt->cmd.Data,"rcvd");#elifdefined(WIN32)

WPRINTSTR(pkt->cmd.Data);#endifbreak;}}

接收數(shù)據(jù)處理函數(shù)里居然要通過液晶顯示，本人這里的液晶暫時沒有移植過來，因為暫時還不具備那個實力，怪不得看不到發(fā)送數(shù)據(jù)的狀況！

這里本人就自作聰明的把以前SampleApp例子里面的一句話加過來了：voidGenericApp_MessageMSGCB(afIncomingMSGPacket_t*pkt){

switch(pkt->clusterId){

caseGENERICAPP_CLUSTERID://"the"messageHalLedBlink(HAL_LED_4,4,50,(500));#ifdefined(LCD_SUPPORTED)

HalLcdWriteScreen((char*)pkt->cmd.Data,"rcvd");#elifdefined(WIN32)

WPRINTSTR(pkt->cmd.Data);#endifbreak;}}

麼想到啊，這么一加居然就有反應(yīng)了，o(∩_∩)o…！我不愧是天才的接班人啊！其實這里很簡單的了，就是接收到數(shù)據(jù)后閃爍4下燈，間隔0.5S。因為從：if(events&GENERICAPP_SEND_MSG_EVT){

//Send"the"message

GenericApp_SendTheMessage();//Setuptosendmessageagain

osal_start_timerEx(GenericApp_TaskID,

GENERICAPP_SEND_MSG_EVT,

GENERICAPP_SEND_MSG_TIMEOUT);//returnunprocessedevents

return(events^GENERICAPP_SEND_MSG_EVT);}

這里可以看出，這個例子很明顯僅僅是個發(fā)送周期信息的例子。所以LED4就周期性的閃爍4下，當然是協(xié)調(diào)器發(fā)送，路由器閃爍，路由器發(fā)送，協(xié)調(diào)器閃爍。但是這例子里體現(xiàn)了綁定的概念，應(yīng)該說是從基本功能上很齊全的一個例子，而且在ZSTACK上實現(xiàn)無線網(wǎng)絡(luò)數(shù)傳，沒有任何多余的功能。所以該例子是一個典型的ZSTACK模板，也就是為用戶提供了一個通用模板可以通過這個建立自己的應(yīng)用。關(guān)于如何在這個例子上建立、修改成自己的工程和應(yīng)用項目詳細見文檔：

CreateNewApplicationForTheCC2430DB_F8W-201*-0033_.pdf這個例子就到此結(jié)束了，否則不然就很難把下面的弄玩了！2、SimpleApp

這個例子我基本跑通了，可是鑒于時間的關(guān)系，沒有來得及打字了，所以就留到下一次了，時間真是如流水啊-------------------快！

學(xué)習Z-Stack之9

接到昨天的繼續(xù)忽悠，話說：2、SimpleApp

—這個例子我基本跑通了，可是鑒于時間的關(guān)系，沒有來得及打字了，所以就留到下一次了，時間真是如流水啊-------------------快！….‖

這個例子里面有兩個演示：一個是燈與開關(guān)的控制實驗，一個溫度傳感器實驗。咱一個個來，不忙。燈與開關(guān)實驗

在這個例子中燈對應(yīng)的工程名字為：SimpleControllerDB；開關(guān)對應(yīng)：SimpleSwitchDB。嚴重需要注意的地方，這里選用的是DB。因為從從零開始學(xué)習Z-Stack之1上可以看到DB與EB的區(qū)別，而這里用DB的硬件就足以應(yīng)付。編譯下載我就不繼續(xù)羅嗦了。

咱關(guān)心的幾個問題不外乎就是表演過程和表演結(jié)果，以及初步看看為什么會有這樣的結(jié)果產(chǎn)生，當然就得從程序上簡單了解下。

首先打開Controller（也就是燈設(shè)備）的電源，那么LED2就會不停的閃爍，這個時候是設(shè)備正在初始化，讓您選擇設(shè)備以哪種類型啟動，從程序可以看出：if(keys&HAL_KEY_SW_1){

if(myAppState==APP_INIT){

//Intheinitstate,keysareusedtoindicatethelogicalmode.//Key1startsdeviceasacoordinatorzb_ReadConfiguration(ZCD_NV_LOGICAL_TYPE,sizeof(uint8),&logicalType);

if(logicalType!=ZG_DEVICETYPE_ENDDEVICE){

logicalType=ZG_DEVICETYPE_COORDINATOR;zb_WriteConfiguration(ZCD_NV_LOGICAL_TYPE,sizeof(uint8),&logicalType);}

//Domoreconfigurationifnecessaryandthenrestartdevicewithauto-startbitset

//writeendpointtosimpledesc...dontpassitinstartreq..thenreset

zb_ReadConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

startOptions=ZCD_STARTOPT_AUTO_START;

zb_WriteConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

zb_SystemReset();}

如果按下S1（UP），那么作為協(xié)調(diào)器啟動。if(keys&HAL_KEY_SW_2){

if(myAppState==APP_INIT){

//Intheinitstate,keysareusedtoindicatethelogicalmode.//Key2startsdeviceasarouterzb_ReadConfiguration(ZCD_NV_LOGICAL_TYPE,sizeof(uint8),&logicalType);

if(logicalType!=ZG_DEVICETYPE_ENDDEVICE){

logicalType=ZG_DEVICETYPE_ROUTER;zb_WriteConfiguration(ZCD_NV_LOGICAL_TYPE,sizeof(uint8),&logicalType);}

zb_ReadConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

startOptions=ZCD_STARTOPT_AUTO_START;

zb_WriteConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

zb_SystemReset();}

如果按下S2（RIGHT），設(shè)備作為路由器啟動。

這里由于是第一個啟動的設(shè)備，所以作為協(xié)調(diào)器啟動，就按下UP，此時燈會有狀態(tài)變化，最終結(jié)果是：LED2常亮，標示建立網(wǎng)絡(luò)成功。如果您還有另外的燈設(shè)備就可以按下RIGHT讓他們都作為路由器啟動，由于本人這里只有兩個節(jié)點，所以就只能有個協(xié)調(diào)器。

現(xiàn)在就來啟動開關(guān)設(shè)備的電源，同樣LED2會閃爍讓您選擇設(shè)備，但是在ZIGBEE中除了協(xié)調(diào)器和路由器就剩下終端設(shè)備了，所以開關(guān)就只能作為終端被啟動，但是也需要通過按鍵來控制，從程序中可以看出：if(keys&HAL_KEY_SW_1){

if(myAppState==APP_INIT){

//Intheinitstate,keysareusedtoindicatethelogicalmode.//TheSwitchdeviceisalwaysanend-devicelogicalType=ZG_DEVICETYPE_ENDDEVICE;zb_WriteConfiguration(ZCD_NV_LOGICAL_TYPE,sizeof(uint8),&logicalType);

//Domoreconfigurationifnecessaryandthenrestartdevicewithauto-startbitset

zb_ReadConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

startOptions=ZCD_STARTOPT_AUTO_START;

zb_WriteConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

zb_SystemReset();}else{

//Initiateabindingwithnulldestination

zb_BindDevice(TRUE,TOGGLE_LIGHT_CMD_ID,NULL);}}

if(keys&HAL_KEY_SW_2){

if(myAppState==APP_INIT){

//Intheinitstate,keysareusedtoindicatethelogicalmode.//TheSwitchdeviceisalwaysanend-device

logicalType=ZG_DEVICETYPE_ENDDEVICE;zb_WriteConfiguration(ZCD_NV_LOGICAL_TYPE,sizeof(uint8),&logicalType);

zb_ReadConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

startOptions=ZCD_STARTOPT_AUTO_START;

zb_WriteConfiguration(ZCD_NV_STARTUP_OPTION,sizeof(uint8),&startOptions);

zb_SystemReset();}else{

//Sendthecommandtotogglelight

zb_SendDataRequest(0xFFFE,TOGGLE_LIGHT_CMD_ID,0,(uint8*)NULL,myAppSeqNumber,0,0);}}

無論是按下S1還是S2（UP或者RIGHT），開關(guān)設(shè)備均作為終端設(shè)備啟動。啟動之后呢，燈的狀態(tài)同樣會發(fā)生一些變化，最終結(jié)果是：LED2快速閃爍，表明此時開關(guān)已經(jīng)成功加入剛才燈設(shè)備建立的那個網(wǎng)絡(luò)了。

那么接下來就要看這個例子的核心部分----------綁定！

首先按下燈設(shè)備（這里為協(xié)調(diào)器，如果有路由器也可以）的UP，那么程序中調(diào)用了：

zb_AllowBind(myAllowBindTimeout);

函數(shù)，允許綁定，這個允許的時間據(jù)說只有10S，當然這個時間是可以調(diào)整的，因為這里的參數(shù)為：staticuint8myAllowBindTimeout=10;至于這個時間怎么計算的就需要到某個函數(shù)zb_AllowBind里去分析了。zb_AllowBind規(guī)定這個參數(shù)為1~64，如果為0，表示為假，就是不允許綁定的意思。如果大于64的話，就一直為真，就是一直都允許綁定。好像似乎是這個意思。至于這個10S是怎么制定的呢，在這個函數(shù)內(nèi)部調(diào)用了：

osal_start_timerEx(sapi_TaskID,ZB_ALLOW_BIND_TIMER,timeout*1000);因為osal_start_timerEx定時函數(shù)最小單位為mS，所以*1000就表示S了。而在SAPI_ProcessEvent事件處理函數(shù)中ZB_ALLOW_BIND_TIMER事件處理如下：

if(events&ZB_ALLOW_BIND_TIMER){afSetMatch(sapi_epDesc.simpleDesc->EndPoint,FALSE);return(events^ZB_ALLOW_BIND_TIMER);}

也就是定時取消綁定狀態(tài)！��！

如果有人看著這些看不明白，那就把這個例子多看幾遍，多跑幾遍。一般如果您每天花費4個小時看這個例子，那么只需要一周事件，我想到時比我還精通明白的！

所以在10S之內(nèi)，開關(guān)必須發(fā)起綁定，此時同樣按下開關(guān)設(shè)備的UP，那么開關(guān)設(shè)備就調(diào)用了函數(shù)：zb_BindDevice(TRUE,TOGGLE_LIGHT_CMD_ID,NULL);發(fā)送一個綁定請求去尋求綁定設(shè)備。

一個設(shè)備允許綁定，一個設(shè)備發(fā)起綁定請求，兩個是您情我愿的，所以就一拍即合，相當?shù)牡菍�！當然沒有這么簡單的哈，就如同兩個人談戀愛，至少也需要是一男一女啊，兩個都是男或女那就太不正常了，ZIGBEE是個國際化的標準，當然不能有這種變態(tài)行為，所以也需要兩個命令的屬性是相反的，就例如這里的控制燈開關(guān)的命令，對于燈來說這個命令為輸入，而對于開關(guān)來說這個命令是輸出。所以一入一出剛好就登對。呵呵��！

綁定成功的表象是：開關(guān)設(shè)備的LED1快速閃爍。voidzb_AllowBindConfirm(uint16source){

//FlashLED

HalLedSet(HAL_LED_1,HAL_LED_MODE_BLINK);}

綁定成功了就可以發(fā)送燈控制命令了。按下RIGHT,調(diào)用了函數(shù)：zb_SendDataRequest(0xFFFE,TOGGLE_LIGHT_CMD_ID,0,(uint8*)NULL,myAppSeqNumber,0,0);

可以看出發(fā)送了一個數(shù)據(jù)請求，顯然是廣播發(fā)送的，而命令為切換燈狀態(tài)的TOGGLE_LIGHT_CMD_ID。當燈收到這命令，就有處理函數(shù)了：

voidzb_ReceiveDataIndication(uint16source,uint16command,uint16len,uint8*pData){

if(command==TOGGLE_LIGHT_CMD_ID){

//ReceivedapplicationcommandtotoggletheLED

HalLedSet(HAL_LED_1,HAL_LED_MODE_TOGGLE);}}

所以LED1顯示狀態(tài)發(fā)生改變。此時這個例子已經(jīng)接近尾聲了，因為綁定成功開關(guān)能夠控制燈了，但是既然可以綁定那么也可以接觸綁定的，如果按下開關(guān)的DOWN，那么同樣調(diào)用了發(fā)送綁定請求函數(shù)：

zb_BindDevice(FALSE,TOGGLE_LIGHT_CMD_ID,NULL);

只是這里第一個參數(shù)為FALSE，所以就能解除綁定。如果某個開關(guān)被解除了綁定，那么此時就不能控制燈了。

在這個例子最后做個小結(jié)------綁定的好處。綁定了之后，發(fā)送數(shù)據(jù)或者命令，就不需要設(shè)備的地址，因為這個命令只能在建立綁定間的設(shè)備中傳輸。------------絕對是我的理解！

還有，一個開關(guān)可以綁定多個燈，同樣，一個燈可以同時與多個開關(guān)發(fā)生綁定。這個不代表本人觀點，本人強力反對腳踏N只船�。。。。�！

現(xiàn)在來簡單分析下傳感器的例子，由于前面燈的例子說的比較多，這里我就說少點。

中心節(jié)點對應(yīng)SimpleCollectorEB，傳感器節(jié)點對應(yīng)SimpleSensorEB。這里用到了EB，主要是因為DB沒有串口硬件，而EB有，這個例子需要用到串口。傳感器的例子效果是：協(xié)調(diào)器可以收集傳感器節(jié)點的溫度信息并通過串口傳輸?shù)絇C機，如下圖所示：

可以看到能夠看到節(jié)點的溫度和電源電壓。

具體實現(xiàn)與燈的例子稍區(qū)別，但是本質(zhì)的原理是一樣的，先選擇設(shè)備類型，然后建立綁定，最后收集信息。這里建立綁定的區(qū)別在于，只要中心節(jié)點允許綁定（與前面操作一樣），然后傳感器節(jié)點是自動發(fā)送綁定請求的：osal_start_timerEx(sapi_TaskID,MY_FIND_COLLECTOR_EVT,myBindRetryDelay);

定時去產(chǎn)生發(fā)MY_FIND_COLLECTOR_EVT事件：if(event&MY_FIND_COLLECTOR_EVT){

//Findandbindtoacollectordevice

zb_BindDevice(TRUE,SENSOR_REPORT_CMD_ID,(uint8*)NULL);}

這個事件就是發(fā)送綁定請求的。至于綁定后的現(xiàn)象與前面一樣了。

最后通過串口調(diào)試工具就能看到前面那個圖的效果了！�。。。。。。。。。。�！

這里的溫度為42，這個肯定不可能的，不然我就被蒸發(fā)掉了哈！因為采用的是芯片內(nèi)部集成的溫度傳感器，這個傳感器做實驗還可以，因為可以看見溫度的變化，但是其準確性是在不敢恭維。TI也是的，做了溫度傳感器，還超級不準確，還不如不做，只有還可以降低硬件成本，幾乎沒有任何使用價值�。�！

友情提示：本文中關(guān)于《資深移動通信工程師學(xué)習zigbee心得》給出的范例僅供您參考拓展思維使用，資深移動通信工程師學(xué)習zigbee心得：該篇文章建議您自主創(chuàng)作。

來源：網(wǎng)絡(luò)整理 免責聲明：本文僅限學(xué)習分享，如產(chǎn)生版權(quán)問題，請聯(lián)系我們及時刪除。

《資深移動通信工程師學(xué)習zigbee心得》由互聯(lián)網(wǎng)用戶整理提供,轉(zhuǎn)載分享請保留原作者信息,謝謝!
鏈接地址：http://m.seogis.com/gongwen/643152.html

• 上一篇：輸電線路維護員見習期工作、學(xué)習心得
• 下一篇：通信工程綜合訓(xùn)練心得