【正文】 內(nèi)核模式（Kernel Mode）用戶模式（User Mode）用戶模式驅(qū)動程序用戶模式驅(qū)動程序應用程序應用程序CoreDLL（用戶模式）對象存儲系統(tǒng)圖形窗口和事件管理器設備管理器內(nèi)核模式驅(qū)動。WinCE 支持四種CPU體系結(jié)構(gòu)，分別是ARM、MIPS、x86 和SHx。硬件是一個嵌入式系統(tǒng)存在的必要條件，是嵌入式設備的外在體現(xiàn)，也是嵌入式操作系統(tǒng)運行的基礎。WinCE Mode（用戶模式）和Kernel Mode（內(nèi)核模式）兩個“層”。嵌入式系統(tǒng)有別于一般的計算機處理系統(tǒng)，他不具備像硬盤那樣大容量的存儲介質(zhì)，而大多使用EPROM、EEPROM或Flash Memory作為存儲介質(zhì)。嵌入式系統(tǒng)的構(gòu)架有四個部分：處理器、存儲器、輸入輸出（I/O）。 嵌入式系統(tǒng)的組成及處理器介紹嵌入式系統(tǒng)是計算機軟件和硬件的綜合體，可涵蓋機械或其他的附屬裝置。簡單地說，嵌入式系統(tǒng)集系統(tǒng)的應用軟件與硬件于一體，具有軟件代碼小、高度自動化、響應速度快等特點，特別適合于要求實施和多任務的體系。 嵌入式系統(tǒng)的概念根據(jù)IEEE的定義，嵌入式系統(tǒng)是“控制、監(jiān)視或者輔助裝置、及其和設備運行的裝置”。其中GSM模塊能夠?qū)崿F(xiàn)向設置的手機號碼短信報警；串口監(jiān)測程序?qū)崿F(xiàn)溫度的實時監(jiān)測、判斷等功能。本章中的溫度數(shù)據(jù)讀取與串口顯示程序主體代碼見附錄3。本章介紹了Zigbee無線傳感網(wǎng)絡的組建、溫度的采集，檢測等。以下是無線溫度傳感網(wǎng)路的示意圖： 無線溫度傳感網(wǎng)路示意圖主節(jié)點的協(xié)調(diào)器通過綁定接收到各個傳感節(jié)點發(fā)送的溫度數(shù)據(jù)，經(jīng)過處理后，通過串口與PC通信，將數(shù)據(jù)顯示在串口助手上。 無線溫度傳感網(wǎng)絡的溫度采集實現(xiàn)前面介紹了任務的實現(xiàn)流程與綁定機制，Zigbee無線網(wǎng)絡從第一個設備協(xié)調(diào)器的上電開始，到網(wǎng)絡穩(wěn)定，再到用戶應用的實現(xiàn)，都是由許多任務的完成實現(xiàn)的。這樣一來，被采集到的溫度數(shù)據(jù)可以很方便地傳送到PC或者嵌入式平臺上實現(xiàn)實時的檢測。綁定后的輸入簇數(shù)據(jù)則可以通過綁定表（綁定表在輸出簇一側(cè)）直接到達輸出簇所在端點描述符對應的任務。不同的是，開關作為控制小燈的設備，擔負的是“輸入”開關狀態(tài)給小燈的職責；小燈則是擔負接收開關狀態(tài)后“輸出”電平的職責。 小燈與開關綁定示意圖小燈的亮滅兩個狀態(tài)與開關的二值實現(xiàn)了對應。前面曾經(jīng)介紹過“簇”也就是一類共性。所謂綁定可以理解為端點描述符的綁定。本節(jié)將介紹無線溫度傳感網(wǎng)絡的實現(xiàn)。其中在程序開發(fā)方面，著重介紹的是用戶程序與Zigbee協(xié)議棧的接口。因此，任務處理函數(shù)的設計在思路上是非常明朗的，只要用戶程序與Zigbee框架的接口（端口描述符等的初始化）完成了，功能實現(xiàn)就比較簡單了。例如ZDO_STATE_CHANGE，代表著本設備在無線網(wǎng)中的角色更改。}以上就是用戶處理函數(shù)的主干，一系列的case語句。break。break。breakcase AF_DATA_CONFIRM_CMD:break。break。用戶任務處理函數(shù)在用戶的任務初始化化完成并且成功加入Zigbee協(xié)議棧中運行之后，能夠使用戶完成應用功能的就是用戶的任務處理函數(shù)了。由短地址是0x0000可以看出，這個設備的發(fā)送數(shù)據(jù)的目標設備的網(wǎng)絡協(xié)調(diào)器。 = 0。這些比較簡單但需要掌握Zigbee技術的一些概念與流程，僅舉例： = (afAddrMode_t)AddrNotPresent。需要初始化的變量 為了使設備能夠加入Zigbee網(wǎng)絡并且實現(xiàn)數(shù)據(jù)的收發(fā)，還需要初始化一些變量。GenericApp_epDesc)。端點描述符的注冊很簡單，一個函數(shù)就能夠完成了。 在應用框架層（AF）層注冊端點描述符 由于在任務數(shù)據(jù)的篩選上起著決定性作用，端點描述符在某種程度上可以作為任務本身理解（沒有事件或者說數(shù)據(jù)驅(qū)動的任務沒有意義）。其中GenericApp_ClusterList就是這個端點描述符中的簇列表，也就是這個任務需要哪些簇類的數(shù)據(jù)。按照編程的一般約定，大寫變量為宏定義。 afNetworkLatencyReq_t latencyReq。 byte *task_id。因此用戶任務端點描述符（這里實際上初始化的是簡單描述符，任務ID等參數(shù)為之后添加）是必須初始化的。這樣就能夠使數(shù)據(jù)找對門，使所有任務順利運行。通過簡單描述符中這些簇以及任務ID等的設定，端點描述符能夠起到過濾的作用。事實上，Zigbee協(xié)議正是這么處理的。例如數(shù)字電路具有三態(tài)，而‘開’‘閉’只能表示兩個邏輯量。例如，開關能夠控制小燈的亮滅，這是很明顯的具有邏輯關聯(lián)性的，那么，開關與小燈就能夠共用一個簇，也就是具有同樣的簇ID。簡單描述符主要包括一些簇（簇用ID號標識，但是實際上是結(jié)構(gòu)體，包含一系列的特性）。 所謂軟件識別在Zigbee協(xié)議棧中的名字是端點描述符。至于組播，是只往某一個組ID下注冊的設備發(fā)送數(shù)據(jù)。Zigbee網(wǎng)絡中有廣播、組播和單播的消息傳遞方式。通過這層識別，信道中的數(shù)據(jù)只會到達需要到達的物理設備，但僅僅是物理載體，這時的數(shù)據(jù)仍是雜亂的。 所謂物理識別就是網(wǎng)絡地址(PANIP)或者設備的永久編號地址。因此必須附加識別信息。這個時候?qū)⒊霈F(xiàn)這樣的場面：一排人各自說著各自的，但是另外一排的人只聽見空地上嘈雜的聲音，并不能知道其中哪些話是自己要去聽的。應用程序的初始化，就是為了用戶的任務能夠“融入”整個Zigbee協(xié)議棧中。這樣的過程是由協(xié)議棧完成的，并不需要用戶關心。這些概念和事件同Zigbee技術基礎概念緊密相連，對于其中比較重要的，將會加以敘述。 本小節(jié)將在GenericApp的基礎上介紹用戶應用程序的初始化與用戶任務的任務處理函數(shù)。Zigbee的用戶開發(fā) 前一小節(jié)介紹了Zigbee協(xié)議棧的OSAL下任務的初始化、事件查詢和事件處理流程。之后通過數(shù)層的調(diào)度，事件傳遞兵分兩路：一路包括任務ID、事件參數(shù)的信息加入至消息列表，等待處理；另外一路將標志事件發(fā)生的數(shù)組置位，告訴系統(tǒng)有事件需要處理。并且在軟定時器存在期間將會每隔設定事件準時查詢事件。 首先，用戶需要自己的任務，在任務初始化中注冊下任務發(fā)生需要的事件，例如按鍵。前者負責將消息（結(jié)構(gòu)體，包括任務處理事件需要的參數(shù)）加入鏈表，后者則通過語句：tasksEvents[task_id] |= event_flag最終將tasksEvents數(shù)組賦值，實現(xiàn)了事件處理的最后步驟。OnBoard_SendKeys函數(shù)本體非常簡短，但是功能卻是事件傳遞的核心：通過函數(shù)osal_msg_send將按鍵事件添加至消息鏈表。按鍵事件的傳遞 上一小節(jié)曾經(jīng)提到在Hal_ProcessEvent下曾經(jīng)調(diào)用一個能夠?qū)⑹录鬟f到OSAL高層的函數(shù)，這個函數(shù)實際上的本體在OSAL啟動之前就已經(jīng)被賦值為OnBoard_KeyCallback。這個鏈表的作用在于，每當系統(tǒng)時間過去一個單位，OSALTimeUpdata函數(shù)將會更新鏈表中每個節(jié)點的軟定時器的值，這些計數(shù)值將自減1，當減為0時，將參數(shù)中任務的事件置位為發(fā)生，請求OSAL處理。} osalTimerRec_t。 uint16 event_flag。為了便于理解羅列如下：typedef struct{ void *next。接下來是osal_start_timerEx這個函數(shù)，它的函數(shù)注釋如下：/******************************************************************* * fn osal_start_timerEx * * brief * * This function is called to start a timer to expire in n mSecs. * When the timer expires, the calling task will get the specified event. * * param uint8 taskID task id to set timer for * param uint16 event_id event to be notified with * param UNINT16 timeout_value in milliseconds. * * return SUCCESS, or NO_TIMER_AVAIL. ******************************************************************/osal_start_timerEx的功能是“為某個ID任務的事件（分別是函數(shù)參數(shù)中的Hal_TaskID、HAL_KEY_EVENT）開啟一個‘軟定時器’，當這個‘軟定時器’的定時長度（函數(shù)參數(shù)timeout_value，單位微秒）溢出時，該任務將會收到事件的發(fā)生通知”。于是按鍵的底層檢測就在這個函數(shù)中完成了。if (!Hal_KeyIntEnable){osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT, 100)。amp。HAL為硬件層縮寫，包括按鍵之類的許多事件均來自此層。實際的語句如“KEY == 0”即可實現(xiàn)。以下來分析一個按鍵的發(fā)生到檢測到最后處理的事件捕獲流程。以下來探討tasksEvents是如何查詢到事件的發(fā)生并且置位的，有別于上一小節(jié)，本節(jié)由底層向高層敘述。 tasksArr數(shù)組與tasksEvents數(shù)組對應關系② Zstack的時鐘脈搏與事件的捕獲 前面說過，Zigbee的OSAL是以查詢、收集事件—找到事件對應的任務—處理事件為脈絡的。events = (tasksArr[idx])( idx, events )。 至于任務的事件具體怎么處理，則有tasksEvents中的值決定，如下代碼：events = tasksEvents[idx]。任務沒有事件時對應的tasksEvents位為0；當有事件需要處理時，對應的tasksEvents為非0。 } }while (++idx tasksCnt)。以上的這句代碼為GenericApp任務注冊了中斷綁定請求的消息，正如本節(jié)開頭介紹的通過綁定方式建立連接。ZDO_RegisterForZDOMsg函數(shù)的兩個參數(shù)分別是任務的ID和消息類型。從分配的ID看，MAC層的任務具有最高的優(yōu)先級，而用戶的任務GenericApp優(yōu)先級是最低的。這些代碼的作用是為所有的任務分配任務ID并且初始化任務變量（底層某些任務的初始化不可見）。這樣就可以通過指針找到任務處理函數(shù)，具體的說，所有的任務處理函數(shù)地址均存在tasksArr數(shù)據(jù)中。endifGenericApp_Init( taskID )。endifZDApp_Init( taskID++ )。endifAPS_Init( taskID++ )。Hal_Init( taskID++ )。macTaskInit( taskID++ )。tasksEvents = (uint16 *)osal_mem_alloc( sizeof( uint16 ) * tasksCnt)。在osalInitTasks()中用戶需要將自己定義的任務添加進去，也就是所謂的與OSAL接口。Zstack的OSAL運作是以查詢、收集事件—找到事件對應的任務—處理事件為脈絡的，（1）OSAL的任務運作機制 Zigbee協(xié)議棧的OSAL運作機制示意① Zstack的任務Zstack中的任務由兩部分組成，即Zigbee自身的各個層任務與用戶定義的任務。最后調(diào)用的osal_start_system()是個死循環(huán)，整個Zigbee應用程序完全交由Zstack的操作系統(tǒng)(OSAL)。但是就已知的來說，這些初始化函數(shù)設定了包括通信頻段選擇、信道選擇等無線電設置的底層部分。}其中的MAC_Init()、MAC_InitDevice()、MAC_InitCoord()均是不能查看原形的。osal_int_disable( INTS_ALL )。if !defined NONWKif ( ZG_BUILD_RTR_TYPE ){MAC_InitCoord()。MAC_Init()。但是并非所有的函數(shù)均能夠查看原形。Zigbee程序啟動后，最先做了一系列的初始化工作。 return ( 0 )。endififdef WDT_IN_PM1 WatchDogEnable( WDTIMX )。 zmain_dev_info()。 osal_int_enable( INTS_ALL )。ifndef NONWKafInit()。 ZMacInit()。 osal_nv_init( NULL )。 InitBoard( OB_COLD )。zmain_vdd_check()。 所有的C語言函數(shù)均從main函數(shù)開始運行，找到GenericApp工程的主函數(shù)int main( void ){ osal_int_disable( INTS_ALL )。 不同的設備選擇不同的代碼下載（Coordinator、Router、EndDevice）。由功能訴述可以看出，該應用可以二次開發(fā)許多功能，包括本設計的某些功能。GenericApp功能：啟動后，自動組織建立一個Zigbee網(wǎng)絡（以一個協(xié)調(diào)器和終端節(jié)點組成的簡單網(wǎng)絡進行講解），網(wǎng)絡中的設備間通過“綁定”與“按條件搜索”兩種方式，建立連接。 Zigbee無線傳感網(wǎng)絡的實現(xiàn)過程 本章節(jié)將以一個Zigbee網(wǎng)絡應用GenericApp分析Zigbee網(wǎng)絡的組成與運作過程。本章作為拋磚引玉的一章，目的不僅在于略微介紹底層應用與基本通信實現(xiàn)以使本論文完善，更重要的是