ZigBee協議棧的OSAL運行機理研究與測試

張玲麗

摘 要：文中研究分析了ZigBee協議棧的OSAL運行機理，并在此基礎之上，通過規范的編程流程，設計了一個行之有效的測試系統，很好地演示了OSAL如何實現多任務切換和處理機制，對后期基于協議棧的編程提供了技術支持。

關鍵詞：ZigBee協議棧；OSAL；任務事件；技術支持

中圖分類號：TP39；TN92 文獻標識碼：A 文章編號：2095-1302（2017）08-00-02

0 引 言

從ZigBee 2006協議棧開始，ZigBee協議棧內加入了實時操作系統，主要制定了一個實現任務間切換、同步與互斥等的機制，而這就是操作系統表象層OSAL （Operating System Abstraction Layer，OSAL）產生的根源。OSAL與標準的操作系統存在一定區別，它只實現了類似操作系統的某些功能，如任務切換、內存管理等，還不能稱為真正意義上的操作系統[1]。OSAL專門分配了存放所有任務事件的tasksEvents[]數組，每一個單元對應存放著每一個任務的所有事件，在這個函數中首先通過一個do—while循環來遍歷tasksEvents[]，找到一個具有待處理事件的優先級最高的任務，序號低的任務優先級高，然后跳出循環，此時，就得到了最高優先級任務的序號idx，然后通過events=tasksEvents[idx]語句將當前具有最高優先級的任務事件取出，接著調用（tasksArr[idx]）（inx，events）函數來執行具體的處理。taskArr[]是一個函數指針數組，根據不同的idx可以執行不同的函數[2]，其程序流程圖如圖1所示。

打開一個ZigBee工程文件，在左側通常可以看到三個文件，分別為“Coordinator.c”、“Coordinator.h”、“OSAL_GenericApp.c”。整個程序所實現的功能都包含在這三個文件中。首先打開Coordinator.c 文件，可以看到兩個比較重要的函數GenericApp_Init 和 GenericApp_ProcessEvent。GenericApp_Init是任務的初始化函數，GenericApp_ProcessEvent則負責判斷由參數傳遞的事件類型，然后執行相應的事件處理函數[3]。我們的設計同樣需要遵循該流程，既要進行任務初始化也需要完成開中斷執行操作系統實體的功能。可以將該工作細化為初始化工作、事件的設置和響應、編寫任務事件處理函數。本文設計了一個驗證該運行機理的演示代碼，展示了不同優先級的任務是如何按先后順序被初始化及跳轉到相應的任務事件處理函數來執行的效果。

1 初始化工作

在Zmain.c中首先應啟動系統，即需要完成初始化功能，包括硬件平臺和軟件架構所需的各個模塊，為操作系統的運行做好準備。由于大部分初始化工作協議棧已設置好，此處我們只需特別設置的初始化工作包括初始化工作時鐘、初始化串口、初始化定時器、設置串口、使能中斷等，同時用戶自定義的事件也都需要放到任務初始化函數中進行初始化，此過程分為兩步：

（1）將所有任務對應的事件表清空，任務事件表保存在TaskEvents結構當中，該結構是一個uint16類型的數組，數組的每一個元素對應一個任務所有的事件，16位對應了16個事件。其中最高位表示是否為系統事件，最高位為1，則表示為系統事件；最高位為0，則表示為非系統事件。

（2）為每個任務分配任務ID并初始化具體任務，任務ID決定了任務的優先級，ID越小響應的優先級越高，在任務初始化函數中，最新初始化的任務ID最小，優先級最高，ID依次遞增，最小ID為0，最大ID為TaskCont-1。其具體代碼如下：

void OS_IntTasks（ void ）

{

uint8 i，taskId = 0；

for（ i = 0； i < TaskCont； i ++ ）

{

TaskEvents[i] = 0；

}

testOsInt（ taskId++ ）； //增加任務初始化，確定任務ID

}

倘若需要增加更多任務，只需在testOsInt（ taskId++ ）注冊新任務即可。

2 事件的設置和響應

任務事件的設置有兩種方式[4]：一種直接使用uint8osal_set_event（ uint8 task_id， uint16 event_flag ）函數來設置事件，該函數包含了兩個參數，即任務ID和事件標志；另一種方法是設置一個超時事件。設置超時事件與直接設置事件的區別在于，超時事件不會立刻將事件加入到相應任務的事件列表中，而是需要等待一定時間后才會加入，這個事件是通過設置函數的第三個參數來決定。

OSAL_STATE osal_start_timerEx（ uint8 taskID，uint16 event_flag，uint16 timeout_value ）{ }

從參數來看，該函數與osal_set_event函數相比，多了一個time_out_value參數，該參數用來設置超時值。該超時值的度量單位就是前面初始化timer1時設置的中斷節拍。

響應任務事件首先需要得到準備就緒任務的ID，得到就緒任務ID后就可以通過該ID號得到相應的任務事件處理函數：events = （TasksFn[idx]）（idx， events），其中TasksFn為任務事件處理函數表，表中的函數與任務ID號相對應。本設計只定義了一個任務響應函數：const OSEventHandle TasksFn[] = {testOsProcess；}，其可將任務進程注冊到任務函數指針列表中。endprint

在該設計中增加了一個超時事件，即在osal_start_timerEx函數中調用了osalAddTimer函數[5]，將事件加入到系統時鐘資源當中。該系統時鐘資源由一個結構體數據定義，其原型如下：

typedef struct

{

void *next；//指向下一個節點

uint16 timeout；//超時事件中的超時值保存在此處，當該值減到0時，將該時鐘資源記錄的任務事件增加到事件列表當中

uint16 event_flag；//事件標識

uint8 task_id；//任務ID

} osalTimerRec_t；

在系統輪詢時，除了對任務事件進行查詢外，還增加了掃描事件查詢函數OS_Scan（），在該函數里對timer1的中斷服務函數進行自增運算，每次在OS_Scan中清零，而temp則記錄了mcuTimerCounterForOSAL的拷貝，即每次輪詢花費的系統時間。但關鍵在于OSALTimerUpdate函數若導致超時，則會將設置有事件標識的時鐘資源的超時值進行自減，將運行時間在timerout中減去，一旦判斷timerout值為0，便將相應的事件進行設置，同時取消該超時事件記錄。

本設計分別采用直接設置事件法和設置超時事件法來設置以下兩個事件：

（1）在任務號為testOSTaskID的任務中設置系統事件0x8000和非系統事件0x0001，osal_set_event（testOSTaskID，0x8001 ）；

（2）在任務號為testOSTaskID的任務中設置超時事件0x0002，打開定時器，并設置超時值為3 000 ms，osal_start_timerEx（testOSTaskID， 0x0002， 3000）。

3 編寫任務處理函數

本設計需要在Coordinator.c中增加對應的任務處理函數，在任務處理函數中實現對系統事件0x8000、非系統事件0x0001和超時事件0x0002的處理。對應的任務處理函數如下：

uint16 testOsProcess（ uint8 taskId， uint16 events ）

{

//系統任務

if（ events & 0x8000 ）

{

uartsendstring（（void *）”OS SYS events＼r＼n”，15）；

return events ^ 0x8000；

}

//串口信息任務

if（ events & 0x0001 ）

{

uartsendstring（（void *）”OS test events＼r＼n”，16）；

return events ^ 0x0001；

}

if（events & 0x0002 ）

{

uartsendstring（（void *）”OS Timer events＼r＼n”，17）；

osal_start_timerEx（testOSTaskID， 0x0002， 3000）；//打開超時定時器，3 s超時

return events ^ 0x0002；

}

return 0；

}

對于0x8000事件，通過串口發送”OS SYS events＼r＼n”字符串；對于0x0001事件，通過串口發送”OS test events＼r＼n”字符串；對于0x0002事件，通過串口發送”OS Timer events＼r＼n”字符串，并周期性設置該事件。

4 結 語

為了驗證OSAL是如何按照處理事件的優先級順序來依次處理事件的，將上述編寫好的代碼組織形成工程文件，并下載到相關硬件開發板或平臺上，采用串口通信線把網關底板和計算機連接起來。打開串口調試助手并正確設置后，從串口輸出數據，其視圖如圖2所示，先顯示OS SYS events，然后顯示OS test events，之后每間隔3 s顯示一次OS Timer events。

由此可見，操作系統是優先處理系統強制事件，然后處理用戶自定義事件。由于本設計中事件1和事件2的優先級一樣，因此優先處理先準備好的事件，由于設置定時器事件時設置了3 s的超時，因此交換兩事件的任務ID號后處理和顯示的順序不變。如果有多個同時準備好的時間，系統會按照任務ID號從小到大的順序依次處理。本設計為展示ZigBee協議棧里所包含的精簡OS系統如何進入任務輪詢狀態并按照一定的任務優先級進入任務事件處理，提供了行之有效的測試方案。

參考文獻

[1]王小強，歐陽駿，黃寧淋.ZigBee無線傳感器網絡設計與實現[M].北京：化學工業出版社，2012.

[2]鄭海杰，宋開新.綜合OSAL的ZigBee協議棧設計[J].杭州電子科技大學學報（自然科學版），2015（6）：32-35.

[3]陳亞琳.Zigbee協議棧消息事件處理分析[J].南京工業職業技術學院學報，2014（4）：44-48.

[4]李戰明，劉寶，駱東松.ZigBee技術規范與協議棧分析[J].微型機與應用，2009，28（5）：45-48.

[5]章偉聰，俞新武，李忠成.基于CC2530及ZigBee協議棧設計無線網絡傳感器節點[J].計算機系統應用，2011，20（7）：184-187，120.

[6]李志瑞，程萬里，杜永章.基于CC2530無線MEMS加速度傳感器設計與驗證[J].物聯網技術，2015，5（6）：6-8.

[7]潘軍.基于ZigBee的無線傳感器網絡的研究與應用[D].大連：大連海事大學，2012.

[8]宋國青. ZigBee自動抄表系統的研究與實現[D].桂林：桂林電子科技大學，2010.endprint