深入淺出OSAL多任務(wù)資源分配機(jī)制

1、、概述OSAL (Operating System Abstraction Layer)，翻譯為“操作系統(tǒng)抽象層”。如何理解 這個(gè)復(fù)雜的名詞呢？表面上看它是作為操作系統(tǒng)存在的，可是為什么又加上“抽象層”呢？ 它的本質(zhì)是什么？在Z-Stack協(xié)議棧中，它又扮演了什么角色呢？要解答這些問(wèn)題，我們必、 須先從宏觀入手，漸漸深入探究，最后答案自然會(huì)浮出水面。應(yīng)用程序框架匝月程序應(yīng)用程序?qū)ο?40對(duì)象1碑京0 時(shí)5擋:捐K I林多枷點(diǎn)下圖是ZigBee協(xié)議的結(jié)構(gòu)圖:Ei*曲設(shè)備對(duì)象(ZDQ)go恣共接口2宅。七或攔一.二3雋.多：.賣(mài)悻略黃問(wèn)點(diǎn).牲咀先*問(wèn)席應(yīng)用程序支持子晨(APS)APS安全管理lC攻

2、寸厘洗W疽安全.服務(wù)攜供者so管埋面板媒體訪問(wèn)控制層PHV物理層(PHY)2.4 GHz-068/915 MHz從這幅圖中，我們可以很清楚地從宏觀上了解ZigBee協(xié)議的結(jié)構(gòu)?？墒?，經(jīng)過(guò)粗略的 瀏覽，我們并沒(méi)有發(fā)現(xiàn)任何OSAL的蹤跡。當(dāng)然，我們都知道，Z-Stack與ZigBee之間并不 能完全劃等號(hào)。Z-Stack是ZigBee的具體實(shí)現(xiàn)，所以存在于Z-Stack中的OSAL并不一定出 現(xiàn)在ZigBee中。但是，我們可以在ZigBee中找到些許OSAL的蹤影。在ZigBee協(xié)議中，協(xié)議本身已經(jīng)定義了大部分內(nèi)容。在基于ZigBee協(xié)議的應(yīng)用開(kāi)發(fā)中， 用戶只需要實(shí)現(xiàn)應(yīng)用程序框架即可。從上圖可以看

3、出應(yīng)用程序框架中包含了最多240個(gè)應(yīng)用 程序?qū)ο?。如果我們把一個(gè)應(yīng)用程序?qū)ο罂醋鰹橐粋€(gè)任務(wù)的話，那么應(yīng)用程序框架將包含一 個(gè)支持多任務(wù)的資源分配機(jī)制。于是OSAL便有了存在的必要性，它正是Z-Stack為了實(shí)現(xiàn) 這樣一個(gè)機(jī)制而存在的。OSAL就是以實(shí)現(xiàn)多任務(wù)為核心的系統(tǒng)資源管理機(jī)制。所以O(shè)SAL與標(biāo)準(zhǔn)的操作系統(tǒng)還是 有很大的區(qū)別的。簡(jiǎn)單而言，OSAL實(shí)現(xiàn)了類(lèi)似操作系統(tǒng)的某些功能，但并不能稱(chēng)之為真正 意義上的操作系統(tǒng)。二、OSAL任務(wù)運(yùn)行方式弄明白了 OSAL是何方神圣，接下來(lái)我們將深入Z-Stack，進(jìn)一步研究OSAL。為了方便，我們使用Z-Stack所提供的GenericApp這個(gè)例程為例來(lái)

4、進(jìn)行分析。此例程 的默認(rèn)路徑為C:Texas InstrumentsZStack-1.4.3-1.2.1ProjectszstackSamplesGenericApp。首先我們?nèi)シ本秃?jiǎn)，先來(lái)了解應(yīng)用程序的運(yùn)行方式。在右側(cè)工作空間窗口打開(kāi)App文件夾，我們可以看到三個(gè)文件，分別是“GenericApp.c”、 “ GenericApp.h ”、 OSAL_GenericApp.c ”。我們整個(gè)程序所實(shí)現(xiàn)的功能都在這三個(gè)文件當(dāng)中。首先打開(kāi)GenericApp.c這個(gè)文件。我們首先看到的是比較重要的兩個(gè)函數(shù)： GenericApp_Init和GenericApp_ProcessEvent。從函數(shù)名稱(chēng)

5、上我們很容易得到的信息便是， GenericApp_Init是任務(wù)的初始化函數(shù)，而GenericApp_ProcessEvent則負(fù)責(zé)處理傳遞給此 任務(wù)的事件。大概瀏覽一下GenericApp_ProcessEvent這個(gè)函數(shù)，我們可以發(fā)現(xiàn)，此函數(shù)的主要功能 是判斷由參數(shù)傳遞的事件類(lèi)型，然后執(zhí)行相應(yīng)的事件處理函數(shù)。我們可以由此推斷Z-Stack 應(yīng)用程序的運(yùn)行機(jī)制如下圖所示：當(dāng)有一個(gè)事件發(fā)生的時(shí)候，OSAL負(fù)責(zé)將此事件分配給能夠處理此事件的任務(wù)，然后此 任務(wù)判斷事件的類(lèi)型，調(diào)用相應(yīng)的事件處理程序進(jìn)行處理。明白了這個(gè)問(wèn)題，新的問(wèn)題又?jǐn)[在了我們的面前：OSAL是如何傳遞事件給任務(wù)的。三、OSAL的

6、事件傳遞機(jī)制在試圖弄清楚這個(gè)問(wèn)題之前，我們需要弄清楚另外一個(gè)十分基礎(chǔ)而重要的問(wèn)題。那就是 如何向我們的應(yīng)用程序中添加一個(gè)任務(wù)。我們先來(lái)看看GenericApp是如何添加任務(wù)的。我們打開(kāi)OSAL_GenericApp.c文件。這里我們可以找到一個(gè)很重要的數(shù)組tasksArr和一個(gè)同樣很重要的函數(shù)osallnitTasks。TaskArr這個(gè)數(shù)組里存放了所有任務(wù)的事件處理函數(shù)的地址，在這里事件處理函數(shù)就代 表了任務(wù)本身，也就是說(shuō)事件處理函數(shù)標(biāo)識(shí)了與其對(duì)應(yīng)的任務(wù)。osallnitTasks是OSAL的任務(wù)初始化函數(shù)，所有任務(wù)的初始化工作都在這里面完成， 并且自動(dòng)給每個(gè)任務(wù)分配一個(gè)ID。要添加新任務(wù)，

7、我們需要編寫(xiě)新任務(wù)的事件處理函數(shù)和初始化函數(shù)，然后將事件處理函 數(shù)的地址加入此數(shù)組。然后在osallnitTasks中調(diào)用此任務(wù)的初始化函數(shù)。在此例中，我們 此前提到過(guò)的GenericApp_ProcessEvent這個(gè)函數(shù)被添加到了數(shù)組的末尾， GenericApp_Init 這個(gè)函數(shù)在 osalInitTasks 中被調(diào)用。值得注意的是，TaskArr數(shù)組里各任務(wù)函數(shù)的排列順序要與osalInitTasks函數(shù)中調(diào)用 各任務(wù)初始化函數(shù)的順序必須一直，只有這樣才能夠保證每個(gè)任務(wù)能夠通過(guò)初始化函數(shù)接收 到正確的任務(wù)ID。另外，為了保存任務(wù)初始化函數(shù)所接收的任務(wù)ID，我們需要給每一個(gè)任務(wù)定義一個(gè)

8、全 局變量來(lái)保存這個(gè)ID。在GenericApp中GenericApp.c中定義了 一個(gè)全局變量 GenericApp_TaskID ;并且在 GenericApp_Init 函數(shù)中進(jìn)行了賦值GenericApp_TaskID = task_id;這條語(yǔ)句將分配給GenericApp的任務(wù)ID保存了下來(lái)。到此，我們就給應(yīng)用程序中完整的添加了一個(gè)任務(wù)。我們回到OSAL如何將事件分配給任務(wù)這個(gè)問(wèn)題上來(lái)在OSAL_GenericApp.c這個(gè)文件中，在定義TaskArr這個(gè)數(shù)組之后，又定義了兩個(gè)全局 變量。tasksCnt這個(gè)變量保存了當(dāng)前的任務(wù)個(gè)數(shù)。tasksEvents是一個(gè)指向數(shù)組的指針，此數(shù)

9、組保存了當(dāng)前任務(wù)的狀態(tài)。在任務(wù)初始化函 數(shù)中做了如下操作tasksEvents = (uint16 *)osal_mem_alloc( sizeof( uint16 ) * tasksCnt);osal_memset(tasksEvents, 0, (sizeof( uint16 ) * tasksCnt);我們可以看出所有任務(wù)的狀態(tài)都被初始化為0。代表了當(dāng)前任務(wù)沒(méi)有需要響應(yīng)的事件。緊接著，我們來(lái)到了 main()函數(shù)。此函數(shù)在ZMain文件夾的ZMain.c文件中。略過(guò)許 多對(duì)當(dāng)前來(lái)說(shuō)并非重要的語(yǔ)句，我們先來(lái)看osal_init_system()這個(gè)函數(shù)。在此函數(shù)中， osalInitTas

10、ks。被調(diào)用，從而tasksEvents中的所有內(nèi)容被初始化為0。之后，在main()函數(shù)中，我們進(jìn)入了 osal_start_system()函數(shù)，此函數(shù)為一個(gè)死循 環(huán)，在這個(gè)循環(huán)中，完成了所有的事件分配。首先我們來(lái)看這樣一段代碼：doif (tasksEventsidx)break; while (+idxtasksCnt);當(dāng)tasksEvents這個(gè)數(shù)組中的某個(gè)元素不為0,即代表此任務(wù)有事件需要相應(yīng)，事件類(lèi) 型取決于這個(gè)元素的值。這個(gè)do-while循環(huán)會(huì)選出當(dāng)前優(yōu)先級(jí)最高的需要響應(yīng)的任務(wù)，events = (tasksArridx)( idx, events )；此語(yǔ)句調(diào)用tasks

11、Arr數(shù)組里面相應(yīng)的事件處理函數(shù)來(lái)響應(yīng)事件。如果我們新添加的任 務(wù)有了需要響應(yīng)的事件，那么此任務(wù)的事件處理程序?qū)?huì)被調(diào)用。就這樣，OSAL就將需要響應(yīng)的事件傳遞給了對(duì)應(yīng)的任務(wù)處理函數(shù)進(jìn)行處理。四、事件的捕獲不過(guò)接下來(lái)就有了更加深入的問(wèn)題了，事件是如何被捕獲的？直觀一些來(lái)說(shuō)就是， tasksEvents這個(gè)數(shù)組里的元素是什么時(shí)候被設(shè)定為非零數(shù)，來(lái)表示有事件需要處理的？為 了詳細(xì)的說(shuō)明這個(gè)過(guò)程，我將以GenericApp這個(gè)例程中響應(yīng)按鍵的過(guò)程來(lái)進(jìn)行說(shuō)明。其他 的事件雖然稍有差別，卻是大同小異。按鍵在我們的應(yīng)用里面應(yīng)該屬于硬件資源，所以O(shè)SAL理應(yīng)為我們提供使用和管理這些 硬件的服務(wù)。稍微留意一下

12、我們之前說(shuō)過(guò)的tasksArr這樣一個(gè)數(shù)組，它保存了所有任務(wù)的 事件處理函數(shù)。我們從中發(fā)現(xiàn)了一個(gè)很重要的信息：Hal_ProcessEvent。HAL(Hardware Abstraction Layer)翻譯為“硬件抽象層”。許多人在這里經(jīng)常把將Z-Stack的硬件抽象層 與ZigBee的物理層混為一談。在這里，我們應(yīng)該將Z-Stack的硬件抽象層與ZigBee的物理 層區(qū)分開(kāi)來(lái)。硬件抽象層所包含的范圍是我們當(dāng)前硬件電路上面所有對(duì)于系統(tǒng)可用的設(shè)備資 源。而ZigBee中的物理層則是針對(duì)無(wú)線通信而言，它所包含的僅限于支持無(wú)線通訊的硬件 設(shè)備。通過(guò)這個(gè)重要的信息，我們可以得出這樣一個(gè)結(jié)論：OSA

13、L將硬件的管理也作為一個(gè)任 務(wù)來(lái)處理。那么我們很自然的去尋找Hal_ProcessEvent這個(gè)事件處理函數(shù)，看看它究竟是 如何管理硬件資源的。在“HALCommenhal_drivers.c”這個(gè)文件中，我們找到了這個(gè)函數(shù)。我們直接分析與 按鍵有關(guān)的一部分。if (events & HAL_KEY_EVENT)#if (defined HAL_KEY) & (HAL_KEY = TRUE)/* Check for keys */HalKeyPoll();/* if interrupt disabled, do next polling */if (!Hal_KeyIntEnable)osal

14、_start_timerEx(Hal_TaskID, HAL_KEY_EVENT, 100);#endif / HAL_KEYreturn events HAL_KEY_EVENT;在事件處理函數(shù)接收到HAL_KEY_EVENT這樣一個(gè)事件后，首先執(zhí)行HalKeyPoll()函數(shù)。 由于這個(gè)例程的按鍵采用查詢(xún)的方法獲取，所以是禁止中斷的，于是表達(dá)式 (!Hal_KeyIntEnable)的值為真。那么 osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT, 100)得以執(zhí)行。osal_start_timerEx這是一個(gè)很常用的函數(shù)，它在這里的功能是經(jīng)過(guò)10

15、0 毫秒后，向Hal_TaskID這個(gè)ID所標(biāo)示的任務(wù)(也就是其本身)發(fā)送一個(gè)HAL_KEY_EVENT 事件。這樣以來(lái)，每經(jīng)過(guò)100毫秒，Hal_ProcessEvent這個(gè)事件處理函數(shù)都會(huì)至少執(zhí)行一 次來(lái)處理HAL_KEY_EVENT事件。也就是說(shuō)每隔100毫秒都會(huì)執(zhí)行HalKeyPoll()函數(shù)。那么我們來(lái)看看HalKeyPoll函數(shù)到底在搞什么鬼！代碼中給的注釋為：/* Check for keys */HalKeyPoll();于是我們推斷這個(gè)函數(shù)的作用是檢查當(dāng)前的按鍵情況。進(jìn)入函數(shù)一看，果不其然。雖然 這個(gè)函數(shù)很長(zhǎng)很復(fù)雜，不過(guò)憑借著非凡的聰明才智，我們還是十分清楚的明白了，經(jīng)過(guò)一系

16、 列的if語(yǔ)句和賦值語(yǔ)句，在接近函數(shù)末尾的地方，keys變量(在函數(shù)起始位置定義的) 獲得了當(dāng)前按鍵的狀態(tài)。最后，有一個(gè)十分重要的函數(shù)調(diào)用。(pHalKeyProcessFunction) (keys, HAL_KEY_STATE_NORMAL);pHalKeyProcessFunction這個(gè)函數(shù)指針指向了哪個(gè)函數(shù)我們現(xiàn)在依然不清楚，但是為 了我們有個(gè)清晰而不間斷的思路，我在這里先告訴大家。在這里調(diào)用的是voidOnBoard_KeyCallback ( uint8 keys, uint8 state )這個(gè)函數(shù)。此函數(shù)在“ZMainOnBoard .c”文件中可以找到。在這個(gè)函數(shù)中，又調(diào)用

17、了 voidOnBoard_KeyCallback ( uint8 keys, uint8 state )在這個(gè)函數(shù)中，按鍵的狀態(tài)信息被封裝到了一個(gè)消息結(jié)構(gòu)體中(對(duì)于消息，我們稍后再 說(shuō))。最后有一個(gè)極其重要的函數(shù)被調(diào)用了。osal_msg_send(registeredKeysTaskID, (uint8 *)msgPtr );與前面的 pHalKeyProcessFunction 相同，我先直接告訴大家 registeredKeysTaskID 所指示的任務(wù)正式我們需要響應(yīng)按鍵的GenericApp這個(gè)任務(wù)。那么也就是說(shuō)，在這里我們向GenericApp發(fā)送了一個(gè)附帶按鍵信息的 消息。在

18、osal_msg_send 函數(shù)中osal_set_event(destination_task, SYS_EVENT_MSG );被調(diào)用，它在這里的作用是設(shè)置destination_task這個(gè)任務(wù)的事件為SYS_EVENT_MSG。 而這個(gè)destination_task正式由osal_msg_send這個(gè)函數(shù)通過(guò)參數(shù)傳遞而來(lái)的，它也指示 的是GenericApp這個(gè)任務(wù)。在osal_set_event這個(gè)函數(shù)中，有這樣一個(gè)語(yǔ)句：tasksEventstask_id |= event_flag;至此，剛才所提到的問(wèn)題得到了解決。我們?cè)賹⑦@個(gè)過(guò)程整理一遍。首先，OSAL專(zhuān)門(mén)建立了一個(gè)任務(wù)來(lái)對(duì)

19、硬件資源進(jìn)行管理，這個(gè)任務(wù)的事件處理函數(shù)是 Hal_ProcessEvent。在這個(gè)函數(shù)中通過(guò)調(diào)用 osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT, 100);這個(gè)函數(shù)使得每隔100毫秒就會(huì)執(zhí)行一次 HalKeyPoll()函數(shù)。 HalKeyPoll()獲取當(dāng)前按鍵的狀態(tài)，并且通過(guò)調(diào)用OnBoard_KeyCallback函數(shù)向GenericApp 任務(wù)發(fā)送一個(gè)按鍵消息，并且設(shè)置tasksEvents中GenericApp所對(duì)應(yīng)的值為非零。如此， 當(dāng)main函數(shù)里這樣一段代碼doif (tasksEventsidx)break; while (+i

20、dxtasksCnt);執(zhí)行了以后，GenericApp這個(gè)任務(wù)就會(huì)被挑選出來(lái)。然后通過(guò)events = (tasksArridx)( idx, events )；這個(gè)函數(shù)調(diào)用其事件處理函數(shù)，完成事件的響應(yīng)?，F(xiàn)在，我們回過(guò)頭來(lái)處理我們之前遺留下來(lái)的問(wèn)題。第一、pHalKeyProcessFunction 這個(gè)函數(shù)指針為何指向了 OnBoard_KeyCallback 函數(shù)。在HALCommenhal_drivers.c這個(gè)文件中，我們找到了 HalDriverInit這個(gè)函數(shù)，在 這個(gè)函數(shù)中，按鍵的初始化函數(shù)HalKeyInit被調(diào)用。在HalKeyInit中有這樣的語(yǔ)句：pHalKeyPro

21、cessFunction = NULL;這說(shuō)明在初始化以后pHalKeyProcessFunction并沒(méi)有指向任何一個(gè)函數(shù)。那 pHalKeyProcessFunction是什么時(shí)候被賦值的呢？就在HalKeyInit的下方有一個(gè)這樣的函數(shù)HalKeyConfig。其中有這樣一條語(yǔ)句：pHalKeyProcessFunction = cback；cback是HalKeyConfig所傳進(jìn)來(lái)的參數(shù)，所以，想要知道它所指向的函數(shù)，必須找到 其調(diào)用的地方。經(jīng)過(guò)簡(jiǎn)單的搜索我們不難找出答案。在main函數(shù)中有這樣一個(gè)函數(shù)調(diào)用： InitBoard( OB_READY );此函數(shù)中做了如下調(diào)用：HalKeyConfig(OnboardKeyIntEnable, OnBoard_KeyCallback);第二、registeredKeysTaskID 為什么標(biāo)識(shí)了 GenericApp 這個(gè)任務(wù)？由于OSAL是一個(gè)支持多任務(wù)的調(diào)度機(jī)制，所以在同一時(shí)間內(nèi)將會(huì)有多個(gè)任務(wù)同時(shí)運(yùn)行。 但是從邏輯上來(lái)講，一個(gè)事件只能由一個(gè)任務(wù)來(lái)處理。按鍵事件也不例外。那么如何向OSAL聲明處理按鍵事件的任務(wù)是GenericApp呢？在Generic