【正文】 L下的任務(wù)鏈表示意3. OSAL事件處理綜述 在最后一小節(jié)，拋開繁雜的英文代碼，著重思路地將系統(tǒng)處理事件的流程加以概括。 首先，用戶需要自己的任務(wù)，在任務(wù)初始化中注冊下任務(wù)發(fā)生需要的事件，例如按鍵。 第二步，在硬件層中，將會維護一個軟定時器，這個軟定時器將決定多少時間查詢（相對于系統(tǒng)來說，中斷也僅僅是事件，某些場所仍舊使用查詢）被注冊事件。并且在軟定時器存在期間將會每隔設(shè)定事件準時查詢事件。 第三步，當(dāng)?shù)讓硬樵兊绞录l(fā)生，它們將通過函數(shù)向系統(tǒng)傳遞發(fā)生事件的ID以及其它的參數(shù)。之后通過數(shù)層的調(diào)度，事件傳遞兵分兩路：一路包括任務(wù)ID、事件參數(shù)的信息加入至消息列表，等待處理；另外一路將標志事件發(fā)生的數(shù)組置位，告訴系統(tǒng)有事件需要處理。 最后，系統(tǒng)通過優(yōu)先級查詢，獲得目前有事件需要處理的優(yōu)先級最高的任務(wù)，調(diào)度對應(yīng)任務(wù)處理函數(shù)，進行處理。Zigbee的用戶開發(fā) 前一小節(jié)介紹了Zigbee協(xié)議棧的OSAL下任務(wù)的初始化、事件查詢和事件處理流程。正是在這樣的一個個任務(wù)中，Zigbee設(shè)備完成了從組網(wǎng)到設(shè)備相互發(fā)生關(guān)聯(lián)到無線網(wǎng)絡(luò)的應(yīng)用。 本小節(jié)將在GenericApp的基礎(chǔ)上介紹用戶應(yīng)用程序的初始化與用戶任務(wù)的任務(wù)處理函數(shù)。其間將會涉及許多與網(wǎng)絡(luò)相關(guān)的概念與事件。這些概念和事件同Zigbee技術(shù)基礎(chǔ)概念緊密相連，對于其中比較重要的，將會加以敘述。（2）應(yīng)用程序初始化與任務(wù)處理 在我們的Zigbee協(xié)調(diào)器運行后，Zigbee網(wǎng)絡(luò)已經(jīng)初始化,其它設(shè)備上電以后只要對協(xié)調(diào)器發(fā)送申請入網(wǎng)的請求，協(xié)調(diào)器確認后會分配一個局域網(wǎng)絡(luò)地址（PANIP）給該設(shè)備，這樣新設(shè)備就可以作為網(wǎng)絡(luò)設(shè)備運作了。這樣的過程是由協(xié)議棧完成的，并不需要用戶關(guān)心。但是作為用戶開發(fā)的應(yīng)用程序，則需要在初始化函數(shù)中初始化程序作為Zigbee應(yīng)用所需要的參數(shù)以及在Zigbee框架的應(yīng)用層中注冊自己的任務(wù)，這樣才能實現(xiàn)任務(wù)在網(wǎng)絡(luò)中的實現(xiàn)。應(yīng)用程序的初始化，就是為了用戶的任務(wù)能夠“融入”整個Zigbee協(xié)議棧中。 端點描述符這里為了方便理解需要做一個比喻：在一個開闊的空地上，面對面的站著兩排人，現(xiàn)在，其中一排人需要做一件事情，他們都需要對對面某個人說幾句話，但是不準在話語中附帶名字等可以識別的信息。這個時候?qū)⒊霈F(xiàn)這樣的場面：一排人各自說著各自的，但是另外一排的人只聽見空地上嘈雜的聲音，并不能知道其中哪些話是自己要去聽的。 說話的一排人就如同發(fā)送無線電信息的Zigbee設(shè)備，它們僅僅負責(zé)往信道中傳送數(shù)據(jù),此時的信道就如同嘈雜的空地，其它的設(shè)備接受了數(shù)據(jù)，但是并不知道這些數(shù)據(jù)究竟是不是給自己的，即使是給自己的這些數(shù)據(jù)該給什么任務(wù)去處理也是未知的。因此必須附加識別信息。 這里的識別信息具有兩層含義：一是目的模塊的物理識別；另一則是應(yīng)用程序的軟件識別。 所謂物理識別就是網(wǎng)絡(luò)地址(PANIP)或者設(shè)備的永久編號地址。網(wǎng)絡(luò)地址代表著設(shè)備在無線網(wǎng)絡(luò)中的身份；永久地址代表某個設(shè)備在世界上的唯一身份。通過這層識別，信道中的數(shù)據(jù)只會到達需要到達的物理設(shè)備，但僅僅是物理載體，這時的數(shù)據(jù)仍是雜亂的。擴展的說，Zigbee網(wǎng)絡(luò)中數(shù)據(jù)的傳播方式由此可以引申出不同點。Zigbee網(wǎng)絡(luò)中有廣播、組播和單播的消息傳遞方式。其中廣播就是向網(wǎng)內(nèi)全體成員發(fā)送數(shù)據(jù)；單播就是朝向單個設(shè)備發(fā)送數(shù)據(jù)。至于組播，是只往某一個組ID下注冊的設(shè)備發(fā)送數(shù)據(jù)。因此不同的網(wǎng)內(nèi)消息傳輸方式也是屬于物理識別的。 所謂軟件識別在Zigbee協(xié)議棧中的名字是端點描述符。它由簡單描述符、目的端點描述符的編號、任務(wù)ID等組成。簡單描述符主要包括一些簇（簇用ID號標識，但是實際上是結(jié)構(gòu)體，包含一系列的特性）。所謂的“簇”其實代表邏輯的關(guān)聯(lián)性。例如，開關(guān)能夠控制小燈的亮滅，這是很明顯的具有邏輯關(guān)聯(lián)性的，那么，開關(guān)與小燈就能夠共用一個簇，也就是具有同樣的簇ID。但是同樣很明顯的，開關(guān)的開閉肯定不能用來控制邏輯量多于兩個的事件。例如數(shù)字電路具有三態(tài)，而‘開’‘閉’只能表示兩個邏輯量。因此開關(guān)與數(shù)字電路的三態(tài)在現(xiàn)在討論的角度上是不能共用一個簇的，因為它們不具有邏輯的關(guān)聯(lián)性與共性。事實上，Zigbee協(xié)議正是這么處理的。對于具有共性的某些事物可以被歸納為一簇。通過簡單描述符中這些簇以及任務(wù)ID等的設(shè)定，端點描述符能夠起到過濾的作用。只有符合任務(wù)需求的數(shù)據(jù)能夠通過端點描述符這個“看門人”進而被任務(wù)處理函數(shù)使用。這樣就能夠使數(shù)據(jù)找對門，使所有任務(wù)順利運行。 這樣的兩層識別，使得用戶開發(fā)的任務(wù)程序能夠真正的在無線網(wǎng)絡(luò)中運作和交流起來。因此用戶任務(wù)端點描述符（這里實際上初始化的是簡單描述符，任務(wù)ID等參數(shù)為之后添加）是必須初始化的。 在GenericApp應(yīng)用中，端點描述符的定義如下：typedef struct{ byte endPoint。 byte *task_id。 SimpleDescriptionFormat_t *simpleDesc。 afNetworkLatencyReq_t latencyReq。}其中的SimpleDescriptionFormat_t也就是簡單描述符，它的定義如下：const SimpleDescriptionFormat_t GenericApp_SimpleDesc ={ GENERICAPP_ENDPOINT, GENERICAPP_PROFID, GENERICAPP_DEVICEID, GENERICAPP_DEVICE_VERSION, GENERICAPP_FLAGS, GENERICAPP_MAX_CLUSTERS, (cId_t *)GenericApp_ClusterList, GENERICAPP_MAX_CLUSTERS, (cId_t *)GenericApp_ClusterList }。按照編程的一般約定，大寫變量為宏定義。簡單描述符中的大寫變量設(shè)置了一些網(wǎng)絡(luò)設(shè)定，這里不仔細介紹了。其中GenericApp_ClusterList就是這個端點描述符中的簇列表，也就是這個任務(wù)需要哪些簇類的數(shù)據(jù)。由于GenericApp非常的簡單，它只使用了一個簇，這個簇的ID被設(shè)為1。 在應(yīng)用框架層（AF）層注冊端點描述符 由于在任務(wù)數(shù)據(jù)的篩選上起著決定性作用，端點描述符在某種程度上可以作為任務(wù)本身理解（沒有事件或者說數(shù)據(jù)驅(qū)動的任務(wù)沒有意義）。在Zigbee協(xié)議棧中實現(xiàn)這種任務(wù)篩選需要將端點描述符注冊到應(yīng)用框架層，也就是讓協(xié)議棧認識下有這么個家伙，以后有許多數(shù)據(jù)是要送給它的。端點描述符的注冊很簡單，一個函數(shù)就能夠完成了。afRegister(amp。GenericApp_epDesc)。函數(shù)中的參數(shù)是需要注冊的端點描述符的地址。需要初始化的變量 為了使設(shè)備能夠加入Zigbee網(wǎng)絡(luò)并且實現(xiàn)數(shù)據(jù)的收發(fā)，還需要初始化一些變量。比如設(shè)備的類型、設(shè)備在網(wǎng)絡(luò)中收發(fā)數(shù)據(jù)的地址、方式等等。這些比較簡單但需要掌握Zigbee技術(shù)的一些概念與流程，僅舉例： = (afAddrMode_t)AddrNotPresent。 = 0。 = 0。這三個變量為設(shè)備發(fā)送的目的地址，addrMode規(guī)定了發(fā)送的方式；endPoint規(guī)定了發(fā)送目的地址的終端編號；shortAddr設(shè)置了目的地址的短地址。由短地址是0x0000可以看出，這個設(shè)備的發(fā)送數(shù)據(jù)的目標設(shè)備的網(wǎng)絡(luò)協(xié)調(diào)器。 通過以上幾個步驟的初始化，用戶開發(fā)的代碼才能進入Zigbee框架的應(yīng)用層，才能在Zigbee協(xié)議棧下完成用戶需求功能。用戶任務(wù)處理函數(shù)在用戶的任務(wù)初始化化完成并且成功加入Zigbee協(xié)議棧中運行之后，能夠使用戶完成應(yīng)用功能的就是用戶的任務(wù)處理函數(shù)了。這里，我們?nèi)シ本秃?直接將用戶的任務(wù)處理函數(shù)簡略表示出來：switch ( MSGpkt ){case ZDO_CB_MSG: GenericApp_ProcessZDOMsgs()。break。case KEY_CHANGE:GenericApp_HandleKeys()。breakcase AF_DATA_CONFIRM_CMD:break。case AF_INCOMING_MSG_CMD:GenericApp_MessageMSGCB()。break。case ZDO_STATE_CHANGE:osal_start_timerEx( )。break。default:break。}以上就是用戶處理函數(shù)的主干，一系列的case語句。Case語句后面的宏代表一些組網(wǎng)期間的消息。例如ZDO_STATE_CHANGE，代表著本設(shè)備在無線網(wǎng)中的角色更改。在接收到這個消息后，原函數(shù)調(diào)用osal_start_timerEx()將自身任務(wù)按照一定事件循環(huán)執(zhí)行；再例如KEY_CHANGE后調(diào)用GenericApp_HandleKeys函數(shù)，表示發(fā)生按鍵消息后立即去處理按鍵，實際上正如之前對GenericApp的功能介紹，這個按鍵處理是去實現(xiàn)綁定的。因此，任務(wù)處理函數(shù)的設(shè)計在思路上是非常明朗的，只要用戶程序與Zigbee框架的接口（端口描述符等的初始化）完成了，功能實現(xiàn)就比較簡單了。 本節(jié)小結(jié) 以上兩個小節(jié)對Zigbee協(xié)議棧的OSAL任務(wù)實現(xiàn)流程和基于Zigbee協(xié)議的用戶程序開發(fā)兩個方面進行了介紹。其中在程序開發(fā)方面，著重介紹的是用戶程序與Zigbee協(xié)議棧的接口。也就是說，即使并不知道底層的具體實現(xiàn)，用戶只需要簡單掌握這些接口部分的初始化與運作，就能實現(xiàn)Zigbee無線網(wǎng)絡(luò)的應(yīng)用開發(fā)。本節(jié)將介紹無線溫度傳感網(wǎng)絡(luò)的實現(xiàn)。首先需要介紹在Zigbee網(wǎng)絡(luò)中一個重要的機制：綁定。所謂綁定可以理解為端點描述符的綁定。許多人將綁定機制描述為“輸入輸出簇”。前面曾經(jīng)介紹過“簇”也就是一類共性。這里仍舊以小燈與開關(guān)為例。 小燈與開關(guān)綁定示意圖小燈的亮滅兩個狀態(tài)與開關(guān)的二值實現(xiàn)了對應(yīng)。從這個角度看，開關(guān)與小燈可以作為同一個“簇”。不同的是，開關(guān)作為控制小燈的設(shè)備，擔(dān)負的是“輸入”開關(guān)狀態(tài)給小燈的職責(zé)；小燈則是擔(dān)負接收開關(guān)狀態(tài)后“輸出”電平的職責(zé)。具有相同邏輯關(guān)系的端點描述符之間可以實現(xiàn)綁定，例如圖中的開關(guān)1與小燈3號。綁定后的輸入簇數(shù)據(jù)則可以通過綁定表（綁定表在輸出簇一側(cè)）直接到達輸出簇所在端點描述符對應(yīng)的任務(wù)。溫度傳感網(wǎng)路中，終端節(jié)點的溫度傳輸與協(xié)調(diào)器中央節(jié)點的串口應(yīng)用是綁定的。這樣一來，被采集到的溫度數(shù)據(jù)可以很方便地傳送到PC或者嵌入式平臺上實現(xiàn)實時的檢測。圖為在PC的串口助手上檢測溫度。 無線溫度傳感網(wǎng)絡(luò)的溫度采集實現(xiàn)前面介紹了任務(wù)的實現(xiàn)流程與綁定機制，Zigbee無線網(wǎng)絡(luò)從第一個設(shè)備協(xié)調(diào)器的上電開始，到網(wǎng)絡(luò)穩(wěn)定，再到用戶應(yīng)用的實現(xiàn)，都是由許多任務(wù)的完成實現(xiàn)的。本設(shè)計的溫度傳感網(wǎng)絡(luò)也不例外。以下是無線溫度傳感網(wǎng)路的示意圖： 無線溫度傳感網(wǎng)路示意圖主節(jié)點的協(xié)調(diào)器通過綁定接收到各個傳感節(jié)點發(fā)送的溫度數(shù)據(jù)，經(jīng)過處理后，通過串口與PC通信，將數(shù)據(jù)顯示在串口助手上。但是由于PC價格比較昂貴并且缺乏靈活性，在本設(shè)計中將以嵌入式平臺代替。本章介紹了Zigbee無線傳感網(wǎng)絡(luò)的組建、溫度的采集，檢測等。接下來將會介紹嵌入式監(jiān)測與報警模塊的實現(xiàn)。本章中的溫度數(shù)據(jù)讀取與串口顯示程序主體代碼見附錄3。前面的章節(jié)主要介紹了如何實現(xiàn)Zigbee無線設(shè)備的組網(wǎng)與溫度，本章將主要介紹嵌入式平臺的兩個部分：GSM模塊與串口監(jiān)測程序。其中GSM模塊能夠?qū)崿F(xiàn)向設(shè)置的手機號碼短信報警；串口監(jiān)測程序?qū)崿F(xiàn)溫度的實時監(jiān)測、判斷等功能。這兩個部分構(gòu)成了整個系統(tǒng)的智能監(jiān)測與報警部分。 嵌入式系統(tǒng)的概念根據(jù)IEEE的定義，嵌入式系統(tǒng)是“控制、監(jiān)視或者輔助裝置、及其和設(shè)備運行的裝置”。從中可以看出嵌入式系統(tǒng)是軟件和硬件的綜合體，不過上述定義并不能充分體現(xiàn)出嵌入式系統(tǒng)的精髓，目前國內(nèi)一個普遍被認同的定義是：以應(yīng)用為中心、以計算機技術(shù)為基礎(chǔ)、軟件硬件可裁剪、適應(yīng)應(yīng)用系統(tǒng)對功能、可靠性、成本、體積、功耗嚴格要求的專用計算機系統(tǒng)。簡單地說，嵌入式系統(tǒng)集系統(tǒng)的應(yīng)用軟件與硬件于一體，具有軟件代碼小、高度自動化、響應(yīng)速度快等特點，特別適合于要求實施和多任務(wù)的體系。嵌入式系統(tǒng)主要由嵌入式處理器、相關(guān)支撐硬件、嵌入式才做系統(tǒng)及應(yīng)用軟件系統(tǒng)等組成，它是可獨立工作的“器件”。 嵌入式系統(tǒng)的組成及處理器介紹嵌入式系統(tǒng)是計算機軟件和硬件的綜合體，可涵蓋機械或其他的附屬裝置。所以嵌入式系統(tǒng)可以籠統(tǒng)的氛圍硬件和軟件兩部分。嵌入式系統(tǒng)的構(gòu)架有四個部分：處理器、存儲器、輸入輸出（I/O）。輸入輸出軟件處理器存儲器 嵌入式系統(tǒng)組成示意嵌入式系統(tǒng)的硬件部分，包括處理器/微處理器、存儲器及外設(shè)器件和I/O端口、圖形控制器等。嵌入式系統(tǒng)有別于一般的計算機處理系統(tǒng)，他不具備像硬盤那樣大容量的存儲介質(zhì)，而大多使用EPROM、EEPROM或Flash Memory作為存儲介質(zhì)。 WinCE 。WinCE Mode（用戶模式）和Kernel Mode（內(nèi)核模式）兩個“層”。CoreDLL等DLL同時出現(xiàn)在兩個層中，驅(qū)動程序也可以被加入到內(nèi)核中。硬件是一個嵌入式系統(tǒng)存在的必要條件，是嵌入式設(shè)備的外在體現(xiàn)，也是嵌入式操作系統(tǒng)運行的基礎(chǔ)。在嵌入式系統(tǒng)領(lǐng)域，由于設(shè)備制造商都是由不同領(lǐng)域不同應(yīng)用的廠商發(fā)展而來的，所以硬件結(jié)構(gòu)相對復(fù)雜，僅CPU 體系結(jié)構(gòu)就有多種。WinCE 支持四種CPU體系結(jié)構(gòu)，分別是ARM、MIPS、x86 和SHx。本課題使用的CPU是ARM。內(nèi)核模式（Kernel Mode）用戶模式（User Mode）用戶模式驅(qū)動程序用戶模式驅(qū)動程序應(yīng)用程序應(yīng)用程序CoreDLL（用戶模式）對象存儲系統(tǒng)圖形窗口和事件管理器設(shè)備管理器內(nèi)核模式驅(qū)