簡(jiǎn)介這份資源是完整的開(kāi)源ZigBee協(xié)議棧C語(yǔ)言實(shí)現(xiàn)基于IEEE 802.15.4標(biāo)準(zhǔn)面向嵌入式系統(tǒng)工程師和IoT開(kāi)發(fā)者可用于研究、定制和擴(kuò)展ZigBee網(wǎng)絡(luò)功能。壓縮包共995個(gè)文件約6.04MB以C源碼187個(gè).c、134個(gè).h為核心并附有HTML文檔、Makefile構(gòu)建腳本、圖片與文本說(shuō)明便于直接閱讀和工程編譯。協(xié)議棧覆蓋物理層、MAC層、網(wǎng)絡(luò)層及APS應(yīng)用支持層代碼結(jié)構(gòu)清晰可通過(guò)閱讀源碼理解幀收發(fā)、CSMA/CA機(jī)制、組網(wǎng)路由和設(shè)備管理流程。已有2266人學(xué)習(xí)下載適合希望掌握Z(yǔ)igBee技術(shù)細(xì)節(jié)及從事無(wú)線傳感網(wǎng)開(kāi)發(fā)的讀者結(jié)合調(diào)試工具和文檔可進(jìn)一步開(kāi)展實(shí)驗(yàn)與二次開(kāi)發(fā)。 做物聯(lián)網(wǎng)嵌入式開(kāi)發(fā)這幾年ZigBee協(xié)議棧這個(gè)概念始終繞不開(kāi)。當(dāng)年我第一次在CC2530上跑Z-Stack光是搞懂那個(gè)OSAL事件循環(huán)就花了一個(gè)星期。今天看到“完整開(kāi)源ZigBee協(xié)議棧C語(yǔ)言代碼”這個(gè)標(biāo)題先說(shuō)句公道話ZigBee這個(gè)圈子里真正嚴(yán)格意義上“完整開(kāi)源”的協(xié)議棧非常罕見(jiàn)但如果你需要一份能讀源碼、能改邏輯、能拿去跑實(shí)際硬件的C語(yǔ)言實(shí)現(xiàn)搜索范圍其實(shí)高度集中。這篇文章就圍繞Z-Stack這類最常被當(dāng)作開(kāi)源方案的代碼從分層結(jié)構(gòu)、C語(yǔ)言源碼組織、編譯配置到組網(wǎng)調(diào)試和擴(kuò)展玩法完整梳理一遍適合剛接觸嵌入式無(wú)線協(xié)議棧的學(xué)生、做智能家居網(wǎng)關(guān)的開(kāi)發(fā)者以及所有準(zhǔn)備在ZigBee上做二次開(kāi)發(fā)的工程師。1. 別被“完整開(kāi)源”四個(gè)字帶偏ZigBee協(xié)議棧的真實(shí)面貌1.1 為什么ZigBee領(lǐng)域幾乎沒(méi)有嚴(yán)格意義的全開(kāi)源很多人看到“完整開(kāi)源ZigBee協(xié)議棧C語(yǔ)言代碼”這個(gè)描述第一反應(yīng)是像Linux內(nèi)核那樣拿到手就能看每一行源碼。但實(shí)際情況完全不同。ZigBee協(xié)議棧從IEEE 802.15.4物理層和MAC層往上有網(wǎng)絡(luò)層NWK、應(yīng)用支持子層APS、ZigBee設(shè)備對(duì)象ZDO、應(yīng)用框架AF還涉及安全服務(wù)、綁定表、組播、OTA升級(jí)等一整套機(jī)制代碼量非常龐大。要實(shí)現(xiàn)一個(gè)能過(guò)ZigBee聯(lián)盟認(rèn)證、能穩(wěn)定商用組網(wǎng)的協(xié)議棧團(tuán)隊(duì)投入成本極高所以商業(yè)公司普遍選擇把核心部分做成預(yù)編譯庫(kù)。另外ZigBee聯(lián)盟的認(rèn)證體系也決定了“全開(kāi)源方案”很難進(jìn)產(chǎn)品。廠商做ZigBee設(shè)備通常要拿認(rèn)證認(rèn)證流程費(fèi)和測(cè)試成本都不低開(kāi)源實(shí)現(xiàn)很難低成本通過(guò)全套兼容性測(cè)試。相比之下藍(lán)牙有Zephyr和BlueZThread有OpenThread這幾個(gè)方向都有真正活躍的全開(kāi)源基礎(chǔ)而ZigBee卻一直高度依賴TI一家這在無(wú)線協(xié)議棧生態(tài)里算是個(gè)特殊案例。1.2 中文社區(qū)默認(rèn)的“開(kāi)源ZigBee代碼”到底指什么實(shí)際上去搜“ZigBee協(xié)議棧源碼”絕大多數(shù)教程和項(xiàng)目指向的都是德州儀器TI的Z-Stack也就是配套CC2530、CC2538、CC2652系列芯片的那套代碼。以最經(jīng)典的Z-Stack 3.0.2為例解壓后能看到App、HAL、MAC、MT、NWK、OSAL、Profile、Services、Tools、ZDO、ZMac、ZMain等目錄源碼量很大但NWK層的路由算法、核心狀態(tài)機(jī)以及部分MAC層關(guān)鍵實(shí)現(xiàn)實(shí)際是以預(yù)編譯庫(kù)形式提供的。也就是說(shuō)這是一種“源碼加二進(jìn)制庫(kù)”的混合模式。TI的License允許免費(fèi)使用這套代碼做開(kāi)發(fā)也允許在硬件產(chǎn)品里燒錄但如果你想把它直接改名、轉(zhuǎn)售或者把源碼完整公開(kāi)再分發(fā)是會(huì)踩License紅線的。所以嚴(yán)格講Z-Stack更像“源代碼高度開(kāi)放、核心部分受限商用”的協(xié)議棧。在中文嵌入式社區(qū)大家說(shuō)“開(kāi)源ZigBee協(xié)議棧C語(yǔ)言代碼”時(shí)默認(rèn)指的就是這套東西。理解了這一點(diǎn)后續(xù)整個(gè)學(xué)習(xí)路徑就清晰了。1.3 你還可能遇到的幾個(gè)方案定位要分清除了Z-Stack市面上偶爾也能看到ZBOSS、一些學(xué)術(shù)項(xiàng)目里的802.15.4 MAC實(shí)現(xiàn)它們的定位各有不同ZBOSS商業(yè)ZigBee協(xié)議棧支持多平臺(tái)但也提供NCP版本和部分源碼主要面向網(wǎng)關(guān)側(cè)場(chǎng)景不是完全開(kāi)源路線。Contiki-NG等物聯(lián)網(wǎng)操作系統(tǒng)里的IEEE 802.15.4實(shí)現(xiàn)它們更多停留在MAC層和6LoWPAN層面不算完整的ZigBee協(xié)議棧不能直接組ZigBee網(wǎng)絡(luò)。各種GitHub上個(gè)人或小團(tuán)隊(duì)寫(xiě)的“ZigBee協(xié)議?！焙芏嗍菍W(xué)習(xí)項(xiàng)目沒(méi)有經(jīng)過(guò)真實(shí)設(shè)備的長(zhǎng)期驗(yàn)證跑起來(lái)容易產(chǎn)品化很難。所以我的建議很直接打基礎(chǔ)、做產(chǎn)品、找現(xiàn)成代碼都把精力放在Z-Stack上最穩(wěn)妥。等把Z-Stack跑明白了再回頭對(duì)比其他方案你會(huì)更清楚每個(gè)抽象層到底在解決什么問(wèn)題。2. 從main函數(shù)看懂Z-Stack分層結(jié)構(gòu)與OSAL調(diào)度2.1 七層協(xié)議棧的職責(zé)用快遞分揀來(lái)類比ZigBee協(xié)議棧是典型的分層設(shè)計(jì)自下而上分別是物理層PHY、介質(zhì)訪問(wèn)控制層MAC、網(wǎng)絡(luò)層NWK、應(yīng)用支持子層APS、應(yīng)用框架AF以及橫跨上層的ZDO設(shè)備對(duì)象。物理層處理2.4GHz頻段的收發(fā)250kbps速率MAC層負(fù)責(zé)信道監(jiān)聽(tīng)、CSMA-CA退避和信標(biāo)管理NWK層負(fù)責(zé)組網(wǎng)、路由和父子節(jié)點(diǎn)關(guān)系A(chǔ)PS層負(fù)責(zé)數(shù)據(jù)包分段重組、綁定表和端到端確認(rèn)AF層是所有應(yīng)用端點(diǎn)的入口ZDO則是整個(gè)設(shè)備的“管家”負(fù)責(zé)設(shè)備發(fā)現(xiàn)、服務(wù)發(fā)現(xiàn)、網(wǎng)絡(luò)管理和安全。打個(gè)比方這批模塊就像一套快遞分揀系統(tǒng)MAC是小區(qū)門(mén)口的快遞員只負(fù)責(zé)一趟趟跑腿NWK是干線運(yùn)輸規(guī)劃決定包裹從一個(gè)城市到另一個(gè)城市走哪條路APS是分揀中心負(fù)責(zé)把包裹按戶拆開(kāi)歸類AF是每家每戶的門(mén)牌號(hào)ZDO則是快遞公司的客戶服務(wù)和調(diào)度中心新住戶要接入、舊住戶要搬走都?xì)w它管。分層的好處是每一層只需要關(guān)心和相鄰層之間的接口這也是為什么協(xié)議棧能用C語(yǔ)言寫(xiě)出幾十萬(wàn)行還能維護(hù)住的原因。2.2 OSAL事件驅(qū)動(dòng)讀懂這個(gè)循環(huán)就讀懂一半源碼Z-Stack里沒(méi)有一個(gè)像Linux那樣的完整操作系統(tǒng)它用的是一套叫OSALOperating System Abstraction Layer的事件驅(qū)動(dòng)調(diào)度器。整個(gè)協(xié)議棧上電后main函數(shù)會(huì)做硬件初始化、外設(shè)初始化然后進(jìn)入一個(gè)死循環(huán)這個(gè)循環(huán)就是整個(gè)系統(tǒng)的發(fā)動(dòng)機(jī)。for (;;) { // 1. 從任務(wù)0開(kāi)始掃描找第一個(gè)有待處理事件的任務(wù) while (idx tasksCnt tasksEvents[idx] 0) { idx; } // 2. 如果找到了 if (idx tasksCnt) { uint16 events tasksEvents[idx]; tasksEvents[idx] 0; // 先清事件 tasksEvents[idx] tasksArr[idx](idx, events); // 調(diào)處理函數(shù)返回未處理完的事件 } }上面這段是我為了講清機(jī)制簡(jiǎn)化的寫(xiě)法不同版本細(xì)節(jié)略有差異但核心思想一致。整個(gè)系統(tǒng)有一個(gè)任務(wù)表tasksArr數(shù)組里每個(gè)元素是一個(gè)函數(shù)指針比如MAC事件處理、HAL硬件事件處理、MT串口處理、用戶App事件處理另有一個(gè)和任務(wù)表一一對(duì)應(yīng)的事件表tasksEvents每一位代表一種事件是否發(fā)生。調(diào)度器不斷從任務(wù)0開(kāi)始掃描誰(shuí)有事件就去調(diào)誰(shuí)的處理函數(shù)。這種“單線程協(xié)作式”調(diào)度模式對(duì)無(wú)線協(xié)議棧來(lái)說(shuō)非常合適。協(xié)議棧本身就是一堆狀態(tài)機(jī)事件驅(qū)動(dòng)是自然匹配并且單線程意味著沒(méi)有復(fù)雜的鎖競(jìng)爭(zhēng)不用考慮多核同步。當(dāng)年我找無(wú)線模塊半天不響應(yīng)的問(wèn)題最后定位就是某個(gè)任務(wù)處理函數(shù)里寫(xiě)了死循環(huán)把整個(gè)任務(wù)調(diào)度卡死了從那以后我對(duì)OSAL的敬畏心就特別足。2.3 核心目錄和文件速查拿到Z-Stack源碼后我建議按下面這張表去建立地圖先知道每個(gè)目錄是干什么的再進(jìn)去讀具體文件。目錄職責(zé)建議優(yōu)先閱讀的文件App用戶應(yīng)用層二次開(kāi)發(fā)主戰(zhàn)場(chǎng)SampleApp.c、SampleApp.hHAL板級(jí)硬件驅(qū)動(dòng)串口、按鍵、LED、定時(shí)器hal_board_cfg.h、hal_uart.cMAC / ZMacIEEE 802.15.4 MAC層包含預(yù)編譯庫(kù)ZMac.c、mac_pib.cMT串口監(jiān)控調(diào)試協(xié)議用于ZNP/抓包調(diào)試MT_UART.c、MT_SYS.cNWK網(wǎng)絡(luò)層核心部分多為庫(kù)目錄主要看接口定義和頭文件OSAL任務(wù)調(diào)度與電源管理OSAL.c、OSAL_Tasks.cZDO設(shè)備對(duì)象與網(wǎng)絡(luò)管理ZDApp.c、ZDNwkMgr.cTools編譯配置文件角色和參數(shù)都在這f8wConfig.cfg、f8wCoord.cfg很多新手第一次打開(kāi)工程看到幾十個(gè)文件夾和上千個(gè)文件直接懵掉。其實(shí)絕大多數(shù)時(shí)候你只需要?jiǎng)覣pp、HAL、Tools這三個(gè)目錄MT層是調(diào)試用NWK和ZDO更多是讀代碼理解機(jī)制安全、路由、鄰居表這些東西都在庫(kù)里不需要天天翻。2.4 如何往協(xié)議棧里加一個(gè)自定義任務(wù)讀源碼和改源碼是兩回事。Z-Stack二次開(kāi)發(fā)最常見(jiàn)的第一步就是新增一個(gè)自定義任務(wù)。以經(jīng)典的SampleApp工程為例自定義任務(wù)需要寫(xiě)三個(gè)東西初始化函數(shù)、事件處理函數(shù)、任務(wù)注冊(cè)。uint8 MyApp_TaskID; void MyApp_Init(uint8 task_id) { MyApp_TaskID task_id; } uint16 MyApp_ProcessEvent(uint8 task_id, uint16 events) { if (events MY_EVENT_1) { // 在這里處理你的業(yè)務(wù)邏輯 return events ^ MY_EVENT_1; } return 0; }寫(xiě)完之后到OSAL_Tasks.c里的tasksArr數(shù)組中追加這個(gè)函數(shù)指針再到osalInitTasks里調(diào)用MyApp_Init分配任務(wù)ID。這個(gè)流程看起來(lái)簡(jiǎn)單但它決定了你以后所有的應(yīng)用邏輯都跑在OSAL的調(diào)度框架里。我見(jiàn)過(guò)不少新人想把業(yè)務(wù)邏輯寫(xiě)進(jìn)main函數(shù)的while循環(huán)里結(jié)果導(dǎo)致協(xié)議棧事件得不到及時(shí)處理網(wǎng)絡(luò)頻繁掉線這就是沒(méi)理解任務(wù)注冊(cè)機(jī)制。3. 編譯與燒錄三步把協(xié)議棧跑上真實(shí)節(jié)點(diǎn)3.1 需要準(zhǔn)備的工具鏈以最常用的CC2530加Z-Stack 3.0.2組合為例你需要準(zhǔn)備IAR Embedded Workbench for 8051來(lái)做編譯燒錄用TI的SmartRF Flash Programmer另外備一個(gè)USB轉(zhuǎn)串口模塊和串口助手用于觀察協(xié)議棧日志。CC2538或CC2652系列則要換IAR for ARM燒錄工具和調(diào)試器也略有不同。不少人在工具鏈上卡住是因?yàn)榘姹酒ヅ鋯?wèn)題。Z-Stack 3.0.2對(duì)IAR版本有要求版本太新或太舊都可能編譯報(bào)一些莫名其妙的錯(cuò)誤。我個(gè)人的做法是裝一個(gè)穩(wěn)定的老版本IAR然后用開(kāi)發(fā)板廠商給的工程包直接打開(kāi)避免自己從頭新建工程。CC2530這塊板子的生態(tài)最成熟資料最多用來(lái)學(xué)協(xié)議棧是最合適的選擇。3.2 設(shè)備角色三選一Coordinator、Router、EndDevice編譯Z-Stack工程時(shí)IAR的Workspace下拉框里會(huì)有CoordinatorEB、RouterEB、EndDeviceEB三個(gè)配置這三個(gè)配置分別對(duì)應(yīng)協(xié)調(diào)器、路由器、終端設(shè)備三個(gè)角色。不要小看這個(gè)選擇工程里所有預(yù)編譯宏、配置文件、鏈接腳本都會(huì)跟著變。協(xié)調(diào)器是網(wǎng)絡(luò)的發(fā)起者負(fù)責(zé)選定信道和PAN ID、建立網(wǎng)絡(luò)整個(gè)ZigBee網(wǎng)絡(luò)只能有一個(gè)協(xié)調(diào)器。路由器負(fù)責(zé)轉(zhuǎn)發(fā)數(shù)據(jù)包也能允許其他節(jié)點(diǎn)入網(wǎng)起到擴(kuò)展網(wǎng)絡(luò)覆蓋范圍的作用。終端設(shè)備則最簡(jiǎn)單它只和自己的父節(jié)點(diǎn)通信大部分時(shí)間可以進(jìn)入低功耗休眠模式。對(duì)應(yīng)到源碼里三個(gè)角色分別靠f8wCoord.cfg、f8wRouter.cfg、f8wEndDevice.cfg三個(gè)文件來(lái)配置編譯選項(xiàng)。在編譯之前先想清楚你的節(jié)點(diǎn)要承擔(dān)什么任務(wù)。要是三個(gè)節(jié)點(diǎn)全編譯成協(xié)調(diào)器它們各自建立的網(wǎng)絡(luò)就永遠(yuǎn)不可能互相加入這也是新手最常見(jiàn)的組網(wǎng)失敗原因之一。3.3 f8wConfig.cfg里最值得動(dòng)的幾個(gè)參數(shù)Tools目錄下的f8wConfig.cfg是協(xié)議棧的一個(gè)總配置文件里面用C語(yǔ)言宏的形式寫(xiě)了很多關(guān)鍵參數(shù)。我挑幾個(gè)實(shí)際項(xiàng)目里必須理解的列出來(lái)。-DZDAPP_CONFIG_PAN_ID0xFFFF -DZDAPP_CONFIG_CHANNEL_LIST0x07FFF800 -DMAX_DEVICE_ENTRIES20 -DNWK_MAX_DEVICE_LIST20ZDAPP_CONFIG_PAN_ID是網(wǎng)絡(luò)ID。設(shè)成0xFFFF表示由協(xié)調(diào)器啟動(dòng)時(shí)隨機(jī)生成一個(gè)PAN ID這個(gè)做法在調(diào)試階段很容易出問(wèn)題因?yàn)閰f(xié)調(diào)器每次重新上電都可能生成不同的PAN ID終端如果按固定PAN ID去掃描就永遠(yuǎn)找不到網(wǎng)絡(luò)。我建議調(diào)試階段把它固定成一個(gè)小數(shù)值比如0x1234全部節(jié)點(diǎn)保持一致等邏輯穩(wěn)定了再放開(kāi)。ZDAPP_CONFIG_CHANNEL_LIST是信道列表0x07FFF800表示2.4GHz的11到26信道全部參與掃描。如果懷疑終端掃描時(shí)間太長(zhǎng)可以把信道列表縮減到某一個(gè)信道比如只想用信道15就把對(duì)應(yīng)bit位設(shè)上這樣掃描速度會(huì)快很多。MAX_DEVICE_ENTRIES和NWK_MAX_DEVICE_LIST控制網(wǎng)絡(luò)內(nèi)節(jié)點(diǎn)數(shù)量上限。如果你要組網(wǎng)超過(guò)20個(gè)設(shè)備這兩個(gè)值必須同步調(diào)大否則后加入的節(jié)點(diǎn)會(huì)入網(wǎng)失敗。這些參數(shù)都是在編譯期寫(xiě)死的改完要重新編譯燒錄。3.4 板級(jí)引腳映射最容易讓新人懷疑人生的地方很多人把協(xié)議棧燒進(jìn)板子之后發(fā)現(xiàn)指示燈不亮、按鍵沒(méi)反應(yīng)、串口沒(méi)有打印第一反應(yīng)是協(xié)議棧沒(méi)跑起來(lái)。其實(shí)大概率是HAL層引腳映射和你的板子對(duì)不上。hal_board_cfg.h文件里定義了LED、按鍵、UART等外設(shè)對(duì)應(yīng)的芯片引腳不同開(kāi)發(fā)板的接法差異非常大。比如協(xié)議棧默認(rèn)的串口引腳是P0.2和P0.3但有些開(kāi)發(fā)板為了焊接方便把串口接到了P1.4、P1.5上代碼不修改肯定不通。同類的坑還出現(xiàn)在LED、按鍵、CC2591射頻前端控制等引腳上。所以拿到一塊新板子第一步是打開(kāi)原理圖逐一對(duì)照hal_board_cfg.h里的宏定義進(jìn)行修改。這一步看起來(lái)不起眼卻能省掉后面大把的調(diào)試時(shí)間。4. 組網(wǎng)失敗與串口丟失三組排查鏈路實(shí)錄4.1 終端掃不到網(wǎng)絡(luò)從配置到抓包逐層定位這個(gè)現(xiàn)象我自己遇到過(guò)無(wú)數(shù)次協(xié)調(diào)器已經(jīng)跑起來(lái)終端節(jié)點(diǎn)上電之后一直搜索不到網(wǎng)絡(luò)。很多人一上來(lái)就懷疑協(xié)議棧源碼有問(wèn)題其實(shí)99%是參數(shù)不一致。第一步先確認(rèn)協(xié)調(diào)器是否真的建網(wǎng)成功。最簡(jiǎn)單的方式是打開(kāi)協(xié)調(diào)器的串口日志正常情況下會(huì)看到網(wǎng)絡(luò)建立成功、PAN ID和信道號(hào)打印出來(lái)。如果協(xié)調(diào)器反復(fù)重啟先去查f8wCoord.cfg里的ZDO_COORDINATORTRUE是否被注釋掉。第二步檢查信道。協(xié)調(diào)器會(huì)在信道列表里掃描一個(gè)相對(duì)干凈的信道來(lái)建網(wǎng)如果協(xié)調(diào)器用的全是隨機(jī)PAN ID和默認(rèn)信道列表而終端編譯時(shí)固定成了某個(gè)單一信道兩邊不在一個(gè)信道上自然永遠(yuǎn)碰不到。調(diào)試期把PAN ID和信道都固定成統(tǒng)一值這個(gè)坑就基本消失了。第三步檢查安全配置。如果兩端的安全配置不一致比如信任中心密鑰不匹配終端能看到網(wǎng)絡(luò)但無(wú)法完成關(guān)聯(lián)現(xiàn)象同樣表現(xiàn)為“找不到網(wǎng)絡(luò)”。這需要通過(guò)抓包工具來(lái)進(jìn)一步確認(rèn)。抓包是定位無(wú)線問(wèn)題最直觀的手段。TI官方有Packet Sniffer工具配合一個(gè)抓包用的接收器能看到信道上所有的beacon、association request和association response幀。第四步如果做到這個(gè)程度問(wèn)題基本就水落石出了。我看到終端發(fā)出association request后遲遲收不到response再往上一查發(fā)現(xiàn)設(shè)備表容量已經(jīng)滿了就是下一小節(jié)要說(shuō)的另一個(gè)大坑。4.2 能入網(wǎng)但狀態(tài)異常短地址0xFFFE和設(shè)備表容量還有一種情況是終端能掃描到網(wǎng)絡(luò)數(shù)據(jù)也通了但過(guò)一會(huì)再看節(jié)點(diǎn)的短地址變成了0xFFFE或者入網(wǎng)后很快就掉線。0xFFFE這個(gè)值在ZigBee協(xié)議里表示“沒(méi)有短地址”通常意味著關(guān)聯(lián)流程沒(méi)有真正完成。最常見(jiàn)的原因是協(xié)調(diào)器或路由器的設(shè)備表滿了。前面提到MAX_DEVICE_ENTRIES和NWK_MAX_DEVICE_LIST如果網(wǎng)絡(luò)里已有的節(jié)點(diǎn)數(shù)達(dá)到這個(gè)上限新節(jié)點(diǎn)就分配不到短地址。我做過(guò)一次壓力測(cè)試默認(rèn)20個(gè)節(jié)點(diǎn)容量實(shí)際到第19個(gè)就開(kāi)始出現(xiàn)關(guān)聯(lián)超時(shí)因?yàn)楦腹?jié)點(diǎn)還要給自己留一個(gè)地址。遇到這種情況把兩個(gè)宏同步調(diào)大比如50或100重新編譯燒錄問(wèn)題即可解決。另一種情況是終端設(shè)備配置了休眠模式。RFD_RCVC_ALWAYS_ONFALSE表示終端不是一直接收數(shù)據(jù)它要周期性喚醒去父節(jié)點(diǎn)那取數(shù)據(jù)。如果父節(jié)點(diǎn)緩存數(shù)據(jù)的超時(shí)時(shí)間設(shè)置得很短而終端的喚醒周期又很長(zhǎng)數(shù)據(jù)還沒(méi)來(lái)得及取就過(guò)期了看起來(lái)就像是入網(wǎng)后不穩(wěn)定。這種問(wèn)題要結(jié)合具體功耗模型來(lái)調(diào)不能只看協(xié)議棧源碼。4.3 串口打印亂碼或無(wú)響應(yīng)MT層與波特率的坑串口是觀察協(xié)議棧內(nèi)部狀態(tài)的重要窗口但也是踩坑高發(fā)區(qū)。第一次在Z-Stack里用串口時(shí)我遇到過(guò)三種典型問(wèn)題完全無(wú)輸出、輸出亂碼、每隔一段時(shí)間丟數(shù)據(jù)。完全無(wú)輸出時(shí)首先檢查工程預(yù)編譯宏是否啟用了MT串口功能。Z-Stack的串口調(diào)試功能在MT層這個(gè)功能本質(zhì)上是把一個(gè)任務(wù)代碼編譯進(jìn)去用來(lái)解析和響應(yīng)主機(jī)發(fā)來(lái)的調(diào)試命令。如果代碼都沒(méi)編譯進(jìn)去串口自然不會(huì)有任何日志。其次檢查串口引腳映射參考前面第3.4節(jié)的做法。輸出亂碼絕大多數(shù)是波特率不匹配。Z-Stack默認(rèn)波特率常見(jiàn)的是57600但部分示例工程或開(kāi)發(fā)板固件會(huì)改成115200串口助手設(shè)置不一致時(shí)就會(huì)出現(xiàn)各種亂碼。這里還牽涉到USB轉(zhuǎn)串口芯片的穩(wěn)定性有些便宜的轉(zhuǎn)接模塊在57600波特率下本身就不太穩(wěn)換一個(gè)CH340或者FT232模塊往往立刻就好了。丟數(shù)據(jù)的問(wèn)題則經(jīng)常和流控有關(guān)。如果代碼里啟用了硬件流控但你的USB轉(zhuǎn)串口模塊并沒(méi)有接RTS/CTS線發(fā)送端和接收端會(huì)互相等待產(chǎn)生間歇性卡頓。Z-Stack的MT層有相關(guān)宏控制流控確認(rèn)你的實(shí)際硬件連接方式再做選擇。5. 源碼之外的延伸ZNP網(wǎng)關(guān)與二次開(kāi)發(fā)方向5.1 把協(xié)議棧當(dāng)黑盒用ZNP/NCP模式理解了Z-Stack源碼結(jié)構(gòu)之后你完全可以把協(xié)議棧做成一個(gè)ZNPZigBee Network Processor設(shè)備也就是常說(shuō)的NCP模式。在這種模式下CC2530或CC2538內(nèi)部運(yùn)行完整的協(xié)議棧對(duì)外只通過(guò)串口和主機(jī)MCU通信。主機(jī)不關(guān)心ZigBee底層細(xì)節(jié)只需要按照MT協(xié)議格式給ZNP模塊發(fā)指令就能創(chuàng)建網(wǎng)絡(luò)、讓節(jié)點(diǎn)入網(wǎng)、控制設(shè)備、讀取數(shù)據(jù)。這個(gè)模式非常適用于做網(wǎng)關(guān)。讓ZigBee協(xié)議棧在專門(mén)芯片里跑主控芯片用ESP32、STM32甚至樹(shù)莓派都可以兩邊通過(guò)串口相連。協(xié)議棧側(cè)已經(jīng)把802.15.4的信號(hào)時(shí)序、CSMA-CA、重傳機(jī)制都處理好了主控側(cè)只需要處理MQTT、HTTP、數(shù)據(jù)庫(kù)這類業(yè)務(wù)邏輯。Z-Stack工程里專門(mén)有ZNP目錄編譯出來(lái)的固件燒進(jìn)芯片后配上任意支持串口的主控就能跑起來(lái)。5.2 開(kāi)源生態(tài)里的典型組合ZNP固件加MQTT網(wǎng)關(guān)ZNP模式讓ZigBee的玩法一下子豐富起來(lái)因?yàn)樗馨裐igBee協(xié)議棧變成標(biāo)準(zhǔn)化的串口外設(shè)?，F(xiàn)在很多開(kāi)源智能家居項(xiàng)目就是這么做的一堆CC2530節(jié)點(diǎn)組成ZigBee網(wǎng)絡(luò)其中一個(gè)節(jié)點(diǎn)燒錄ZNP協(xié)調(diào)器固件通過(guò)USB或者串口連到樹(shù)莓派樹(shù)莓派上跑MQTT協(xié)議把ZigBee傳上來(lái)的數(shù)據(jù)轉(zhuǎn)成MQTT主題發(fā)布出去上層再對(duì)接各種自動(dòng)化邏輯。這種組合的好處在于你可以繼續(xù)用Z-Stack的C語(yǔ)言源碼來(lái)定制節(jié)點(diǎn)固件比如某個(gè)傳感節(jié)點(diǎn)需要做極低功耗的讀寫(xiě)策略直接在App層和HAL層改而網(wǎng)關(guān)側(cè)又不需要被ZigBee協(xié)議棧綁死想用Linux還是FreeRTOS都行因?yàn)閆NP已經(jīng)幫主機(jī)屏蔽了協(xié)議細(xì)節(jié)。對(duì)想深入理解協(xié)議棧的人來(lái)說(shuō)這是一個(gè)很好的過(guò)渡方案先通過(guò)ZNP把網(wǎng)絡(luò)搭建和基本通信跑通再回頭去改協(xié)議棧內(nèi)部的任務(wù)和事件難度曲線會(huì)平滑很多。5.3 源碼級(jí)二次開(kāi)發(fā)該從哪個(gè)模塊下手如果讀完前面內(nèi)容你已經(jīng)能把Z-Stack跑起來(lái)下一步就是決定要改哪個(gè)模塊。根據(jù)我自己的經(jīng)驗(yàn)二次開(kāi)發(fā)通常集中在三個(gè)方向。第一個(gè)方向是應(yīng)用層開(kāi)發(fā)也是最常見(jiàn)的。在App目錄里新建任務(wù)定義自己的cluster和attribute把自定義數(shù)據(jù)通過(guò)AF_DataRequest發(fā)出去。這個(gè)層面不需要深入理解NWK層只需要按示例工程照貓畫(huà)虎快速實(shí)現(xiàn)業(yè)務(wù)邏輯。第二個(gè)方向是HAL層驅(qū)動(dòng)適配。換一塊新板子、增加一個(gè)新傳感器、調(diào)整串口或SPI引腳都在HAL層完成。這一層的代碼全是C語(yǔ)言文件可以直接閱讀和修改是練習(xí)和鞏固嵌入式驅(qū)動(dòng)能力的好素材。第三個(gè)方向是低功耗策略優(yōu)化。Z-Stack里OSAL有電源管理機(jī)制ZDO部分也有休眠和喚醒相關(guān)的邏輯。終端設(shè)備用電池供電時(shí)如何結(jié)合任務(wù)事件靈活控制CPU和射頻模塊的休眠時(shí)間往往需要深入到OSAL_PwrMgr和ZDO層去調(diào)整。這個(gè)方向難度最高但對(duì)產(chǎn)品的續(xù)航價(jià)值最大。最后說(shuō)點(diǎn)個(gè)人實(shí)際體會(huì)。我早期做ZigBee產(chǎn)品時(shí)最忌憚的就是一卡住就開(kāi)始重讀協(xié)議棧源碼四處改代碼結(jié)果越改越亂。后來(lái)養(yǎng)成的習(xí)慣是先抓包確認(rèn)物理層和MAC層有沒(méi)有問(wèn)題再查NWK層和配置參數(shù)最后才動(dòng)應(yīng)用層代碼。開(kāi)源協(xié)議棧的價(jià)值不僅在于它能看更在于出錯(cuò)時(shí)你能順著代碼和抓包結(jié)果一層層往下追這種調(diào)試能力是在黑盒商業(yè)協(xié)議棧上練不出來(lái)的。如果你也正在接觸ZigBee希望這份從代碼結(jié)構(gòu)到實(shí)戰(zhàn)排錯(cuò)的梳理能讓你少走我當(dāng)年走過(guò)的彎路。以及設(shè)備測(cè)試時(shí)強(qiáng)烈建議至少準(zhǔn)備一個(gè)抓包工具和兩個(gè)以上的終端節(jié)點(diǎn)很多玄學(xué)問(wèn)題換個(gè)節(jié)點(diǎn)就能明顯縮小排查范圍。本文還有配套的精品資源點(diǎn)擊獲取