資深移動(dòng)通信工程師學(xué)習(xí)zigbee心得

201*-11-12

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

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

AODV+ENY是什么概念?

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

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

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

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

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

一個(gè)終端節(jié)點(diǎn)第一開機(jī),檢測(cè)信道,如果有1個(gè)以上信道上有信標(biāo),這個(gè)節(jié)點(diǎn)怎么做選擇呢?是不是所以拓?fù)浣Y(jié)構(gòu)的地址分配算法都是:An=Ak+Cship(d)*Rm+n?還是,只是樹狀拓?fù)浣Y(jié)構(gòu)時(shí),按這個(gè)算法分配地址呢?

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

GTS是什么概念?

Beacon的一個(gè)作用是注冊(cè)/識(shí)別一個(gè)PAN?是什么概念?

路由表入口是什么概念?

CAPcontentionaccessperiodCFPcontentionfreeperiodGTSGuaranteedtimeslot

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

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

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

201*年1月4日星期二

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

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

個(gè)PANID是16位短地址中的一個(gè)嗎?不是吧

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

201*年2月16日星期三

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

2節(jié)點(diǎn)加入過(guò)程是個(gè)半盲目的過(guò)程。估計(jì)是為了減少接入時(shí)間和減少?gòu)?fù)雜度的原因吧。節(jié)點(diǎn)向協(xié)調(diào)器發(fā)Associationrequest后，協(xié)調(diào)器會(huì)發(fā)一個(gè)ACK。這個(gè)ACK只是用來(lái)說(shuō)”哦“。

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

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

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

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

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

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

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

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

三種。

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

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

在超幀的競(jìng)爭(zhēng)訪問(wèn)階段，節(jié)點(diǎn)使用帶時(shí)隙的CSMA-CA訪問(wèn)機(jī)制，并且任何通信都必須在競(jìng)爭(zhēng)訪問(wèn)時(shí)段結(jié)束前完成。

GTS,在非競(jìng)爭(zhēng)時(shí)段，這個(gè)時(shí)段被分成若干個(gè)GTS。每個(gè)GTS又由多個(gè)時(shí)隙組成。

2種通信模式：1帶信標(biāo)帶時(shí)隙的CSMA-CA

2不帶信標(biāo)使用非時(shí)隙的CSMA-CA機(jī)制訪問(wèn)信道確認(rèn)幀不需要使用CSMA-CA機(jī)制

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

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

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

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

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

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

樓老師膠片中的和藍(lán)牙比較中，zigbee有254個(gè)節(jié)點(diǎn)設(shè)備。這個(gè)256是怎么來(lái)的？一個(gè)主節(jié)點(diǎn)下可以聯(lián)256個(gè)節(jié)點(diǎn)。簡(jiǎn)單理解，在星型拓?fù)淠Ｊ较�，一個(gè)FFD可以聯(lián)254個(gè)RFD。

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

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

Zigbee的由來(lái)

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

Zigbee是什么

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

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

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

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

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

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

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

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

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

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

省電：兩節(jié)五號(hào)電池支持長(zhǎng)達(dá)6個(gè)月到2年左右的使用時(shí)間。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4．免費(fèi)頻段：Zigbee使用的是免費(fèi)頻段，而許多數(shù)傳電臺(tái)所使用的頻段不僅需要申請(qǐng)，而且每年都需要向國(guó)家無(wú)委會(huì)交納相當(dāng)?shù)念l率使用費(fèi)。

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

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

學(xué)習(xí)Zstack之1

Zstack情況：

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

正式開始：

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

第一步：安裝Zstack

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

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

Start->Programs->TexasInstruments->ZStack-1.4.3->Z-StackUser’sGuide,既然讓我看我就來(lái)看看這個(gè)文檔！！

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

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

1.1、適用范圍

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

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

兩塊SmartRF04EB評(píng)估版，每個(gè)都可以用于CC2430EM評(píng)估模塊。如圖1-1所示：

Figure1:ChipconSmartRF04EBEvaluationBoardwithCC2430EM5塊CC2430DB評(píng)估板，如圖1-2所示：

Figure2:ChipconCC2430DBDevelopmentBoard

10個(gè)SOC_BB評(píng)估板，每個(gè)都可以用于CC2430EM或CC2431EM。如圖1-3所示：

Figure3:ChipconSOC_BBBatteryBoard2.3、電纜

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

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

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

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

這個(gè)也就是安裝ZStack-CC2430-1.4.3.exe的過(guò)程。4.2、IAR安裝

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

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

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

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

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

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

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

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

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

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

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

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

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

圖1-4

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

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

圖1-6

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

圖1-7

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

圖1-8

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

略

至于詳細(xì)的示范流程，這里先不說(shuō)了，因?yàn)楸救瞬捎玫挠布�與原裝有點(diǎn)差異，即使按照這個(gè)方法下載仍然不能演示，因?yàn)槲疫@個(gè)不能用跳線來(lái)選擇設(shè)備類型。

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

ZigBee協(xié)議規(guī)范規(guī)定，一個(gè)14位的個(gè)域網(wǎng)標(biāo)志符（PANID）來(lái)標(biāo)識(shí)唯一的一個(gè)網(wǎng)絡(luò)。Z-Stack可以用兩種方式由用戶自己選擇其PANID，當(dāng)ZDAPP_CONFIG_PAN_ID值設(shè)置不為0xFFFF時(shí)，那么設(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ù)評(píng)估，只不過(guò)這里沒有詳細(xì)的介紹，在后續(xù)文檔中應(yīng)該有介紹的。

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

圖1-9

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

圖1-10

學(xué)習(xí)Zstack之2

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

毫無(wú)疑問(wèn)：如果是第一次打開這個(gè)例子工程，肯定很迷糊，因?yàn)榇藭r(shí)我迷糊了。對(duì)圖2-1我簡(jiǎn)直是相當(dāng)迷糊。圖2-1

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

兩條路：1就是先看主函數(shù)，2就是看看TI提供例子說(shuō)明文檔沒有。我這里先看看主函數(shù)再說(shuō)哈！因?yàn)槲揖椭�道從主函�?shù)看起.

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

圖2-2

下面把主函數(shù)復(fù)制過(guò)來(lái)簡(jiǎn)單看下：ZSEGintmain(void){

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

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

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

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

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

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

osal_nv_init(NULL);

//Determinetheextendedaddress------------確定擴(kuò)展地址（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-------------------這里沒有返回，大概是進(jìn)入OS了。}//main()

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

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

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

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

1、認(rèn)識(shí)硬件------------按鍵和LED

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

圖2-3

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

如圖2-4

如圖2-5

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

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

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

*@fnzmain_ext_addr

*@briefMakesextendedaddressifnoneexists.確定擴(kuò)展地址是有效的*@returnnone

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

staticZSEGvoidzmain_ext_addr(void){

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

//InitializeextendedaddressinNV初始化NV里的擴(kuò)載地址

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)檢查是否為無(wú)效值（地址）xad=(uint8*)&aExtendedAddress;for(i=0;i

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

tmp=0x20;#endif

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

for(i=0;i

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

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

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些臨時(shí)的64位物理地址進(jìn)入NV

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

從程序中可以看出，一開始就檢測(cè)FLASH中的物理地址，因?yàn)檫@個(gè)地址在FLASH中是固定的存儲(chǔ)空間，一旦為有效地址就退出函數(shù)，一旦為無(wú)效地址（0xFFFFFFFFFFFFFFFF）,那么就對(duì)其物理地址進(jìn)行簡(jiǎn)單的初始化并檢測(cè)SW5按鍵。還是比較好理解的！3、運(yùn)行例子

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

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

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

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

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

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

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

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

但是本人英文很差，所以需要慢慢看，等點(diǎn)時(shí)間放上來(lái)！

Z-Stack之3

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

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

1.1.1、描述

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

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

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

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

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

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

這里我基本上能看明白是什么，但是我不打算寫出來(lái)，因?yàn)樯婕暗揭恍㈱IGBEE的關(guān)鍵術(shù)語(yǔ)，不是很明白。

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

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

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

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

OSAL和APL系統(tǒng)服務(wù)是唯一的，因?yàn)楸热绨存I和串口類似事件處罰就只能用唯一的一個(gè)任務(wù)標(biāo)識(shí)。這兩個(gè)硬件都留給了用戶自己定義使用。1.2.4、應(yīng)用設(shè)計(jì)

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

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

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

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

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

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

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

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

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

1.2.5.1、任務(wù)初始化

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

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

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

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

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

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

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

2.2.6.1、SYS_EVENT_MSG(0x8000)

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

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

1.2.6.1.2、AF_INCOMING_MSG_CMD

AF信息輸入指示1.2.6.1.3、KEY_CHANGE

鍵盤動(dòng)作指示

1.2.6.1.4、ZDO_NEW_DSTADDR

匹配描述符請(qǐng)求（MatchDeorRequest）響應(yīng)指示。（例如：自動(dò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指定的通道上形成一個(gè)網(wǎng)絡(luò)，協(xié)調(diào)器將建立一個(gè)隨機(jī)編號(hà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、自動(dòng)啟動(dòng)

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

1.3.2、軟件啟動(dòng)

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

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

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

學(xué)Z-Stack之4

SampleApplication分析（下）

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

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

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

SampleApp_NwkState=DEV_INIT;

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

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

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

SampleApp_epDesc.endPoint=SAMPLEAPP_ENDPOINT;-----SampleAppEP描述符的EP號(hào)

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

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

這里其實(shí)是對(duì)SampleApp的EP描述符進(jìn)行初始化。

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

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

RegisterForKeys(SampleApp_TaskID);

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

SampleApp_Group.ID=0x0001;

osal_memcpy(SampleApp_Group.name,—Group1‖);

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

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

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

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

可以看到是通過(guò)檢測(cè)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ù)。

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

1）、HAL檢測(cè)到鍵盤按下（中斷或者查詢檢測(cè)）2）、HAL的OSAL任務(wù)檢測(cè)到一個(gè)鍵盤狀態(tài)改變調(diào)用回叫函數(shù)產(chǎn)生3）、OSAL鍵盤改變回叫函數(shù)發(fā)送一個(gè)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ù)請(qǐng)求函數(shù)調(diào)用后，都通過(guò)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ā)生改變，那么通過(guò)ZDO_STATE_CHANGE事件通知所有的任務(wù)。注意：在這個(gè)例子中，一旦設(shè)備成功加入網(wǎng)絡(luò)，是通過(guò)定時(shí)運(yùn)行的方式運(yùn)行的。一旦網(wǎng)絡(luò)狀態(tài)為加入‖JOINED‖,那么它可能不需要任何的認(rèn)為操作就能綁定其他設(shè)備，因?yàn)樵O(shè)置為自動(dòng)發(fā)現(xiàn)并綁定的。//Releasethememory

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

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);}

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

在SampleApp.h中定義了：

#defineSAMPLEAPP_SEND_PERIODIC_MSG_EVT0x0001

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

通過(guò)OSAL定時(shí)器，這個(gè)應(yīng)用定時(shí)發(fā)送一個(gè)周期信息：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ù)用來(lái)發(fā)送數(shù)據(jù)。關(guān)于發(fā)送數(shù)據(jù)的具體過(guò)程這里就不做深入研究，不外乎就是把數(shù)據(jù)從應(yīng)用層傳到網(wǎng)絡(luò)層，在傳到MAC，在傳到無(wú)力層，最后通過(guò)OTA發(fā)送出去。接收數(shù)據(jù)就是相反的過(guò)程了，那么接收之后，在應(yīng)用層有什么反應(yīng)呢，最直觀的反應(yīng)就是會(huì)發(fā)送一個(gè)AF_INCOMING_MSG_CMD消息事件。caseAF_INCOMING_MSG_CMD:

SampleApp_MessageMSGCB(MSGpkt);break;

這里表示收到某個(gè)信息，然后在里面調(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;}}

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

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

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

學(xué)Z-Stack之5

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

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

#ifdefined(SOFT_START)if(readCoordinatorJumper())

zgDeviceLogicalType=ZG_DEVICETYPE_COORDINATOR;else

zgDeviceLogicalType=ZG_DEVICETYPE_ROUTER;#endif//SOFT_START

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

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

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

if(readCoordinatorJumper())

zgDeviceLogicalType=ZG_DEVICETYPE_COORDINATOR;else

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

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

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

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

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

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

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

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

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

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

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

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

其實(shí)這個(gè)還是很容易理解的：

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

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

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

MT（MonitorTest）：實(shí)現(xiàn)通過(guò)串口可控各層，于各層進(jìn)行直接交互。NWK（ZigBeeNetworkLayer）：網(wǎng)絡(luò)層目錄，含網(wǎng)絡(luò)層配置參數(shù)文件及網(wǎng)絡(luò)層庫(kù)的函數(shù)接口文件，APS層庫(kù)的函數(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庫(kù)函數(shù)回調(diào)處理函數(shù)。ZMain：主函數(shù)目錄，包括入口函數(shù)及硬件配置文件。Output：輸出文件目錄，這個(gè)EW8051IDE自動(dòng)生成的。

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

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

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

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

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

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

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

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

節(jié)點(diǎn)類型

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

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

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

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

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

路由器

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

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

終端設(shè)備

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

堆棧模式（StackProfile）

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

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

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

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

#defineSTACK_PROFILE_IDHOME_CONTROLS。

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

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

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

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

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

ZB分布式網(wǎng)絡(luò)中地址分配是唯一的。為了不使網(wǎng)絡(luò)中設(shè)備混亂，為每個(gè)設(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ò)物理上的—長(zhǎng)度‖

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

開發(fā)者自定義

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

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

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

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

z-stack中的尋址

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

uint16shortAddr;ZLongAddr_textAddr;}addr;

byteaddrMode;}zAddrType_t;

地址模式參數(shù)

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

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

afAddrBroadcast=AddrBroadcast}afAddrMode_t;

地址模式參數(shù)是需要的，因?yàn)樵赯B中，數(shù)據(jù)包能被點(diǎn)傳輸、多點(diǎn)傳輸或者廣播傳輸。點(diǎn)傳輸被發(fā)送到單個(gè)設(shè)備，多點(diǎn)傳輸一定發(fā)送到一組設(shè)備，廣播傳輸一般被發(fā)送到網(wǎng)絡(luò)中的所有設(shè)備。如下是更詳細(xì)的說(shuō)明。

點(diǎn)到傳輸（Unicast）

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

間接尋址

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

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

廣播傳輸

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

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

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

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

組地址

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

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

//Assignyourselftogroup1group.ID=0x0001;

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

重要設(shè)備地址

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

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

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

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

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

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

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

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

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

有三種方式建立一個(gè)綁定表格：

ZDO綁定請(qǐng)求一個(gè)試運(yùn)轉(zhuǎn)工具能告訴這個(gè)設(shè)備制作一個(gè)綁定報(bào)告。ZDO終端設(shè)備綁定請(qǐng)求2設(shè)備能告訴協(xié)調(diào)器他們想建立綁定表格報(bào)告。該協(xié)調(diào)器將使協(xié)調(diào)并在這兩個(gè)設(shè)備上創(chuàng)建綁定表格條目

設(shè)備應(yīng)用在設(shè)備上的應(yīng)用能建立或管理一個(gè)綁定表格。

任何一個(gè)設(shè)備或應(yīng)用能在網(wǎng)絡(luò)中發(fā)送一個(gè)ZDO信息到另一個(gè)設(shè)備（）建立一個(gè)綁定報(bào)告。這是調(diào)用綁定幫助并且它將建立一個(gè)綁定條目為發(fā)送設(shè)備。3.1.1ZDO綁定請(qǐng)求

通過(guò)調(diào)用函數(shù)ZDP_BindReq()發(fā)送一個(gè)綁定請(qǐng)求。第一個(gè)參數(shù)（dstAddr）是綁定的源地址的短地址。這之前應(yīng)該確定允許綁定，在ZDConfig.h文件中有參數(shù)[ZDO_BIND_UNBIND_REQUEST]允許綁定。能用同樣的參數(shù)調(diào)用函數(shù)ZDP_UnbindReq()移除綁定。

目標(biāo)設(shè)備將調(diào)用函數(shù)ZDApp_BindRsp()或ZDApp_UnbindRsp()，反饋綁定或移除綁定的響應(yīng)，返回其操作狀態(tài)為ZDP_SUCCESS,ZDP_TABLE_FULL或ZDP_NOT_SUPPORTED.

3.1.2ZDO終端設(shè)備綁定請(qǐng)求

該機(jī)制是用一個(gè)按鈕按下或其他類似的動(dòng)作來(lái)選擇設(shè)備在指定時(shí)間內(nèi)被綁定。在規(guī)定時(shí)間內(nèi)，該終端設(shè)備綁定請(qǐng)求信息被收集到協(xié)調(diào)器，并創(chuàng)建一個(gè)基于模式（profile）ID和串（cluster）ID的規(guī)定的綁定表格條目。默認(rèn)的終端設(shè)備綁定超時(shí)時(shí)間（APS_DEFAULT_MAXBINDING_TIME）為16S（定義在nwk_globals.h中），但是能被改變發(fā)送綁定請(qǐng)求

在所有的應(yīng)用例子中有一個(gè)處理鍵盤事件的函數(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ā)送一個(gè)綁定信息到協(xié)調(diào)器�；蛘撸�在SampleLight和SampleSwitch例子中，直接調(diào)用ZDP_EndDeviceBindReq()函數(shù)就實(shí)現(xiàn)點(diǎn)亮/關(guān)閉燈的功能。接收綁定請(qǐng)求

協(xié)調(diào)器將接收[ZDP_IncomingData()在ZDProfile.c]這些信息并分析處理[ZDO_ProcessEndDeviceBindReq()在ZDObject.c]這些信息并調(diào)用函數(shù)ZDApp_EndDeviceBindReqCB()[inZDApp.c]，它將調(diào)用ZDO_MatchEndDeviceBind()[ZDObject.c]處理這個(gè)請(qǐng)求

當(dāng)協(xié)調(diào)器接收到2個(gè)匹配終端色后備的綁定請(qǐng)求時(shí)，它將啟動(dòng)在綁定設(shè)備上創(chuàng)建源綁定條目的處理過(guò)程。該協(xié)調(diào)器有如下處理過(guò)程：解除綁定1.發(fā)送一個(gè)ZDO解除綁定請(qǐng)求到第一個(gè)設(shè)備。終端設(shè)備綁定切換處理，所以解除綁定首先被發(fā)送到移除一個(gè)存在的綁定條目。

2.等待ZDO解除綁定響應(yīng)，如果響應(yīng)狀態(tài)為ZDP_NO_ENTRY,發(fā)送一個(gè)ZDO綁定請(qǐng)求，在源設(shè)備上制作一個(gè)綁定條目。如果該響應(yīng)為ZDP_SUCCESS,為第一個(gè)設(shè)備繼續(xù)到moveontotheclusterIDforthefirstdevice(theunbindremovedtheentrytoggle).

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

4.當(dāng)?shù)谝粋�(gè)設(shè)備完成時(shí)，對(duì)第二個(gè)設(shè)備做同樣的處理。

5.當(dāng)?shù)诙�個(gè)設(shè)備完成時(shí)，發(fā)送ZDO終端設(shè)備綁定響應(yīng)信息到第一個(gè)和第二個(gè)設(shè)備

3.1.3設(shè)備應(yīng)用綁定管理

在設(shè)備上其他進(jìn)入綁定條目的方式是應(yīng)用層管理綁定表格。意思是說(shuō)，應(yīng)用層將調(diào)用下列函數(shù)進(jìn)入和移除綁定表格條目：bindAddEntry()增加綁定表格條目

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

bindRemoveClusterIdFromList()從一個(gè)存在的綁定表格項(xiàng)目中移除一個(gè)串ID。

bindAddClusterIdToList()向一個(gè)已經(jīng)存在的綁定記錄中增加一個(gè)群IDbindRemoveDev()刪除所有地址引用的記錄

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

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

允許綁定源的編譯選項(xiàng)REFLECTOR在f8wConfig.cfg文件中。在文件f8wConfig.cfg,中查看這兩個(gè)綁定配置參數(shù)（NWK_MAX_BINDING_ENTRIES&MAX_BINDING_CLUSTER_IDS)。NWK_MAX_BINDING_ENTRIES綁定表格中最大的綁定實(shí)體數(shù)量參數(shù)；MAX_BINDING_CLUSTER_IDS是在每個(gè)綁定實(shí)體中最大的串ID數(shù)量。

綁定表在靜態(tài)RAM中(未分配)，因此綁定表中記錄的個(gè)數(shù)，每條記錄中群ID的個(gè)數(shù)都實(shí)際影響著使用RAM的數(shù)量。每一條綁定記錄是8字節(jié)多(MAX_BINDING_CLUSTER_IDS*2字節(jié))。除了綁定表使用的靜態(tài)RAM的數(shù)量，綁定配置項(xiàng)目也影響地址管理器中的記錄的個(gè)數(shù)。4、路由4.1預(yù)覽

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

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

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

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

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

ZB終端設(shè)備路由

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

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

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

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

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

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

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

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

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

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

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

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

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

路由功能需要路由器維護(hù)一些表格：路由表格

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

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

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

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

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

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

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

學(xué)習(xí)ZStack之8

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

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

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

首先來(lái)看看TI究竟有哪些例子：

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

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

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

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

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

所以還決定看看程序來(lái)判斷這個(gè)例子的功能。

大約瀏覽了下，這個(gè)例子似乎還與設(shè)備的綁定有關(guān)系，因?yàn)樵诎唇ㄌ幚沓绦蛑邪l(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ā)送綁定請(qǐng)求的命令。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（左）是初始化一個(gè)匹配描述符請(qǐng)求，也就是發(fā)現(xiàn)服務(wù)，或者叫自動(dòng)尋求匹配設(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ā)送的是一個(gè)字符串—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ù)里居然要通過(guò)液晶顯示，本人這里的液晶暫時(shí)沒有移植過(guò)來(lái)，因?yàn)闀簳r(shí)還不具備那個(gè)實(shí)力，怪不得看不到發(fā)送數(shù)據(jù)的狀況！

這里本人就自作聰明的把以前SampleApp例子里面的一句話加過(guò)來(lái)了：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í)這里很簡(jiǎn)單的了，就是接收到數(shù)據(jù)后閃爍4下燈，間隔0.5S。因?yàn)閺模篿f(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);}

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

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

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

學(xué)習(xí)Z-Stack之9

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

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

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

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

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

首先打開Controller（也就是燈設(shè)備）的電源，那么LED2就會(huì)不停的閃爍，這個(gè)時(shí)候是設(shè)備正在初始化，讓您選擇設(shè)備以哪種類型啟動(dòng)，從程序可以看出：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)器啟動(dòng)。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è)備作為路由器啟動(dòng)。

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

現(xiàn)在就來(lái)啟動(dòng)開關(guān)設(shè)備的電源，同樣LED2會(huì)閃爍讓您選擇設(shè)備，但是在ZIGBEE中除了協(xié)調(diào)器和路由器就剩下終端設(shè)備了，所以開關(guān)就只能作為終端被啟動(dòng)，但是也需要通過(guò)按鍵來(lái)控制，從程序中可以看出：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);}}

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

那么接下來(lái)就要看這個(gè)例子的核心部分----------綁定！

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

zb_AllowBind(myAllowBindTimeout);

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

osal_start_timerEx(sapi_TaskID,ZB_ALLOW_BIND_TIMER,timeout*1000);因?yàn)閛sal_start_timerEx定時(shí)函數(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);}

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

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

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

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

綁定成功的表象是：開關(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ā)送了一個(gè)數(shù)據(jù)請(qǐng)求，顯然是廣播發(fā)送的，而命令為切換燈狀態(tài)的TOGGLE_LIGHT_CMD_ID。當(dāng)燈收到這命令，就有處理函數(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ā)生改變。此時(shí)這個(gè)例子已經(jīng)接近尾聲了，因?yàn)榻壎ǔ晒﹂_關(guān)能夠控制燈了，但是既然可以綁定那么也可以接觸綁定的，如果按下開關(guān)的DOWN，那么同樣調(diào)用了發(fā)送綁定請(qǐng)求函數(shù)：

zb_BindDevice(FALSE,TOGGLE_LIGHT_CMD_ID,NULL);

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

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

還有，一個(gè)開關(guān)可以綁定多個(gè)燈，同樣，一個(gè)燈可以同時(shí)與多個(gè)開關(guān)發(fā)生綁定。這個(gè)不代表本人觀點(diǎn)，本人強(qiáng)力反對(duì)腳踏N只船�。。。。。�

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

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

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

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

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

//Findandbindtoacollectordevice

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

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

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

這里的溫度為42，這個(gè)肯定不可能的，不然我就被蒸發(fā)掉了哈！因?yàn)椴捎玫氖切酒瑑?nèi)部集成的溫度傳感器，這個(gè)傳感器做實(shí)驗(yàn)還可以，因?yàn)榭梢钥匆姕囟鹊淖兓�，但是其�?zhǔn)確性是在不敢恭維。TI也是的，做了溫度傳感器，還超級(jí)不準(zhǔn)確，還不如不做，只有還可以降低硬件成本，幾乎沒有任何使用價(jià)值�。�！

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

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

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

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