學習梳理一下FreeRTOS任務(wù)管理單元實現(xiàn)思路，代碼分析基于V10.4.3。從本文開始計劃寫個圖解freeRTOS內(nèi)核系列筆記分享給朋友們，希望大家喜歡。文章中或有錯誤，也請留言交流指正

本文主要學習梳理FreeRTOS任務(wù)管理器的基本原理，大體框架。

內(nèi)核任務(wù)管理器需求

先來對比一下裸奔系統(tǒng)與RTOS應(yīng)用系統(tǒng)的編程模型，看看兩種編程的不同畫風。

裸奔系統(tǒng)

在不用RTOS的單片機應(yīng)用開發(fā)時，編程模型大概是這樣的畫風：

程序的主體是一個死循環(huán)，該應(yīng)用程序由一系列協(xié)同工作的函數(shù)片段組成，相互實現(xiàn)邏輯配合，實現(xiàn)用戶業(yè)務(wù)需求。該應(yīng)用程序獨占單片機，常規(guī)的單片機系統(tǒng)都僅有有一個計算單元核。

普通外設(shè)I/O,這里所說I/O是指廣義的I/O，比如GPIO、PWM、ADC、DAC、LCD顯示（當然這里并不嚴謹，比如ADC,DAC、LCD等也可以產(chǎn)生中斷）等。中斷函數(shù)將異步事件接收成或報文或標志或數(shù)值，在與主循環(huán)發(fā)生邏輯關(guān)聯(lián)。

中斷外設(shè)，比如UART、USB、I2C、定時器、DMA等根據(jù)應(yīng)用需求而使用的中斷。這些中斷都需要相應(yīng)的中斷函數(shù)進行處理異步中斷事件。對于輸出可能采樣主動輸出，一般由主循環(huán)某一個動作執(zhí)行；對于輸入設(shè)備或許采用輪詢方式，在與主循環(huán)進行耦合。

RTOS應(yīng)用系統(tǒng)

在一個基于RTOS應(yīng)用系統(tǒng)中，其編程模型大致是下面這樣一個畫風，有多個并行的任務(wù)在相對長的宏觀時間維度看起來，多個任務(wù)是并行運行的，但對于常規(guī)單片機而言（一般都是單核），任一時刻只有一個任務(wù)或中斷函數(shù)在獨占CPU核。

常見的RTOS沒有設(shè)備驅(qū)動模型，沒有對外設(shè)設(shè)備進行抽象，中斷函數(shù)將會由用戶或調(diào)用RTOS 機制，比如event/signal等與任務(wù)進行通信

任務(wù)間還有可能需要通信，或傳遞消息，或完成某項需求相互間需要同步等

同樣任務(wù)需要與硬件普通IO外設(shè)進行打交道，或入或出。但有可能是這個任務(wù)實現(xiàn)，也有可能是哪個任務(wù)執(zhí)行。完全取決于開發(fā)人員如何設(shè)計。

RTOS實現(xiàn)任務(wù)的切入切出，切入使某任務(wù)運行；切出使某任務(wù)掛起，出讓CPU，暫停運行。

RTOS充當?shù)讓又С止δ埽琑TOS還提供豐富的時間管理，隊列、郵箱等機制供應(yīng)用開發(fā)使用。

......

對于單片機而言，一般只有一個核，所有RTOS為了方便理解，可以看成是最最主要的目就是通過軟件方法將硬件CPU核程序運行環(huán)境抽象為每一個應(yīng)用任務(wù)虛擬出一個軟核。這樣從時間維度上看起來多任務(wù)是并行的，而事實上這種并行是偽并行。

上圖僅僅為理解RTOS作用方便，這種虛擬核本質(zhì)上并不存在，只是將硬件CPU核的運行時上下文（PC指針、狀態(tài)寄存器等寄存器組、任務(wù)運行時臨時變量等）通過快照保存切入切出而實現(xiàn)多任務(wù)的偽并行運行。

FreeRTOS任務(wù)管理器需求

從前文看出，任務(wù)管理要實現(xiàn)任務(wù)的切入、切出，則首先需要對任務(wù)進行抽象描述，以實現(xiàn)在CPU上能夠?qū)崿F(xiàn)切換。根據(jù)閱讀代碼以及文獻加上自己的理解，將內(nèi)核任務(wù)管理器的主要功能需求大致梳理成下面這樣一張用例圖Use case Diagram，僅僅為理解方便，或許并不嚴謹。

從上圖，大致可以看出FreeRTOS任務(wù)調(diào)度器需要以下一些功能需求：

任務(wù)抽象描述，一個任務(wù)一般本質(zhì)上是一個死循環(huán)程序片段（當然也有任務(wù)運行著會退出被殺掉的可能）。對于任務(wù)的抽象：

一般會有任務(wù)的執(zhí)行主體，利用函數(shù)主體函數(shù)指針進行抽象

RTOS常規(guī)都是的基于優(yōu)先級搶占調(diào)度算法，因此需要抽象出哪個任務(wù)具有更高概率能被執(zhí)行，用優(yōu)先級進行描述

任務(wù)需要得以切換，就需要將任務(wù)在切換間的臨時狀態(tài)進行保存，棧機制就能很好的滿足這樣的需求，因此每個任務(wù)都有一個或大或小的任務(wù)棧。其本質(zhì)上是一片連續(xù)的FILO（先入后出）內(nèi)存。

.....

任務(wù)創(chuàng)建、刪除等API接口，供應(yīng)用開發(fā)使用。

任務(wù)調(diào)度器控制接口，啟動調(diào)度器、停止調(diào)度器、掛起所有任務(wù)、恢復運行等調(diào)度器接口。

任務(wù)雜項信息接口，比如獲取任務(wù)狀態(tài)、tick信息、調(diào)試、獲取任務(wù)名等API接口

任務(wù)調(diào)度算法，基于調(diào)度策略對運行時的任務(wù)進行調(diào)度，或掛起、或運行、或就緒等，主要根據(jù)調(diào)度策略管理任務(wù)的切入切出。這里主要涉及到任務(wù)間上下文切換、任務(wù)與中斷函數(shù)間的上下文切換兩種場景。

抽象C運行時環(huán)境，現(xiàn)代RTOS應(yīng)用系統(tǒng)一般基于C語言，抽象C運行時環(huán)境，這里主要指棧，當然很多RTOS內(nèi)核也內(nèi)核堆，freeRTOS也不例外。熟悉C編程的朋友都知道，堆內(nèi)存由malloc/free函數(shù)操作集提供用戶接口，既然C堆已有，為何RTOS內(nèi)核重新造輪子？為啥內(nèi)核額外需要實現(xiàn)自己的堆管理器呢？這大體是基于下面些緣由：

編譯器C堆實現(xiàn)，在小型嵌入式系統(tǒng)上有時候并不能直接使用。

C堆的實現(xiàn)可能相對較大，占用了較大代碼空間。比較浪費有限的代碼存儲空間。

C堆很少是線程安全的。

C堆申請執(zhí)行時間不是確定的， 執(zhí)行功能所需的時間因調(diào)用而異。

C堆會在單片機有限的內(nèi)存資源引發(fā)內(nèi)存碎片問題。

C堆會使鏈接器配置復雜化。

C堆如引發(fā)未知錯誤，不便于調(diào)試。

FreeRTOS任務(wù)描述抽象

對于其中幾項必須的關(guān)鍵數(shù)據(jù)域描述一下其抽象作用：

pxTopOfStack：指向任務(wù)棧棧頂指針

xStateListItem：任務(wù)狀態(tài)鏈表描述節(jié)點，用于動態(tài)將該任務(wù)添加、刪除到就緒或阻塞任務(wù)對列鏈表中

xEventListItem：事件鏈表描述節(jié)點，描述本任務(wù)相關(guān)事件，用于將本任務(wù)添加到事件鏈表中。

uxPriority：任務(wù)優(yōu)先級，用于描述本任務(wù)的優(yōu)先級。

pxStack：任務(wù)棧指針，指向本任務(wù)的任務(wù)棧。

pcTaskName：任務(wù)名字符串存儲區(qū)，長度可配。默認為16字節(jié)

其他的數(shù)據(jù)域，可裁剪實現(xiàn)一些更豐富的功能，比如主要用于防治優(yōu)先級反轉(zhuǎn)的優(yōu)先級繼承機制，trace追蹤功能等。限于篇幅，也主要梳理任務(wù)管理器的主要原理，就不展開了。

任務(wù)創(chuàng)建刪除管理

FreeRTOS為用戶提供一組函數(shù)集用于任務(wù)的創(chuàng)建、刪除等管理，先看任務(wù)的創(chuàng)建API：

xTaskCreate/xTaskCreateStatic 都是用于創(chuàng)建任務(wù)而用，其區(qū)別在于：

xTaskCreate 申請任務(wù)控制塊以及棧從內(nèi)核堆申請

xTaskCreateStatic 創(chuàng)建的任務(wù)，其任務(wù)控制塊內(nèi)存以及任務(wù)棧內(nèi)存由用戶傳入?；蛟S有朋友會問StaticTask_t這不是任務(wù)控制塊嘛，仔細看看其結(jié)構(gòu)定義其內(nèi)存對齊及大小剛好是前面說的任務(wù)控制塊的定義。

xTaskCreateRestricted() /xTaskCreateRestrictedStatic(),主要用于在有或使能MPU單元的芯片中創(chuàng)建任務(wù)。這里的MPU是指Memory Protection Unit (MPU)，不是微處理器的意思。這兩者的區(qū)別與上面兩個API類似，主要在于其內(nèi)存分配方式不同，xTaskCreateRestricted是從內(nèi)核堆動態(tài)申請，xTaskCreateRestrictedStatic用戶傳入。

PRIVILEGED_FUNCTION 這個宏是用于存儲保護單元芯片的。

這幾個任務(wù)創(chuàng)建函數(shù)都是用于任務(wù)創(chuàng)建，任務(wù)一旦創(chuàng)建就會被插入任務(wù)就緒鏈表中，當調(diào)度器調(diào)度啟動后就按任務(wù)狀態(tài)機根據(jù)調(diào)度策略以及外部輸入事件進行調(diào)度接管。這里以xTaskCreate繪制一下其內(nèi)在干了些啥：

再看看另外兩個函數(shù)：

vTaskAllocateMPURegions: 定義一組內(nèi)存保護單元（MPU）區(qū)域，供MPU受限任務(wù)使用.

vTaskDelete: 刪除用使用xTaskCreate()或xTaskCreateStatic()創(chuàng)建的任務(wù)。

任務(wù)控制管理接口

這一系列的API接口操作集主要用于對任務(wù)進行掛起延時、獲取優(yōu)先級、自中斷函數(shù)獲取優(yōu)先級、掛起、恢復運行等操作?；緩钠浜瘮?shù)名就可以看出其作用。比如：

vTaskDelay調(diào)用，會使調(diào)用該函數(shù)的任務(wù)進入阻塞狀態(tài)一段時間，時間為傳入的tick數(shù)。

這里需要注意的是有的函數(shù)在中斷函數(shù)體里面不可以調(diào)用，需要使用專用版本，具體可以看看手冊或注釋。

調(diào)度器控制接口

這一組函數(shù)API集主要用于調(diào)度器的啟動、停止控制：

vTaskStartScheduler，主要用于待用戶任務(wù)創(chuàng)建好后，硬件初始化后，啟動內(nèi)核調(diào)度器

vTaskEndScheduler，可用于停止內(nèi)核調(diào)度器，一般很少用到，在一些安全相關(guān)的應(yīng)用可能會在出故障時主動停止調(diào)度器。

vTaskSuspendAll，掛起所有任務(wù)，可以用用戶邏輯主動掛起所有的任務(wù)

xTaskResumeAll，恢復所有任務(wù)為就緒態(tài)。

任務(wù)雜項API集

我根據(jù)代碼及注釋及自己理解，將這些API歸類到雜項API集合：

這些函數(shù)具體作用就不贅述，這里僅僅梳理分類，用到時候查手冊即可。

跨平臺移植接口

這些接口不同硬件平臺需要做具化的移植，做差異化的處理，但是對于FreeRTOS統(tǒng)一了內(nèi)部調(diào)用的接口。這樣的思路在應(yīng)用開發(fā)時也可以考慮使用，對于公共部分可以抽象出統(tǒng)一的接口，這樣在不同平臺上可以很方便的進行移植。對于這些接口后面有機會學習整理分享。

對于用例圖中的其他部分，核心調(diào)度部分以及上下文切換，篇幅所限留在后面學習整理分享。

總結(jié)一下

本文基本學習梳理了一下對于FreeRTOS任務(wù)調(diào)度器外部接口、以及大體作用，基本組成情況，水平所限，文章中錯誤難免，歡迎交流指正。

責任編輯：xj

原文標題：圖解FreeRTOS 原理系列之任務(wù)管理器基本框架

文章出處：【微信公眾號：嵌入式ARM】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。