URL: http://www.eefocus.com/sensorwireless/blog/08-03/144457_c9bd6.html
摘要:FreeRTOS是一個源碼公開的免費的嵌入式實時操作系統，通過研究其內核可以更好地理解嵌入式操作系統的實現原理.本文主要闡述FreeRTOS系統中的任務調度機制、時間管理機制、任務管理機制以及內存分配策略的實現原理，並指出FreeRTOS在應用中的優缺點。
在嵌入式領域中，嵌入式實時操作系統正得到越來越廣泛的應用。採用嵌入式實時操作系統(RTOS)可以更合理、更有效地利用CPU的資源，簡化應用軟件的設計，縮短系統開發時間，更好地保證系統的實時性和可靠性。由於RTOS需佔用一定的系統資源(尤其是RAM資源)，只有μC／OS-II、embOS、salvo、FreeRTOS等少數實時操作系統能在小RAM單片機上運行。相對於C／OS-II、embOS等商業操作系統，FreeRTOS操作系統是完全免費的操作系統，具有源碼公開、可移植、可裁減、調度策略靈活的特點，可以方便地移植到各種單片機上運行，其最新版本爲2.6版。
1、FreeRTOS操作系統功能
作爲一個輕量級的操作系統，FreeRTOS提供的功能包括：任務管理、時間管理、信號量、消息隊列、內存管理、記錄功能等，可基本滿足較小系統的需要。FreeRTOS內核支持優先級調度算法，每個任務可根據重要程度的不同被賦予一定的優先級，CPU總是讓處於就緒態的、優先級最高的任務先運行。FreeRT0S內核同時支持輪換調度算法，系統允許不同的任務使用相同的優先級，在沒有更高優先級任務就緒的情況下，同一優先級的任務共享CPU的使用時間。
FreeRTOS的內核可根據用戶需要設置爲可剝奪型內核或不可剝奪型內核。當FreeRTOS被設置爲可剝奪型內核時，處於就緒態的高優先級任務能剝奪低優先級任務的CPU使用權，這樣可保證系統滿足實時性的要求；當FreeRTOS被設置爲不可剝奪型內核時，處於就緒態的高優先級任務只有等當前運行任務主動釋放CPU的使用權後才能獲得運行，這樣可提高CPU的運行效率。
2、FreeRTOS操作系統的原理與實現
2.1任務調度機制的實現
任務調度機制是嵌入式實時操作系統的一個重要概念，也是其核心技術。對於可剝奪型內核，優先級高的任務一旦就緒就能剝奪優先級較低任務的CPU使用權，提高了系統的實時響應能力。不同於μC／OS-II，FreeRTOS對系統任務的數量沒有限制，既支持優先級調度算法也支持輪換調度算法，因此FreeRTOS採用雙向鏈表而不是採用查任務就緒表的方法來進行任務調度。系統定義的鏈表和鏈表節點數據結構如下所示：
FreeRTOS定義就緒任務鏈表數組爲xList pxReady—TasksLists[portMAX_PRIORITIES]。其中portMAX_PRIORITIES爲系統定義的最大優先級。若想使優先級爲n的任務進入就緒態，需要把此任務對應的TCB中的結點xGenericListltem插入到鏈表pxReadyTasksLiStS[n]中，還要把xGenericListItem中的pvContainer指向pxReadyTasksLists[n]方可實現。
當進行任務調度時，調度算法首先實現優先級調度。系統按照優先級從高到低的順序從就緒任務鏈表數組中尋找usNumberOfItems第一個不爲0的優先級，此優先級即爲當前最高就緒優先級，據此實現優先級調度。若此優先級下只有一個就緒任務，則此就緒任務進入運行態；若此優先級下有多個就緒任務，則需採用輪換調度算法實現多任務輪流執行。
若在優先級n下執行輪換調度算法，系統先通過執行(pxReadyTasksLists[n])→pxIndex=( pxReadyTasks-Lists[n ]) → pxlndex→pxNext語句得到當前結點所指向的下一個結點，再通過此結點的pvOwner指針得到對應的任務控制塊，最後使此任務控制塊對應的任務進入運行態。由此可見，在FreeRTOS中，相同優先級任務之間的切換時間爲一個時鐘節拍週期。
以圖1爲例，設系統的最大任務數爲pottMAX_PRIORITIES，在某一時刻進行任務調度時，得到pxReadyTasksLists[i]．usNumberOfItems=O(i=2...portMAX_PRIORITIES)以及pxReadyTasksLists[1]。usNumberOfItems=3。由此內核可知當前最高就緒優先級爲l，且此優先級下已有三個任務已進入就緒態．由於最高就緒優先級下有多個就緒任務，系統需執行輪換調度算法實現任務切換；通過指針pxlndex可知任務l爲當前任務，而任務l的pxNext結點指向任務2，因此係統把pxIndex指向任務2並執行任務2來實現任務調度。當下一個時鐘節拍到來時，若最高就緒優先級仍爲1，由圖可見，系統會把pxIndex指向任務3並執行任務3。
![]()
圖1 任務調度示意
爲了加快任務調度的速度，FrecRTOS通過變量ucTopReadyPriotity跟蹤當前就緒的最高優先級。當把一個任務加入就緒鏈表時，如果此任務的優先級高於ucTopReadyPriority，則把這個任務的優先級賦予ucTopReadyPriority。這樣當進行優先級調度時，調度算法不是從portMAX_PRIORITIES而是從ucTopReady-Priority開始搜索。這就加快了搜索的速度，同時縮短了內核關斷時間。
爲了加快任務調度的速度，FrecRTOS通過變量ucTopReadyPriotity跟蹤當前就緒的最高優先級。當把一個任務加入就緒鏈表時，如果此任務的優先級高於ucTopReadyPriority，則把這個任務的優先級賦予ucTopReadyPriority。這樣當進行優先級調度時，調度算法不是從portMAX_PRIORITIES而是從ucTopReady-Priority開始搜索。這就加快了搜索的速度，同時縮短了內核關斷時間。
2.3 時間管理的實現
FreeRTOS提供的典型時間管理函數是vTaskDelay()，調用此函數可以實現將任務延時一段特定時間的功能。在FreeRT0S中，若一個任務要延時xTicksToDelay個時鐘節拍，系統內核會把當前系統已運行的時鐘節拍總數(定義爲xTickCount，32位長度)加上xTicksToDelay得到任務下次喚醒時的時鐘節拍數xTimeToWake。然後，內核把此任務的任務控制塊從就緒鏈表中刪除，把xTimeToWake作爲結點值賦予任務的xItemValue，再根據xTimeToWake的值把任務控制塊按照順序插入不同的鏈表。若xTimeToWake
> xTickCount，即計算中沒有出現溢出，內核把任務控制塊插入到pxDelayedTaskList鏈表；若xTimeToWak e< xTickCount，即在計算過程中出現溢出，內核把任務控制塊插入到pxOverflowDelayed-Taskust鏈表。
每發生一個時鐘節拍，內核就會把當前的xTick-Count加1。若xTickCount的結果爲0，即發生溢出，內核會把pxOverflowDelayedTaskList作爲當前鏈表；否則，內核把pxDelaycdTaskList作爲當前鏈表。內核依次比較xTickCotlrtt和鏈表各個結點的xTimcToWake。若xTick-Count等於或大於xTimeToWake，說明延時時間已到，應該把任務從等待鏈表中刪除，加入就緒鏈表。
由此可見，不同於μC／OS—II，FreeRTOS採用“加”的方式實現時間管理。其優點是時間節拍函數的執行時間與任務數量基本無關，而μC／OS—II的OSTimcTick()的執行時間正比於應用程序中建立的任務數。因此當任務較多時，FreeRTOS採用的時間管理方式能有效加快時鐘節拍中斷程序的執行速度。
2.4 內存分配策略
每當任務、隊列和信號量創建的時候，FreeRTOS要求分配一定的RAM。雖然採用malloc()和free()函數可以實現申請和釋放內存的功能，但這兩個函數存在以下缺點：並不是在所有的嵌入式系統中都可用，要佔用不定的程序空間，可重人性欠缺以及執行時間具有不可確定性。爲此，除了可採用malloc()和free()函數外，FreeRTOS還提供了另外兩種內存分配的策略，用戶可以根據實際需要選擇不同的內存分配策略。
第1種方法是，按照需求內存的大小簡單地把一大塊內存分割爲若干小塊，每個小塊的大小對應於所需求內存的大小。這樣做的好處是比較簡單，執行時間可嚴格確定，適用於任務和隊列全部創建完畢後再進行內核調度的系統；這樣做的缺點是，由於內存不能有效釋放，系統運行時應用程序並不能實現刪除任務或隊列。
第2種方法是，採用鏈表分配內存，可實現動態的創建、刪除任務或隊列。系統根據空閒內存塊的大小按從小到大的順序組織空閒內存鏈表。當應用程序申請一塊內存時，系統根據申請內存的大小按順序搜索空閒內存鏈表，找到滿足申請內存要求的最小空閒內存塊。爲了提高內存的使用效率，在空閒內存塊比申請內存大的情況下，系統會把此空閒內存塊一分爲二。一塊用於滿足申請內存的要求，一塊作爲新的空閒內存塊插入到鏈表中。
2.3 時間管理的實現
FreeRTOS提供的典型時間管理函數是vTaskDelay()，調用此函數可以實現將任務延時一段特定時間的功能。在FreeRT0S中，若一個任務要延時xTicksToDelay個時鐘節拍，系統內核會把當前系統已運行的時鐘節拍總數(定義爲xTickCount，32位長度)加上xTicksToDelay得到任務下次喚醒時的時鐘節拍數xTimeToWake。然後，內核把此任務的任務控制塊從就緒鏈表中刪除，把xTimeToWake作爲結點值賦予任務的xItemValue，再根據xTimeToWake的值把任務控制塊按照順序插入不同的鏈表。若xTimeToWake
> xTickCount，即計算中沒有出現溢出，內核把任務控制塊插入到pxDelayedTaskList鏈表；若xTimeToWak e< xTickCount，即在計算過程中出現溢出，內核把任務控制塊插入到pxOverflowDelayed-Taskust鏈表。
每發生一個時鐘節拍，內核就會把當前的xTick-Count加1。若xTickCount的結果爲0，即發生溢出，內核會把pxOverflowDelayedTaskList作爲當前鏈表；否則，內核把pxDelaycdTaskList作爲當前鏈表。內核依次比較xTickCotlrtt和鏈表各個結點的xTimcToWake。若xTick-Count等於或大於xTimeToWake，說明延時時間已到，應該把任務從等待鏈表中刪除，加入就緒鏈表。
由此可見，不同於μC／OS—II，FreeRTOS採用“加”的方式實現時間管理。其優點是時間節拍函數的執行時間與任務數量基本無關，而μC／OS—II的OSTimcTick()的執行時間正比於應用程序中建立的任務數。因此當任務較多時，FreeRTOS採用的時間管理方式能有效加快時鐘節拍中斷程序的執行速度。
2.4 內存分配策略
每當任務、隊列和信號量創建的時候，FreeRTOS要求分配一定的RAM。雖然採用malloc()和free()函數可以實現申請和釋放內存的功能，但這兩個函數存在以下缺點：並不是在所有的嵌入式系統中都可用，要佔用不定的程序空間，可重人性欠缺以及執行時間具有不可確定性。爲此，除了可採用malloc()和free()函數外，FreeRTOS還提供了另外兩種內存分配的策略，用戶可以根據實際需要選擇不同的內存分配策略。
第1種方法是，按照需求內存的大小簡單地把一大塊內存分割爲若干小塊，每個小塊的大小對應於所需求內存的大小。這樣做的好處是比較簡單，執行時間可嚴格確定，適用於任務和隊列全部創建完畢後再進行內核調度的系統；這樣做的缺點是，由於內存不能有效釋放，系統運行時應用程序並不能實現刪除任務或隊列。
第2種方法是，採用鏈表分配內存，可實現動態的創建、刪除任務或隊列。系統根據空閒內存塊的大小按從小到大的順序組織空閒內存鏈表。當應用程序申請一塊內存時，系統根據申請內存的大小按順序搜索空閒內存鏈表，找到滿足申請內存要求的最小空閒內存塊。爲了提高內存的使用效率，在空閒內存塊比申請內存大的情況下，系統會把此空閒內存塊一分爲二。一塊用於滿足申請內存的要求，一塊作爲新的空閒內存塊插入到鏈表中。
下面以圖2爲例介紹方法2的實現。假定用於動態分配的RAM共有8KB，系統首先初始化空閒內存塊鏈表，把8KB RAM全部作爲一個空閒內存塊。當應用程序分別申請1KB和2KB內存後，空閒內存塊的大小變爲5KB3。2KB的內存使用完畢後，系統需要把2KB插入到現有的空閒內存塊鏈表。由於2 KB<5KB，所以把這2 KB插入5KB的內存塊之前。若應用程序又需要申請3 KB的內存，而在空閒內存塊鏈表中能滿足申請內存要求的最小空閒內存塊爲5KB，因此把5KB內存拆分爲2部分，3KB部分用於滿足申請內存的需要，2KB部分作爲新的空閒內存塊插入鏈表。隨後1KB的內存使用完畢需要釋放，系統會按順序把1KB內存插入到空閒內存鏈表中。
![]()
圖2 採用空閒內存塊鏈表進行內存管理
方法2的優點是，能根據任務需要高效率地使用內存，尤其是當不同的任務需要不同大小的內存的時候。方法二的缺點是，不能把應用程序釋放的內存和原有的空閒內存混合爲一體，因此，若應用程序頻繁申請與釋放“隨機”大小的內存，就可能造成大量的內存碎片。這就要求應用程序申請與釋放內存的大小爲“有限個”固定的值(如圖2中申請與釋放內存的大小固定爲l KB、2 KB或3 KB)。方法2的另一個缺點是，程序執行時間具有一定的不確定性。
μC／OS—II提供的內存管理機制是把連續的大塊內存按分區來管理，每個分區中包含整數個大小相同的內存塊。由於每個分區的大小相同，即使頻繁地申請和釋放內存也不會產生內存碎片問題，但其缺點是內存的利用率相對不高。當申請和釋放的內存大小均爲一個固定值時(如均爲2 KB)，FreeRTOS的方法2內存分配策略就可以實現類似μC／OS—Ⅱ的內存管理效果。
2.5 FreeRTOS的移植
FreeRTOS操作系統可以被方便地移植到不同處理器上工作，現已提供了ARM、MSP430、AVR、PIC、C8051F等多款處理器的移植。FrceRTOS在不同處理器上的移植類似於μC／0S一II，故本文不再詳述FreeRTOS的移植。此外，TCP／IP協議棧μIP已被移植到FreeRTOS上，具體代碼可見FreeRTOS網站。
2.6 FreeRTOS的不足
相對於常見的μC／OS—II操作系統，FreeRTOS操作系統既有優點也存在不足。其不足之處，一方面體現在系統的服務功能上，如FreeRTOS只提供了消息隊列和信號量的實現，無法以後進先出的順序向消息隊列發送消息；另一方面，FreeRTOS只是一個操作系統內核，需外擴第三方的GUI(圖形用戶界面)、TCP／IP協議棧、FS(文件系統)等才能實現一個較複雜的系統，不像μC／OS-II可以和μC／GUI、μC／FS、μC／TCP-IP等無縫結合。
3、結 論
作爲一個源碼公開的操作系統，學習FreeRTOS可以更好地掌握嵌入式實時操作系統的實現原理；作爲一個免費的操作系統，採用FreeRTOS可在基本滿足較小系統需要的情況下降低系統成本、簡化開發難度。在實踐中，採用FreeRTOS操作系統和MSP430單片機構成的溫度控制系統穩定可靠，實現了較好的控制效果。相信隨着時間的發展，FreeRTOS會不斷完善其功能，以更好地滿足人們對嵌入式操作系統實時性、可靠性、易用性的要求。
