1.Zigbee協議和Z-Stack

Zigbee協議和Z-Stack是什麼關係？這可能是初學Zigbee同學想知道的問題。給大家舉個例子吧，我們生活中使用的插排是要符合一定的標準的，現在國家標準是GB2099.3-2008，裡面規定了好多插排的電氣、機械等要求。不同廠家生產的插排，要在中國國內銷售的話，必須符合這個標準。但是生產這個插排的廠家多了去了，像 公牛、philips等等（排除做廣告的嫌疑）。其實Zigbee協議棧規範和Z-Stack的關係也差不多，Z-Stack就是符合Zigbee協議棧規範的一個硬體和軟體平臺，是Zigbee協議棧的一個具體實現。當然，還有其他的具體實現，freakz協議棧和contiki作業系統、TinyOS等等。大家要注意，Z-Stack是TI公司提供的協議棧，它是個半開源的協議棧，有些核心程式碼是以庫的形式提供的，所以要想深入瞭解協議棧或者想進一步提升程式設計能力的同學還是找一個全開源的協議棧玩玩吧。比如，freakz協議棧。

2.IAR和Z-Stack

Z-Stack的整個開發環境IDE使用的是IAR（IAR的版本需要參考Z-Stack Home Sample Application User's Guide。此文件在TI提供的資料包裡\Documents內）。從來沒有使用過IAR的同學請參考文章最後附件：IAR入門。這只是個簡單的入門指導，想詳細瞭解IAR或者使用過程中遇到什麼問題請使用IAR的help選項。

 我們知道Zigbee裝置的分為Coordinator、Router、Enddevice三種角色，這三種角色在IAR裡怎麼修改吶？我們開啟一個TI HA（TI提供的關於智慧家居的解決方案），下載地址見下載平臺：http://down.51cto.com/data/2067778

從圖中標示的位置可以修改這三種裝置角色，其實這裡的選項是修改IAR project配置的地方，這裡TI提供的project裡已經配置好了這三鍾Zigbee裝置角色的配置檔案。我們這裡只選擇就可以了。

Z-Stack軟體結構有一個很大的特點：使用巨集定義來區分是否編譯某一模組/功能/函式。

全是根據巨集定義來決定是否編譯這個功能，有的是根據是否定義這個巨集，有的是根據定義的這個巨集的值來決定其什麼作用。這也可以理解，因為TI提供的是一個通用的基礎開發平臺，需要考慮相容性，易用性，並且硬體資源有限，只能使用巨集定義的方式在程式預編譯階段根據巨集定義就可以知道需要哪些功能了。

那麼關鍵的問題來了，這些巨集定義在IAR裡是怎麼定義的類？在IAR中有兩種定義方式：

第一種：

在開啟的TI project工程目錄的Tools下面，有***.cfg檔案，這些是IAR Compiler command-line options。可以在這裡定義巨集。

定義的方法是“-D 加上你要定義的巨集”，例如上面的 -DMAC_CFG_TX_MAX,其實定義的巨集就是MAC_CFG_TX_MAX，你搜索整個工程就可以找到在哪裡使用了這個巨集。取消定義可以在定義前加上“//”。例如//-DMAC_CFG_TX_DATA_MAX=5。

你可能想知道IAR讀取這些cfg檔案需要不需要配置？自己新增加配置檔案怎麼辦？

開啟選單欄 project---option

找到C/C++Complier 選項，然後選擇Extra Options，在這裡寫你自己需要引用的cfg檔案就可以了。

第二種：

開啟選單欄 project---option 然後找到preprocessor選項。

在這裡也可以定義巨集，直接書寫巨集的名字即可，例如：“ZTOOL_P1”。取消巨集定義可以在前面新增“x”，例如“xZTOOL_P1”。當然也可以定義有值的巨集，“LCD_SUPPORTED=DEBUG”。

另外，還要說一下上面截圖中的上面的部分：是新增標頭檔案包含路徑的，這樣在原始碼包含標頭檔案時你就不用書寫好長的路徑名稱了，直接寫標頭檔案名稱就行。

關於這兩種定義巨集有什麼區別？要是兩個地方都定義了相同的巨集但值不同（有可能是你馬虎定義重複了），這種情況以那個為準？

關於區別，第一種定義方式其實就是將要定義的某一類功能的巨集都放到一個檔案中，方便修改、查詢。這樣所有的工程都可以通過指定檔案的方式來使用這些巨集定義或者巨集定義的值。比較方便一些，例如：TI工程裡的f8wCoord.cfg這個巨集定義配置檔案，是針對所有Coordinator的定義，好多不同project想編譯成Coordinator角色的都可以引用這個command-line options檔案。

第二種方式定義只是針對具體某個project的，通過第二種方式設定的內容都會儲存在***.ewp檔案中，這個就是具體某個project的具體配置。

還有一點需要說明：

上面第一處是IAR關於某一個project的一個配置檔案，選中不同的配置檔案，IAR就會根據不同的配置進行編譯、連結等等一系列動作。這裡的配置主要包括：選單欄裡 roject---option裡面所有的設定，還有選擇是否編譯某一個具體的檔案。

顯示為暗灰色的X號的檔案不參與此project的編譯，設定方法為在project具體某個檔案上右鍵--option--Exclude from buid。如上圖所示。

IAR會單獨建立資料夾用於儲存不同peoject配置的編譯、連結生成的檔案。就相當於利用不同的配置實現不同的功能，最明顯的你想編譯一個release版本，編譯一個debug版本，release版本不包括除錯資訊。你就可以設定兩個配置。新增配置的方法是選單欄--project---edit configration裡面add即可。

這裡是選擇同一個工作空間裡不同的專案的。即IAR管理思路是這樣的：一個workspace裡可以包含好多的project，而一個project又可以存在好多種的配置。具體參考選單欄---help---IDE Project Management and Building Guide。

這是IAR的連結器使用的連結指令碼，使用這個檔案制定不同變數或者儲存區域的最終連結地址，還有其他一些功能，具體參考選單欄---help---Linker and Library Reference Guide。

3.Z-Stack軟體結構簡介

關於Z-Stack結構比較詳細的資料需要看這兩個TI的官方資料：Z-Stack Home Developer's Guide.pdf

Z-Stack Home Sample Application User's Guide.pdf。是比較全面的資料。關於TI Z-Stack的project各個資料夾的作用網路上已經有大量的資料，這裡就不一一贅述。大家可以到網路搜尋資料學習。我這裡只是簡單說一下基於Z-Stack協議棧開發application的思路和方法。Z-Stack project不僅僅提供了Zigbee協議棧的各層API，還提供了一個基於輪詢排程的OS(osal),還提供了一些硬體資源驅動API。各個API使用說明見 TI安裝包 Document---API裡面有各個API的使用說明。

下面我們重點說說這個OSAL,因為它是一個簡易的輪詢式作業系統，Z-Stack協議使用它作為簡單的任務管理、排程、任務間通通訊，使用它使其軟體結構更清晰。另外，我們基於Z-Stack協議的Application設計也要基於此軟體結構。關於這個東東的講解可以參考：http://bbs.feibit.com/thread-16-1-1.html。我這裡舉個例子讓大家好理解這個輪詢作業系統。如果大家有嵌入式實時作業系統的知識，那這個OSAL就比較好理解。其實OSAL並不是實際意義上的作業系統，它只是一個輪詢系統。大家可以想象一個部門有好幾個僱員，只有一個辦公電腦，這個辦公電腦同一時間只能有一位僱員使用，僱員使用辦公電腦需要部門領導審批。部門領導根據僱員年齡的大小進行排序，年齡小的先使用，年齡大的後使用。部門領導負責通知各個僱員在使用辦公電腦時都需要做哪些具體的工作，若某一僱員在得到辦公電腦的使用權時沒有任何事情需要做，那他就將辦公電腦讓給下一個等待的僱員使用。部門領導會根據發生的事件（包括外部事件、僱員之間需要溝通）記錄在一個工作安排薄裡，每一個僱員得到辦公電腦都需要查詢工作安排薄來看自己有哪些工作，工作做完了，再接著查詢，直到沒有自己的工作了，就讓下一個等待的僱員使用辦公電腦。

這下大家可能明白了，若是那個年齡最小的僱員老是有任務做，那其他僱員就沒有機會使用辦公電腦了。所以這個OSAL只是一個簡單的輪詢外部事件的簡單排程系統。想了解嵌入式實時作業系統的相關知識，可以學習一下UCOS的相關資料。

另外，我們還需要了解這樣一種軟體設計思路：Z-Stack作為一個基礎軟體開發包，為了易於維護軟體結構設計時是分層的，那各層之間如何通訊？上層需要呼叫下層的服務時，直接呼叫下層提供的API介面即可，那下層有一些緊急事件或者有些變化是上層關心的，如何通知到上層吶？上層接收到這樣的訊息時有可能需要做不同的操作，這一般怎麼實現吶？這種下層事件發生需要通知上層的情況，需要使用回撥函式，下層事件發生，會呼叫使用者高層註冊的函式來處理下層事件，這就實現了下層到上層的通訊。

所以一般我們需要註冊回撥函式，然後底層事件發生會呼叫我們註冊的函式，註冊函式可以根據傳遞過來的引數做相應處理。

4.兩個基於TI CC2530和Z-Stack平臺的裝置Zigbee通訊

一個Coordinator一個Enddevice，它們之間通訊，我們在Z-Stack提供的project---SimpleLight的基礎上進行修改原始碼做我們的實驗。實現現象如下：Coordinator建立網路後，Enddevice裝置加入網路，然後Coordinator通過廣播的方式傳送字串“Coordinator send!”，EndDevice收到此字串後控制LED燈閃爍，並且向Coordinator傳送“EndDevice received!\r\n”。Coordinator收到後，通過串列埠打印出來。使用的硬體平臺為battery board。

我們選擇CoordinatorEB配置選項。

我們移除project中App資料夾中的zcl_samplelight.c、zcl_samplelight.h、zcl_samplelight_data.c，新增Coordinator.c、Coordinator.h這兩個檔案，OSAL_GenericApp.c這個檔案是OSAL層和Application層之間的介面檔案。這個檔案主要負責OSAL的task的初始化，新增task event處理函式。

先看Coordinator的程式碼：

我們新新增一個task，在Z-Stack中新新增task一般需要以下兩步：1，新增task初始化函式：GenericApp_Init。