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