踐：任務(wù)調(diào)度、隊(duì)列與STM32移植詳解)
1. 為什么嵌入式工程師繞不開RTOS1.1 從裸機(jī)到RTOS思維發(fā)生了什么變化先說個(gè)很常見的場景。很多做單片機(jī)的朋友一開始都是跑裸機(jī)程序main函數(shù)里一個(gè)while(1)輪詢各種標(biāo)志位或者靠中斷置位、主循環(huán)處理。這種前后臺(tái)系統(tǒng)在功能簡單時(shí)完全夠用代碼也好調(diào)試?？梢坏╉?xiàng)目里同時(shí)出現(xiàn)按鍵掃描、OLED刷新、傳感器采集、串口透傳、電機(jī)控制你會(huì)發(fā)現(xiàn)自己開始陷入一種“拆東墻補(bǔ)西墻”的節(jié)奏要保證電機(jī)響應(yīng)及時(shí)就得提高中斷頻率但中斷太頻繁又會(huì)拖慢主循環(huán)想在主循環(huán)里加個(gè)狀態(tài)機(jī)處理復(fù)雜邏輯又怕漏掉某個(gè)IO口的變化。最難受的是一旦某個(gè)功能需要阻塞等待比如串口收一幀數(shù)據(jù)整個(gè)系統(tǒng)的實(shí)時(shí)性就被拉垮了。RTOS解決的就是這個(gè)核心問題把一個(gè)大循環(huán)拆成多個(gè)獨(dú)立的小循環(huán)每個(gè)小循環(huán)對應(yīng)一個(gè)任務(wù)由調(diào)度器決定哪個(gè)任務(wù)在什么時(shí)間占用CPU。這樣一來電機(jī)控制、界面刷新、通信處理各管各的邏輯上徹底解耦代碼的可維護(hù)性好了一個(gè)量級(jí)。FreeRTOS作為全球市場占有率最高的開源RTOS生態(tài)最成熟、學(xué)習(xí)資料最多、版權(quán)策略對商業(yè)產(chǎn)品也足夠友好所以我的建議很直接如果你打算學(xué)RTOS從FreeRTOS入手基本不會(huì)走彎路。當(dāng)然RTOS不是銀彈。它引入的調(diào)度開銷、優(yōu)先級(jí)設(shè)計(jì)、資源競爭問題在非常簡單的項(xiàng)目里反而顯得多余。我個(gè)人的判斷標(biāo)準(zhǔn)是當(dāng)你的項(xiàng)目里已經(jīng)有三個(gè)以上需要“并行”處理的業(yè)務(wù)模塊并且模塊之間存在明顯的等待關(guān)系時(shí)就該認(rèn)真考慮引入RTOS了。后面要講的思路、機(jī)制和踩坑經(jīng)驗(yàn)也是圍繞這個(gè)標(biāo)準(zhǔn)展開的。1.2 “實(shí)時(shí)”到底指什么很多初學(xué)者第一次接觸Real Time Operating System這個(gè)概念時(shí)容易把“實(shí)時(shí)”理解為“速度快”。其實(shí)實(shí)時(shí)指的更多是確定性也就是系統(tǒng)能否在規(guī)定時(shí)間內(nèi)完成規(guī)定操作。一個(gè)低優(yōu)先級(jí)任務(wù)被更高優(yōu)先級(jí)任務(wù)搶占后系統(tǒng)能不能保證它在下一次調(diào)度周期內(nèi)繼續(xù)運(yùn)行這個(gè)“保證”才是實(shí)時(shí)的核心。FreeRTOS是典型的軟實(shí)時(shí)系統(tǒng)它靠優(yōu)先級(jí)搶占式調(diào)度來保證“高優(yōu)先級(jí)任務(wù)先跑”但它并不保證具體的截止時(shí)間。翻譯成人話就是如果你的項(xiàng)目要求“某個(gè)中斷發(fā)生后5微秒內(nèi)必須開始響應(yīng)”那這是硬實(shí)時(shí)約束需要靠中斷服務(wù)程序和精心設(shè)計(jì)的臨界區(qū)來保證如果你的項(xiàng)目只是要求“觸摸事件及時(shí)響應(yīng)不能有明顯卡頓”那FreeRTOS完全能勝任。我自己在做項(xiàng)目時(shí)習(xí)慣先列一張實(shí)時(shí)性需求表把每個(gè)模塊允許的最大響應(yīng)延遲寫清楚再?zèng)Q定哪些功能放中斷、哪些放高優(yōu)先級(jí)任務(wù)、哪些放低優(yōu)先級(jí)任務(wù)。這個(gè)習(xí)慣救了我很多次。比如有個(gè)產(chǎn)品按鍵消抖和串口命令解析如果都放同一個(gè)低優(yōu)先級(jí)任務(wù)會(huì)導(dǎo)致按鍵偶爾延遲響應(yīng)后來把按鍵掃描單獨(dú)提到中優(yōu)先級(jí)任務(wù)串口解析留在低優(yōu)先級(jí)卡頓問題立刻消失。2. 先搞懂FreeRTOS的調(diào)度內(nèi)核2.1 任務(wù)是怎么被調(diào)度的在FreeRTOS里一個(gè)任務(wù)本質(zhì)就是一個(gè)帶死循環(huán)的普通C函數(shù)。它看起來是這樣void vTaskA(void *pvParameters) { while (1) { // 業(yè)務(wù)邏輯 vTaskDelay(pdMS_TO_TICKS(100)); } }但光有函數(shù)還不夠你還需要告訴內(nèi)核這個(gè)任務(wù)的優(yōu)先級(jí)、堆棧大小、入口函數(shù)等信息也就是調(diào)用xTaskCreate后續(xù)章節(jié)會(huì)細(xì)講。創(chuàng)建成功后調(diào)度器就開始接管了。它維護(hù)著一張就緒鏈表里面按優(yōu)先級(jí)排著所有可以運(yùn)行的任務(wù)。調(diào)度器每次做調(diào)度決策時(shí)做的事非常簡單找出當(dāng)前最高優(yōu)先級(jí)的就緒任務(wù)讓它的現(xiàn)場寄存器、棧指針等加載到CPU上運(yùn)行。FreeRTOS最核心的調(diào)度機(jī)制有兩個(gè)。一個(gè)是優(yōu)先級(jí)搶占式調(diào)度如果高優(yōu)先級(jí)任務(wù)進(jìn)入就緒態(tài)它立刻搶占當(dāng)前運(yùn)行的低優(yōu)先級(jí)任務(wù)哪怕低優(yōu)先級(jí)任務(wù)只跑了一行代碼。另一個(gè)是時(shí)間片輪轉(zhuǎn)調(diào)度所有同優(yōu)先級(jí)任務(wù)按順序輪流運(yùn)行一個(gè)時(shí)間片通常是1個(gè)tick或按配置決定時(shí)間一到就切換到下一個(gè)。這兩個(gè)機(jī)制疊加就是你在很多資料里看到的“搶占式時(shí)間片”調(diào)度策略。我把任務(wù)調(diào)度的思維模型比作醫(yī)院分診優(yōu)先級(jí)比喻病情的緊急程度急診病人來了普通門診必須讓位同級(jí)別的病人按排隊(duì)順序依次就診。這個(gè)類比雖然簡單但足夠解釋90%的調(diào)度現(xiàn)象了。你只需要記住在FreeRTOS里描述任務(wù)優(yōu)先級(jí)時(shí)數(shù)字越大優(yōu)先級(jí)越高——這一點(diǎn)和很多實(shí)時(shí)系統(tǒng)是反的初學(xué)經(jīng)常搞混。2.2 tick、上下文切換與臨界區(qū)FreeRTOS的心跳叫tick由系統(tǒng)節(jié)拍定時(shí)器Cortex-M上通常是SysTick周期性產(chǎn)生中斷默認(rèn)情況下1ms觸發(fā)一次你可以通過configTICK_RATE_HZ配置我一般配1000也就是1ms一個(gè)tick。每個(gè)tick中斷調(diào)度器都會(huì)檢查一次任務(wù)狀態(tài)決定要不要切換。這就是系統(tǒng)“感知時(shí)間”的基礎(chǔ)vTaskDelay、超時(shí)等待這些功能都依賴它。每次任務(wù)切換內(nèi)核要做一件聽起來簡單但實(shí)際很繁瑣的事情保存當(dāng)前任務(wù)的CPU寄存器和棧指針然后恢復(fù)下一個(gè)任務(wù)之前保存的現(xiàn)場。這個(gè)過程叫上下文切換在Cortex-M處理器上由PendSV異常配合SysTick完成。之所以用PendSV而不是直接在SysTick中斷里切換是為了避免在中斷處理過程中做危險(xiǎn)操作——設(shè)計(jì)中PendSV是優(yōu)先級(jí)最低的異常所有高優(yōu)先級(jí)中斷處理完之后才會(huì)真正進(jìn)入任務(wù)切換從而保證系統(tǒng)的高實(shí)時(shí)性。臨界區(qū)則是另一個(gè)必須理解的概念。多個(gè)任務(wù)共享全局變量時(shí)如果不加以保護(hù)會(huì)被調(diào)度器在任意時(shí)刻打斷產(chǎn)生數(shù)據(jù)錯(cuò)亂。FreeRTOS的做法是關(guān)中斷——在臨界區(qū)內(nèi)調(diào)度器無法運(yùn)行任務(wù)不會(huì)被搶占。但關(guān)中斷的代價(jià)很大它是“殺敵一千自損八百”的手段所以臨界區(qū)要盡量短。我的經(jīng)驗(yàn)是臨界區(qū)里只做變量修改和標(biāo)志位翻轉(zhuǎn)絕對不放延時(shí)、打印、復(fù)雜運(yùn)算。像串口打印這種操作放在臨界區(qū)外用隊(duì)列異步處理更合適。3. 基于STM32的FreeRTOS移植實(shí)錄3.1 移植前的準(zhǔn)備與文件選擇FreeRTOS移植在STM32上非常成熟甚至你用STM32CubeMX點(diǎn)幾下就能生成一個(gè)帶FreeRTOS的工程。但我覺得學(xué)習(xí)階段最好還是手動(dòng)搞一次最小移植搞清楚每個(gè)文件是干嘛的這樣以后遇到問題才知道往哪個(gè)方向查。先從官網(wǎng)或GitHub下載源碼解壓后的目錄結(jié)構(gòu)需要注意幾個(gè)關(guān)鍵位置根目錄下的FreeRTOS/Source是內(nèi)核核心代碼其中tasks.c、queue.c、list.c、timers.c、event_groups.c、stream_buffer.c這些必須了解各自作用但不需要全部加入工程。portable目錄是按編譯器和架構(gòu)劃分的可移植層比如Cortex-M4F內(nèi)核在GCC下用portable/GCC/ARM_CM4F在Keil下用portable/RVDS/ARM_CM4F。這里需要根據(jù)你的芯片和開發(fā)環(huán)境仔細(xì)選。portable/MemMang提供了heap_1到heap_5五種內(nèi)存管理實(shí)現(xiàn)最常用的是heap_4它支持碎片合并和刪除任務(wù)后的內(nèi)存釋放優(yōu)先選它。移植一個(gè)最小工程必須包含的文件有tasks.c、queue.c、list.c以及對應(yīng)的port.c和heap_4.c。如果你要用軟件定時(shí)器加timers.c要用事件組加event_groups.c。文件選好后還有一個(gè)關(guān)鍵配置文件FreeRTOSConfig.h里面定義了tick頻率、堆大小、最大任務(wù)數(shù)、是否開啟鉤子函數(shù)等。這個(gè)文件不在源碼目錄里需要自己創(chuàng)建或從示例工程里拷貝它決定內(nèi)核的“性格”必須仔細(xì)核對每個(gè)宏。3.2 CubeMX快速生成一個(gè)最小可運(yùn)行工程如果你用STM32CubeMX整個(gè)移植過程能壓縮到幾分鐘。我的做法是在CubeMX里選好芯片型號(hào)在System Core里找到SYSTimebase Source選擇SysTick之外的定時(shí)器比如TIM6。為什么因?yàn)镕reeRTOS默認(rèn)占用了SysTick作為系統(tǒng)tick如果你把HAL庫的時(shí)基也掛在SysTick上啟動(dòng)后會(huì)直接沖突現(xiàn)象就是程序一跑就卡死或HardFault。這個(gè)坑十個(gè)人里有九個(gè)會(huì)踩。然后切換到Middleware and Software Packs勾選FreeRTOSInterface選擇CMSIS_V1HAL標(biāo)準(zhǔn)或CMSIS_V2兩者的API封裝略有不同新版推薦CMSIS_V2功能更全。接著就可以在Tasks標(biāo)簽頁里看到系統(tǒng)自動(dòng)創(chuàng)建了一個(gè)defaultTask你可以直接改名字、優(yōu)先級(jí)和入口函數(shù)。生成代碼后在main()里會(huì)自動(dòng)調(diào)用MX_FREERTOS_Init()創(chuàng)建任務(wù)后調(diào)用osKernelStart()啟動(dòng)調(diào)度器。但這里有個(gè)很關(guān)鍵的細(xì)節(jié)CubeMX生成的MX_FREERTOS_Init()是在main()中調(diào)用的但osKernelStart()并不會(huì)返回。所以任何在任務(wù)啟動(dòng)前需要執(zhí)行的初始化代碼比如外設(shè)初始化、全局變量賦值必須在MX_FREERTOS_Init()之前完成。我見過不少同事在新工程里加了一大堆初始化代碼結(jié)果全是“跑不到”的死代碼因?yàn)檎{(diào)度器啟動(dòng)后主線程就永遠(yuǎn)停在osKernelStart()里了。3.3 第一版任務(wù)的驗(yàn)證要點(diǎn)移植完之后第一件事不是寫業(yè)務(wù)而是驗(yàn)證調(diào)度器能不能正常跑起來。我習(xí)慣用一個(gè)最簡單的LED閃爍任務(wù)來驗(yàn)證任務(wù)里調(diào)vTaskDelay延時(shí)200ms并翻轉(zhuǎn)LED引腳。為什么用這個(gè)因?yàn)槿绻{(diào)度器沒跑起來LED要么不亮要么不閃現(xiàn)象非常直觀。驗(yàn)證時(shí)有幾個(gè)要點(diǎn)值得注意。第一檢查configMINIMAL_STACK_SIZECubeMX默認(rèn)生成的值通常夠用但如果你在任務(wù)函數(shù)里聲明了大數(shù)組或調(diào)用了printf就可能不夠棧溢出會(huì)引起HardFault且很難從代碼邏輯上定位。第二確認(rèn)configTOTAL_HEAP_SIZE它決定所有任務(wù)堆棧的總預(yù)算是多少如果創(chuàng)建任務(wù)失敗先查這里。第三確認(rèn)configUSE_PREEMPTION設(shè)為1否則系統(tǒng)變成協(xié)作式調(diào)度高優(yōu)先級(jí)任務(wù)不會(huì)主動(dòng)搶占行為會(huì)和預(yù)期差很多。這個(gè)階段如果出問題我建議先不要懷疑源碼Bug。九成以上是配置問題、文件漏加或啟動(dòng)順序不對。你用調(diào)試器停在HardFault_Handler里看?；厮莺蚿xCurrentTCB基本能定位到是哪個(gè)任務(wù)出了問題。4. 動(dòng)手寫第一個(gè)多任務(wù)程序4.1 任務(wù)創(chuàng)建的核心參數(shù)先貼一段最常用的任務(wù)創(chuàng)建代碼這是FreeRTOS入門的“Hello World”TaskHandle_t xTaskALedHandle NULL; void Task_LED(void *param) { while (1) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); vTaskDelay(pdMS_TO_TICKS(500)); } } void Task_Print(void *param) { while (1) { printf(tick: %lu\r\n, (unsigned long)xTaskGetTickCount()); vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); xTaskCreate(Task_LED, LED, 128, NULL, 3, xTaskALedHandle); xTaskCreate(Task_Print, Print, 256, NULL, 5, NULL); vTaskStartScheduler(); while (1) { // 正常情況下永遠(yuǎn)不會(huì)運(yùn)行到這里 } }xTaskCreate有6個(gè)參數(shù)我逐個(gè)說下經(jīng)驗(yàn)第1個(gè)是入口函數(shù)注意函數(shù)簽名必須是void func(void *param)param由第4個(gè)參數(shù)傳入。第2個(gè)是任務(wù)名主要用于調(diào)試和查看任務(wù)列表不能超過configMAX_TASK_NAME_LEN。第3個(gè)是堆棧大小FreeRTOS里單位是“字”不是字節(jié)在32位單片機(jī)上128表示512字節(jié)。我給串口打印任務(wù)至少256字1KB因?yàn)閜rintf系列函數(shù)會(huì)吃不少棧空間。第4個(gè)是傳入?yún)?shù)沒用就傳NULL。第5個(gè)是優(yōu)先級(jí)數(shù)值越大優(yōu)先級(jí)越高?？臻e任務(wù)優(yōu)先級(jí)是0所以你的業(yè)務(wù)任務(wù)優(yōu)先級(jí)至少給1。第6個(gè)是任務(wù)句柄指針可以用來掛起、刪除、等待任務(wù)不需要就傳NULL。很多人一上來就想挑戰(zhàn)復(fù)雜架構(gòu)我反而建議先把兩個(gè)任務(wù)跑通感受一下“任務(wù)自己跑自己的”是怎么一回事再說后面的設(shè)計(jì)。4.2 時(shí)間片輪轉(zhuǎn)和優(yōu)先級(jí)搶占的實(shí)測前面代碼里我故意讓兩個(gè)任務(wù)的優(yōu)先級(jí)不同LED是3Print是5這就意味著Print任務(wù)永遠(yuǎn)優(yōu)先于LED。如果你在串口助手里看打印頻率會(huì)發(fā)現(xiàn)LED翻轉(zhuǎn)速度其實(shí)會(huì)受到printf執(zhí)行時(shí)間的影響因?yàn)镻rint任務(wù)只要在運(yùn)行就會(huì)一直占著CPU直到主動(dòng)調(diào)用vTaskDelay讓出。如果你想讓兩個(gè)同優(yōu)先級(jí)任務(wù)輪流跑可以把它們都設(shè)成3。這時(shí)FreeRTOS會(huì)按時(shí)間片輪轉(zhuǎn)調(diào)度每個(gè)任務(wù)默認(rèn)跑一個(gè)tick1ms后切換到下一個(gè)。不過要注意vTaskDelay(pdMS_TO_TICKS(500))會(huì)讓任務(wù)主動(dòng)阻塞500個(gè)tick在這個(gè)阻塞期間它不參與輪轉(zhuǎn)直到延時(shí)結(jié)束才回到就緒態(tài)。所以同優(yōu)先級(jí)任務(wù)的“輪流”指的是多個(gè)任務(wù)都處于就緒狀態(tài)時(shí)的調(diào)度規(guī)則不是單純按次數(shù)排隊(duì)。實(shí)測優(yōu)先級(jí)搶占時(shí)有一個(gè)很直觀的例子把LED任務(wù)優(yōu)先級(jí)設(shè)為5、Print任務(wù)優(yōu)先級(jí)設(shè)為3然后讓Print任務(wù)在while(1)里持續(xù)進(jìn)行一個(gè)耗時(shí)運(yùn)算比如浮點(diǎn)累乘你會(huì)發(fā)現(xiàn)LED幾乎不閃了。因?yàn)镻rint一進(jìn)入就緒態(tài)就搶占CPU而它又不主動(dòng)讓出時(shí)間片。這個(gè)現(xiàn)象不是Bug恰恰是優(yōu)先級(jí)搶占的正常表現(xiàn)。理解了這一點(diǎn)你就能明白為什么高優(yōu)先級(jí)的任務(wù)不能做長耗時(shí)操作——它會(huì)把低優(yōu)先級(jí)任務(wù)“餓死”。4.3 用隊(duì)列讓任務(wù)間“通信”多任務(wù)系統(tǒng)里任務(wù)間需要傳遞數(shù)據(jù)最常用的機(jī)制是隊(duì)列。隊(duì)列就像一個(gè)帶鎖的信箱一個(gè)任務(wù)往信箱里塞數(shù)據(jù)另一個(gè)任務(wù)從信箱里取數(shù)據(jù)兩邊都不需要關(guān)心對方在哪個(gè)CPU時(shí)間片運(yùn)行。隊(duì)列底層是環(huán)形緩沖區(qū)但FreeRTOS在讀寫隊(duì)列時(shí)還做了阻塞和喚醒的機(jī)制。核心API就三個(gè)套路很固定QueueHandle_t xQueue; xQueue xQueueCreate(10, sizeof(uint8_t)); // 參數(shù)1隊(duì)列長度參數(shù)2每個(gè)元素的大小 // 發(fā)送在任務(wù)里用帶超時(shí)時(shí)間 uint8_t data 0x01; xQueueSend(xQueue, data, portMAX_DELAY); // 接收在任務(wù)里用帶超時(shí)時(shí)間 uint8_t recv; xQueueReceive(xQueue, recv, portMAX_DELAY);注意portMAX_DELAY表示永久等待任務(wù)會(huì)進(jìn)入阻塞狀態(tài)直到有數(shù)據(jù)或延時(shí)超時(shí)。它不消耗CPU這正是RTOS的價(jià)值所在——比起裸機(jī)里用while輪詢等待標(biāo)志位任務(wù)阻塞時(shí)CPU可以去做別的事。我給一個(gè)實(shí)際生產(chǎn)中用得比較多的模式一個(gè)按鍵檢測任務(wù)每隔10ms掃描一次按鍵檢測到按下就把鍵值發(fā)到隊(duì)列另一個(gè)界面刷新任務(wù)阻塞在隊(duì)列上收到鍵值就更新OLED屏。兩個(gè)任務(wù)互不干擾即使按鍵處理非常頻繁也不會(huì)卡住界面刷新。這就是典型的生產(chǎn)者-消費(fèi)者模型也是FreeRTOS里最常用、最好調(diào)試的結(jié)構(gòu)。相比之下用全局變量標(biāo)志位的方案在任務(wù)多了以后代碼會(huì)亂成一鍋粥出了Bug根本不知道是誰改的。5. 常見問題與避坑技巧實(shí)錄5.1 堆棧溢出這類隱蔽問題怎么定位堆棧溢出可能是FreeRTOS里最令人頭疼的問題它不會(huì)立刻報(bào)錯(cuò)而是表現(xiàn)為隨機(jī)死機(jī)、變量被莫名篡改、函數(shù)返回地址錯(cuò)亂。原因很簡單任務(wù)調(diào)用函數(shù)時(shí)局部變量、返回地址、被調(diào)用函數(shù)的棧幀都放在任務(wù)棧里棧不夠用就會(huì)往相鄰內(nèi)存區(qū)域?qū)懺浇绨褎e的任務(wù)或系統(tǒng)內(nèi)核的數(shù)據(jù)踩壞。對付它FreeRTOS提供了兩層探測機(jī)制。第一層是configCHECK_FOR_STACK_OVERFLOW設(shè)為1時(shí)系統(tǒng)會(huì)在任務(wù)切換時(shí)檢查棧指針是否越界設(shè)為2時(shí)檢查會(huì)更嚴(yán)格會(huì)去校驗(yàn)棧頂區(qū)域的值是否被破壞。第二層是需要你自己實(shí)現(xiàn)的鉤子函數(shù)vApplicationStackOverflowHook一旦檢測到溢出系統(tǒng)會(huì)調(diào)用它。我的建議是調(diào)試驗(yàn)證階段直接設(shè)為2并在鉤子里點(diǎn)亮LED或進(jìn)入死循環(huán)方便第一時(shí)間發(fā)現(xiàn)。發(fā)布版本再關(guān)掉省一點(diǎn)開銷。但工具只是輔助關(guān)鍵是別讓棧不夠用。我總結(jié)的經(jīng)驗(yàn)是任務(wù)棧以“字”為單位普通任務(wù)翻轉(zhuǎn)LED、讀IO給128字就夠涉及串口打印、浮點(diǎn)運(yùn)算、modbus協(xié)議棧、printf的任務(wù)給256到512字比較穩(wěn)妥如果你在任務(wù)里用snprintf格式化長字符串直接上512字以上否則遲早出事。實(shí)在拿不準(zhǔn)可以臨時(shí)把棧翻倍測試如果問題消失說明?？隙ú粔?。最后分享一個(gè)定位技巧在任務(wù)函數(shù)入口、出口和while(1)循環(huán)里分別打印或保存uxTaskGetStackHighWaterMark()的返回值這個(gè)接口能告訴你任務(wù)棧歷史最低剩余量單位是字。把高水位標(biāo)記記錄下來你就能準(zhǔn)確知道每個(gè)任務(wù)實(shí)際用了多少棧再據(jù)此優(yōu)化配置。5.2 中斷優(yōu)先級(jí)配置為何直接導(dǎo)致死機(jī)在裸機(jī)開發(fā)時(shí)你可能從來沒仔細(xì)想過NVIC中斷優(yōu)先級(jí)的具體數(shù)值。但一旦用上FreeRTOS中斷優(yōu)先級(jí)的配置就變成“安全紅線”級(jí)別的問題。核心原因在于FreeRTOS在臨界區(qū)是通過關(guān)中斷實(shí)現(xiàn)的它對你的中斷優(yōu)先級(jí)分成了兩組可以調(diào)用的系統(tǒng)API的如xQueueSendFromISR和不可以調(diào)用的。在Cortex-M處理器上數(shù)值越大優(yōu)先級(jí)越低。FreeRTOS通過configMAX_SYSCALL_INTERRUPT_PRIORITY來劃分邊界優(yōu)先級(jí)數(shù)值大于這個(gè)宏的中斷也就是邏輯優(yōu)先級(jí)低于宏會(huì)受調(diào)度器和臨界區(qū)保護(hù)可以在中斷里調(diào)用FromISR結(jié)尾的API優(yōu)先級(jí)數(shù)值小于或等于這個(gè)宏的中斷邏輯優(yōu)先級(jí)過高不受臨界區(qū)保護(hù)絕對不能在里面調(diào)用FreeRTOS的API否則可能直接死機(jī)或?qū)е孪到y(tǒng)不穩(wěn)定。我見過最典型的死法把外部中斷優(yōu)先級(jí)設(shè)為最低數(shù)值0邏輯最高優(yōu)先級(jí)然后在中斷服務(wù)函數(shù)里調(diào)用xQueueSendFromISR?？雌饋泶a沒問題實(shí)際跑起來卻是隨機(jī)死機(jī)。原因是臨界區(qū)關(guān)閉中斷的“范圍”覆蓋不到這個(gè)高優(yōu)先級(jí)中斷它可能在調(diào)度器正在修改鏈表時(shí)打斷系統(tǒng)把隊(duì)列結(jié)構(gòu)改壞。正確做法是把SysTick和PendSV中斷優(yōu)先級(jí)設(shè)為最高的數(shù)值邏輯最低比如在STM32上設(shè)15把普通外設(shè)中斷設(shè)為它和configMAX_SYSCALL_INTERRUPT_PRIORITY之間的合理值。CubeMX生成的代碼默認(rèn)會(huì)幫你設(shè)置好但如果你手動(dòng)寫寄存器初始化中斷一定要非常小心。建議所有用到的外設(shè)中斷優(yōu)先級(jí)統(tǒng)一給一個(gè)中間值既保證實(shí)時(shí)響應(yīng)又能安全調(diào)用FreeRTOS API。5.3 優(yōu)先級(jí)反轉(zhuǎn)和互斥量優(yōu)先級(jí)反轉(zhuǎn)這個(gè)概念很多人只在面試題里見過但實(shí)際項(xiàng)目中真的會(huì)踩坑。簡單描述就是一個(gè)高優(yōu)先級(jí)任務(wù)H在等待一個(gè)信號(hào)量而這個(gè)信號(hào)量被低優(yōu)先級(jí)任務(wù)L持有此時(shí)優(yōu)先級(jí)中等的任務(wù)M不斷就緒因?yàn)樗鼉?yōu)先級(jí)高于L導(dǎo)致L一直無法運(yùn)行、無法釋放信號(hào)量于是H也被“卡”住。表面上看是優(yōu)先級(jí)更高的H在等優(yōu)先級(jí)更低的M系統(tǒng)表現(xiàn)非常反直覺。FreeRTOS里解決優(yōu)先級(jí)反轉(zhuǎn)的標(biāo)準(zhǔn)方案是互斥量它能啟動(dòng)優(yōu)先級(jí)繼承機(jī)制。當(dāng)高優(yōu)先級(jí)任務(wù)H在等待互斥量時(shí)系統(tǒng)會(huì)臨時(shí)把持有互斥量的低優(yōu)先級(jí)任務(wù)L的優(yōu)先級(jí)提升到H的優(yōu)先級(jí)這樣M即使就緒也無法搶占LL順利運(yùn)行并釋放互斥量H立刻獲得資源繼續(xù)執(zhí)行。它和信號(hào)量的區(qū)別在于互斥量帶有所有權(quán)概念只能由持鎖任務(wù)自己釋放信號(hào)量主要用于事件通知和資源計(jì)數(shù)沒有優(yōu)先級(jí)繼承機(jī)制。我自己的習(xí)慣是只要任務(wù)是用來保護(hù)共享資源的就用互斥量而不是二值信號(hào)量只有需要做事件通知時(shí)才用二值信號(hào)量。這個(gè)選擇能省去大量時(shí)序問題的排查時(shí)間。用互斥量還要注意另一個(gè)細(xì)節(jié)FreeRTOS會(huì)在configUSE_RECURSIVE_MUTEXES開啟時(shí)支持遞歸互斥量也就是同一任務(wù)可以重復(fù)獲取同一把鎖但要成對調(diào)用xSemaphoreTake和xSemaphoreGive否則釋放次數(shù)不對永遠(yuǎn)鎖死。這個(gè)“優(yōu)先級(jí)反轉(zhuǎn)遞歸鎖”的組合算是我見過FreeRTOS項(xiàng)目里最復(fù)雜的交叉故障一旦出現(xiàn)沒有調(diào)試技巧真的會(huì)懷疑人生。我在接觸FreeRTOS的初期被中斷優(yōu)先級(jí)配置、堆棧溢出這些隱性坑折磨過不少次。后來養(yǎng)成了一個(gè)習(xí)慣每做一個(gè)新項(xiàng)目先花半天時(shí)間把FreeRTOSConfig.h里的所有宏過一遍搞清楚每一個(gè)開關(guān)是干什么的絕不拿來就用。這個(gè)習(xí)慣看起來慢實(shí)際上能省掉后面幾天的排查時(shí)間。這篇文章是FreeRTOS系列的第一篇重點(diǎn)是把“RTOS到底在解決什么問題”和“任務(wù)調(diào)度、隊(duì)列、互斥量這些基礎(chǔ)機(jī)制是怎么運(yùn)作的”講透。下一篇我會(huì)結(jié)合一個(gè)實(shí)際項(xiàng)目完整演示一個(gè)多任務(wù)系統(tǒng)從需求分析、任務(wù)劃分到編碼實(shí)現(xiàn)的全過程包括優(yōu)先級(jí)怎么定、隊(duì)列怎么規(guī)劃、棧大小怎么估算。那部分內(nèi)容比今天的更貼近實(shí)際工程到時(shí)候你可以直接照著做。 FreeRTOS從入門到實(shí)踐：任務(wù)調(diào)度、隊(duì)列與STM32移植詳解
1. 為什么嵌入式工程師繞不開RTOS1.1 從裸機(jī)到RTOS思維發(fā)生了什么變化先說個(gè)很常見的場景。很多做單片機(jī)的朋友一開始都是跑裸機(jī)程序main函數(shù)里一個(gè)while(1)輪詢各種標(biāo)志位或者靠中斷置位、主循環(huán)處理。這種前后臺(tái)系統(tǒng)在功能簡單時(shí)完全夠用代碼也好調(diào)試?？梢坏╉?xiàng)目里同時(shí)出現(xiàn)按鍵掃描、OLED刷新、傳感器采集、串口透傳、電機(jī)控制你會(huì)發(fā)現(xiàn)自己開始陷入一種“拆東墻補(bǔ)西墻”的節(jié)奏要保證電機(jī)響應(yīng)及時(shí)就得提高中斷頻率但中斷太頻繁又會(huì)拖慢主循環(huán)想在主循環(huán)里加個(gè)狀態(tài)機(jī)處理復(fù)雜邏輯又怕漏掉某個(gè)IO口的變化。最難受的是一旦某個(gè)功能需要阻塞等待比如串口收一幀數(shù)據(jù)整個(gè)系統(tǒng)的實(shí)時(shí)性就被拉垮了。RTOS解決的就是這個(gè)核心問題把一個(gè)大循環(huán)拆成多個(gè)獨(dú)立的小循環(huán)每個(gè)小循環(huán)對應(yīng)一個(gè)任務(wù)由調(diào)度器決定哪個(gè)任務(wù)在什么時(shí)間占用CPU。這樣一來電機(jī)控制、界面刷新、通信處理各管各的邏輯上徹底解耦代碼的可維護(hù)性好了一個(gè)量級(jí)。FreeRTOS作為全球市場占有率最高的開源RTOS生態(tài)最成熟、學(xué)習(xí)資料最多、版權(quán)策略對商業(yè)產(chǎn)品也足夠友好所以我的建議很直接如果你打算學(xué)RTOS從FreeRTOS入手基本不會(huì)走彎路。當(dāng)然RTOS不是銀彈。它引入的調(diào)度開銷、優(yōu)先級(jí)設(shè)計(jì)、資源競爭問題在非常簡單的項(xiàng)目里反而顯得多余。我個(gè)人的判斷標(biāo)準(zhǔn)是當(dāng)你的項(xiàng)目里已經(jīng)有三個(gè)以上需要“并行”處理的業(yè)務(wù)模塊并且模塊之間存在明顯的等待關(guān)系時(shí)就該認(rèn)真考慮引入RTOS了。后面要講的思路、機(jī)制和踩坑經(jīng)驗(yàn)也是圍繞這個(gè)標(biāo)準(zhǔn)展開的。1.2 “實(shí)時(shí)”到底指什么很多初學(xué)者第一次接觸Real Time Operating System這個(gè)概念時(shí)容易把“實(shí)時(shí)”理解為“速度快”。其實(shí)實(shí)時(shí)指的更多是確定性也就是系統(tǒng)能否在規(guī)定時(shí)間內(nèi)完成規(guī)定操作。一個(gè)低優(yōu)先級(jí)任務(wù)被更高優(yōu)先級(jí)任務(wù)搶占后系統(tǒng)能不能保證它在下一次調(diào)度周期內(nèi)繼續(xù)運(yùn)行這個(gè)“保證”才是實(shí)時(shí)的核心。FreeRTOS是典型的軟實(shí)時(shí)系統(tǒng)它靠優(yōu)先級(jí)搶占式調(diào)度來保證“高優(yōu)先級(jí)任務(wù)先跑”但它并不保證具體的截止時(shí)間。翻譯成人話就是如果你的項(xiàng)目要求“某個(gè)中斷發(fā)生后5微秒內(nèi)必須開始響應(yīng)”那這是硬實(shí)時(shí)約束需要靠中斷服務(wù)程序和精心設(shè)計(jì)的臨界區(qū)來保證如果你的項(xiàng)目只是要求“觸摸事件及時(shí)響應(yīng)不能有明顯卡頓”那FreeRTOS完全能勝任。我自己在做項(xiàng)目時(shí)習(xí)慣先列一張實(shí)時(shí)性需求表把每個(gè)模塊允許的最大響應(yīng)延遲寫清楚再?zèng)Q定哪些功能放中斷、哪些放高優(yōu)先級(jí)任務(wù)、哪些放低優(yōu)先級(jí)任務(wù)。這個(gè)習(xí)慣救了我很多次。比如有個(gè)產(chǎn)品按鍵消抖和串口命令解析如果都放同一個(gè)低優(yōu)先級(jí)任務(wù)會(huì)導(dǎo)致按鍵偶爾延遲響應(yīng)后來把按鍵掃描單獨(dú)提到中優(yōu)先級(jí)任務(wù)串口解析留在低優(yōu)先級(jí)卡頓問題立刻消失。2. 先搞懂FreeRTOS的調(diào)度內(nèi)核2.1 任務(wù)是怎么被調(diào)度的在FreeRTOS里一個(gè)任務(wù)本質(zhì)就是一個(gè)帶死循環(huán)的普通C函數(shù)。它看起來是這樣void vTaskA(void *pvParameters) { while (1) { // 業(yè)務(wù)邏輯 vTaskDelay(pdMS_TO_TICKS(100)); } }但光有函數(shù)還不夠你還需要告訴內(nèi)核這個(gè)任務(wù)的優(yōu)先級(jí)、堆棧大小、入口函數(shù)等信息也就是調(diào)用xTaskCreate后續(xù)章節(jié)會(huì)細(xì)講。創(chuàng)建成功后調(diào)度器就開始接管了。它維護(hù)著一張就緒鏈表里面按優(yōu)先級(jí)排著所有可以運(yùn)行的任務(wù)。調(diào)度器每次做調(diào)度決策時(shí)做的事非常簡單找出當(dāng)前最高優(yōu)先級(jí)的就緒任務(wù)讓它的現(xiàn)場寄存器、棧指針等加載到CPU上運(yùn)行。FreeRTOS最核心的調(diào)度機(jī)制有兩個(gè)。一個(gè)是優(yōu)先級(jí)搶占式調(diào)度如果高優(yōu)先級(jí)任務(wù)進(jìn)入就緒態(tài)它立刻搶占當(dāng)前運(yùn)行的低優(yōu)先級(jí)任務(wù)哪怕低優(yōu)先級(jí)任務(wù)只跑了一行代碼。另一個(gè)是時(shí)間片輪轉(zhuǎn)調(diào)度所有同優(yōu)先級(jí)任務(wù)按順序輪流運(yùn)行一個(gè)時(shí)間片通常是1個(gè)tick或按配置決定時(shí)間一到就切換到下一個(gè)。這兩個(gè)機(jī)制疊加就是你在很多資料里看到的“搶占式時(shí)間片”調(diào)度策略。我把任務(wù)調(diào)度的思維模型比作醫(yī)院分診優(yōu)先級(jí)比喻病情的緊急程度急診病人來了普通門診必須讓位同級(jí)別的病人按排隊(duì)順序依次就診。這個(gè)類比雖然簡單但足夠解釋90%的調(diào)度現(xiàn)象了。你只需要記住在FreeRTOS里描述任務(wù)優(yōu)先級(jí)時(shí)數(shù)字越大優(yōu)先級(jí)越高——這一點(diǎn)和很多實(shí)時(shí)系統(tǒng)是反的初學(xué)經(jīng)常搞混。2.2 tick、上下文切換與臨界區(qū)FreeRTOS的心跳叫tick由系統(tǒng)節(jié)拍定時(shí)器Cortex-M上通常是SysTick周期性產(chǎn)生中斷默認(rèn)情況下1ms觸發(fā)一次你可以通過configTICK_RATE_HZ配置我一般配1000也就是1ms一個(gè)tick。每個(gè)tick中斷調(diào)度器都會(huì)檢查一次任務(wù)狀態(tài)決定要不要切換。這就是系統(tǒng)“感知時(shí)間”的基礎(chǔ)vTaskDelay、超時(shí)等待這些功能都依賴它。每次任務(wù)切換內(nèi)核要做一件聽起來簡單但實(shí)際很繁瑣的事情保存當(dāng)前任務(wù)的CPU寄存器和棧指針然后恢復(fù)下一個(gè)任務(wù)之前保存的現(xiàn)場。這個(gè)過程叫上下文切換在Cortex-M處理器上由PendSV異常配合SysTick完成。之所以用PendSV而不是直接在SysTick中斷里切換是為了避免在中斷處理過程中做危險(xiǎn)操作——設(shè)計(jì)中PendSV是優(yōu)先級(jí)最低的異常所有高優(yōu)先級(jí)中斷處理完之后才會(huì)真正進(jìn)入任務(wù)切換從而保證系統(tǒng)的高實(shí)時(shí)性。臨界區(qū)則是另一個(gè)必須理解的概念。多個(gè)任務(wù)共享全局變量時(shí)如果不加以保護(hù)會(huì)被調(diào)度器在任意時(shí)刻打斷產(chǎn)生數(shù)據(jù)錯(cuò)亂。FreeRTOS的做法是關(guān)中斷——在臨界區(qū)內(nèi)調(diào)度器無法運(yùn)行任務(wù)不會(huì)被搶占。但關(guān)中斷的代價(jià)很大它是“殺敵一千自損八百”的手段所以臨界區(qū)要盡量短。我的經(jīng)驗(yàn)是臨界區(qū)里只做變量修改和標(biāo)志位翻轉(zhuǎn)絕對不放延時(shí)、打印、復(fù)雜運(yùn)算。像串口打印這種操作放在臨界區(qū)外用隊(duì)列異步處理更合適。3. 基于STM32的FreeRTOS移植實(shí)錄3.1 移植前的準(zhǔn)備與文件選擇FreeRTOS移植在STM32上非常成熟甚至你用STM32CubeMX點(diǎn)幾下就能生成一個(gè)帶FreeRTOS的工程。但我覺得學(xué)習(xí)階段最好還是手動(dòng)搞一次最小移植搞清楚每個(gè)文件是干嘛的這樣以后遇到問題才知道往哪個(gè)方向查。先從官網(wǎng)或GitHub下載源碼解壓后的目錄結(jié)構(gòu)需要注意幾個(gè)關(guān)鍵位置根目錄下的FreeRTOS/Source是內(nèi)核核心代碼其中tasks.c、queue.c、list.c、timers.c、event_groups.c、stream_buffer.c這些必須了解各自作用但不需要全部加入工程。portable目錄是按編譯器和架構(gòu)劃分的可移植層比如Cortex-M4F內(nèi)核在GCC下用portable/GCC/ARM_CM4F在Keil下用portable/RVDS/ARM_CM4F。這里需要根據(jù)你的芯片和開發(fā)環(huán)境仔細(xì)選。portable/MemMang提供了heap_1到heap_5五種內(nèi)存管理實(shí)現(xiàn)最常用的是heap_4它支持碎片合并和刪除任務(wù)后的內(nèi)存釋放優(yōu)先選它。移植一個(gè)最小工程必須包含的文件有tasks.c、queue.c、list.c以及對應(yīng)的port.c和heap_4.c。如果你要用軟件定時(shí)器加timers.c要用事件組加event_groups.c。文件選好后還有一個(gè)關(guān)鍵配置文件FreeRTOSConfig.h里面定義了tick頻率、堆大小、最大任務(wù)數(shù)、是否開啟鉤子函數(shù)等。這個(gè)文件不在源碼目錄里需要自己創(chuàng)建或從示例工程里拷貝它決定內(nèi)核的“性格”必須仔細(xì)核對每個(gè)宏。3.2 CubeMX快速生成一個(gè)最小可運(yùn)行工程如果你用STM32CubeMX整個(gè)移植過程能壓縮到幾分鐘。我的做法是在CubeMX里選好芯片型號(hào)在System Core里找到SYSTimebase Source選擇SysTick之外的定時(shí)器比如TIM6。為什么因?yàn)镕reeRTOS默認(rèn)占用了SysTick作為系統(tǒng)tick如果你把HAL庫的時(shí)基也掛在SysTick上啟動(dòng)后會(huì)直接沖突現(xiàn)象就是程序一跑就卡死或HardFault。這個(gè)坑十個(gè)人里有九個(gè)會(huì)踩。然后切換到Middleware and Software Packs勾選FreeRTOSInterface選擇CMSIS_V1HAL標(biāo)準(zhǔn)或CMSIS_V2兩者的API封裝略有不同新版推薦CMSIS_V2功能更全。接著就可以在Tasks標(biāo)簽頁里看到系統(tǒng)自動(dòng)創(chuàng)建了一個(gè)defaultTask你可以直接改名字、優(yōu)先級(jí)和入口函數(shù)。生成代碼后在main()里會(huì)自動(dòng)調(diào)用MX_FREERTOS_Init()創(chuàng)建任務(wù)后調(diào)用osKernelStart()啟動(dòng)調(diào)度器。但這里有個(gè)很關(guān)鍵的細(xì)節(jié)CubeMX生成的MX_FREERTOS_Init()是在main()中調(diào)用的但osKernelStart()并不會(huì)返回。所以任何在任務(wù)啟動(dòng)前需要執(zhí)行的初始化代碼比如外設(shè)初始化、全局變量賦值必須在MX_FREERTOS_Init()之前完成。我見過不少同事在新工程里加了一大堆初始化代碼結(jié)果全是“跑不到”的死代碼因?yàn)檎{(diào)度器啟動(dòng)后主線程就永遠(yuǎn)停在osKernelStart()里了。3.3 第一版任務(wù)的驗(yàn)證要點(diǎn)移植完之后第一件事不是寫業(yè)務(wù)而是驗(yàn)證調(diào)度器能不能正常跑起來。我習(xí)慣用一個(gè)最簡單的LED閃爍任務(wù)來驗(yàn)證任務(wù)里調(diào)vTaskDelay延時(shí)200ms并翻轉(zhuǎn)LED引腳。為什么用這個(gè)因?yàn)槿绻{(diào)度器沒跑起來LED要么不亮要么不閃現(xiàn)象非常直觀。驗(yàn)證時(shí)有幾個(gè)要點(diǎn)值得注意。第一檢查configMINIMAL_STACK_SIZECubeMX默認(rèn)生成的值通常夠用但如果你在任務(wù)函數(shù)里聲明了大數(shù)組或調(diào)用了printf就可能不夠棧溢出會(huì)引起HardFault且很難從代碼邏輯上定位。第二確認(rèn)configTOTAL_HEAP_SIZE它決定所有任務(wù)堆棧的總預(yù)算是多少如果創(chuàng)建任務(wù)失敗先查這里。第三確認(rèn)configUSE_PREEMPTION設(shè)為1否則系統(tǒng)變成協(xié)作式調(diào)度高優(yōu)先級(jí)任務(wù)不會(huì)主動(dòng)搶占行為會(huì)和預(yù)期差很多。這個(gè)階段如果出問題我建議先不要懷疑源碼Bug。九成以上是配置問題、文件漏加或啟動(dòng)順序不對。你用調(diào)試器停在HardFault_Handler里看?；厮莺蚿xCurrentTCB基本能定位到是哪個(gè)任務(wù)出了問題。4. 動(dòng)手寫第一個(gè)多任務(wù)程序4.1 任務(wù)創(chuàng)建的核心參數(shù)先貼一段最常用的任務(wù)創(chuàng)建代碼這是FreeRTOS入門的“Hello World”TaskHandle_t xTaskALedHandle NULL; void Task_LED(void *param) { while (1) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); vTaskDelay(pdMS_TO_TICKS(500)); } } void Task_Print(void *param) { while (1) { printf(tick: %lu\r\n, (unsigned long)xTaskGetTickCount()); vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); xTaskCreate(Task_LED, LED, 128, NULL, 3, xTaskALedHandle); xTaskCreate(Task_Print, Print, 256, NULL, 5, NULL); vTaskStartScheduler(); while (1) { // 正常情況下永遠(yuǎn)不會(huì)運(yùn)行到這里 } }xTaskCreate有6個(gè)參數(shù)我逐個(gè)說下經(jīng)驗(yàn)第1個(gè)是入口函數(shù)注意函數(shù)簽名必須是void func(void *param)param由第4個(gè)參數(shù)傳入。第2個(gè)是任務(wù)名主要用于調(diào)試和查看任務(wù)列表不能超過configMAX_TASK_NAME_LEN。第3個(gè)是堆棧大小FreeRTOS里單位是“字”不是字節(jié)在32位單片機(jī)上128表示512字節(jié)。我給串口打印任務(wù)至少256字1KB因?yàn)閜rintf系列函數(shù)會(huì)吃不少棧空間。第4個(gè)是傳入?yún)?shù)沒用就傳NULL。第5個(gè)是優(yōu)先級(jí)數(shù)值越大優(yōu)先級(jí)越高?？臻e任務(wù)優(yōu)先級(jí)是0所以你的業(yè)務(wù)任務(wù)優(yōu)先級(jí)至少給1。第6個(gè)是任務(wù)句柄指針可以用來掛起、刪除、等待任務(wù)不需要就傳NULL。很多人一上來就想挑戰(zhàn)復(fù)雜架構(gòu)我反而建議先把兩個(gè)任務(wù)跑通感受一下“任務(wù)自己跑自己的”是怎么一回事再說后面的設(shè)計(jì)。4.2 時(shí)間片輪轉(zhuǎn)和優(yōu)先級(jí)搶占的實(shí)測前面代碼里我故意讓兩個(gè)任務(wù)的優(yōu)先級(jí)不同LED是3Print是5這就意味著Print任務(wù)永遠(yuǎn)優(yōu)先于LED。如果你在串口助手里看打印頻率會(huì)發(fā)現(xiàn)LED翻轉(zhuǎn)速度其實(shí)會(huì)受到printf執(zhí)行時(shí)間的影響因?yàn)镻rint任務(wù)只要在運(yùn)行就會(huì)一直占著CPU直到主動(dòng)調(diào)用vTaskDelay讓出。如果你想讓兩個(gè)同優(yōu)先級(jí)任務(wù)輪流跑可以把它們都設(shè)成3。這時(shí)FreeRTOS會(huì)按時(shí)間片輪轉(zhuǎn)調(diào)度每個(gè)任務(wù)默認(rèn)跑一個(gè)tick1ms后切換到下一個(gè)。不過要注意vTaskDelay(pdMS_TO_TICKS(500))會(huì)讓任務(wù)主動(dòng)阻塞500個(gè)tick在這個(gè)阻塞期間它不參與輪轉(zhuǎn)直到延時(shí)結(jié)束才回到就緒態(tài)。所以同優(yōu)先級(jí)任務(wù)的“輪流”指的是多個(gè)任務(wù)都處于就緒狀態(tài)時(shí)的調(diào)度規(guī)則不是單純按次數(shù)排隊(duì)。實(shí)測優(yōu)先級(jí)搶占時(shí)有一個(gè)很直觀的例子把LED任務(wù)優(yōu)先級(jí)設(shè)為5、Print任務(wù)優(yōu)先級(jí)設(shè)為3然后讓Print任務(wù)在while(1)里持續(xù)進(jìn)行一個(gè)耗時(shí)運(yùn)算比如浮點(diǎn)累乘你會(huì)發(fā)現(xiàn)LED幾乎不閃了。因?yàn)镻rint一進(jìn)入就緒態(tài)就搶占CPU而它又不主動(dòng)讓出時(shí)間片。這個(gè)現(xiàn)象不是Bug恰恰是優(yōu)先級(jí)搶占的正常表現(xiàn)。理解了這一點(diǎn)你就能明白為什么高優(yōu)先級(jí)的任務(wù)不能做長耗時(shí)操作——它會(huì)把低優(yōu)先級(jí)任務(wù)“餓死”。4.3 用隊(duì)列讓任務(wù)間“通信”多任務(wù)系統(tǒng)里任務(wù)間需要傳遞數(shù)據(jù)最常用的機(jī)制是隊(duì)列。隊(duì)列就像一個(gè)帶鎖的信箱一個(gè)任務(wù)往信箱里塞數(shù)據(jù)另一個(gè)任務(wù)從信箱里取數(shù)據(jù)兩邊都不需要關(guān)心對方在哪個(gè)CPU時(shí)間片運(yùn)行。隊(duì)列底層是環(huán)形緩沖區(qū)但FreeRTOS在讀寫隊(duì)列時(shí)還做了阻塞和喚醒的機(jī)制。核心API就三個(gè)套路很固定QueueHandle_t xQueue; xQueue xQueueCreate(10, sizeof(uint8_t)); // 參數(shù)1隊(duì)列長度參數(shù)2每個(gè)元素的大小 // 發(fā)送在任務(wù)里用帶超時(shí)時(shí)間 uint8_t data 0x01; xQueueSend(xQueue, data, portMAX_DELAY); // 接收在任務(wù)里用帶超時(shí)時(shí)間 uint8_t recv; xQueueReceive(xQueue, recv, portMAX_DELAY);注意portMAX_DELAY表示永久等待任務(wù)會(huì)進(jìn)入阻塞狀態(tài)直到有數(shù)據(jù)或延時(shí)超時(shí)。它不消耗CPU這正是RTOS的價(jià)值所在——比起裸機(jī)里用while輪詢等待標(biāo)志位任務(wù)阻塞時(shí)CPU可以去做別的事。我給一個(gè)實(shí)際生產(chǎn)中用得比較多的模式一個(gè)按鍵檢測任務(wù)每隔10ms掃描一次按鍵檢測到按下就把鍵值發(fā)到隊(duì)列另一個(gè)界面刷新任務(wù)阻塞在隊(duì)列上收到鍵值就更新OLED屏。兩個(gè)任務(wù)互不干擾即使按鍵處理非常頻繁也不會(huì)卡住界面刷新。這就是典型的生產(chǎn)者-消費(fèi)者模型也是FreeRTOS里最常用、最好調(diào)試的結(jié)構(gòu)。相比之下用全局變量標(biāo)志位的方案在任務(wù)多了以后代碼會(huì)亂成一鍋粥出了Bug根本不知道是誰改的。5. 常見問題與避坑技巧實(shí)錄5.1 堆棧溢出這類隱蔽問題怎么定位堆棧溢出可能是FreeRTOS里最令人頭疼的問題它不會(huì)立刻報(bào)錯(cuò)而是表現(xiàn)為隨機(jī)死機(jī)、變量被莫名篡改、函數(shù)返回地址錯(cuò)亂。原因很簡單任務(wù)調(diào)用函數(shù)時(shí)局部變量、返回地址、被調(diào)用函數(shù)的棧幀都放在任務(wù)棧里棧不夠用就會(huì)往相鄰內(nèi)存區(qū)域?qū)懺浇绨褎e的任務(wù)或系統(tǒng)內(nèi)核的數(shù)據(jù)踩壞。對付它FreeRTOS提供了兩層探測機(jī)制。第一層是configCHECK_FOR_STACK_OVERFLOW設(shè)為1時(shí)系統(tǒng)會(huì)在任務(wù)切換時(shí)檢查棧指針是否越界設(shè)為2時(shí)檢查會(huì)更嚴(yán)格會(huì)去校驗(yàn)棧頂區(qū)域的值是否被破壞。第二層是需要你自己實(shí)現(xiàn)的鉤子函數(shù)vApplicationStackOverflowHook一旦檢測到溢出系統(tǒng)會(huì)調(diào)用它。我的建議是調(diào)試驗(yàn)證階段直接設(shè)為2并在鉤子里點(diǎn)亮LED或進(jìn)入死循環(huán)方便第一時(shí)間發(fā)現(xiàn)。發(fā)布版本再關(guān)掉省一點(diǎn)開銷。但工具只是輔助關(guān)鍵是別讓棧不夠用。我總結(jié)的經(jīng)驗(yàn)是任務(wù)棧以“字”為單位普通任務(wù)翻轉(zhuǎn)LED、讀IO給128字就夠涉及串口打印、浮點(diǎn)運(yùn)算、modbus協(xié)議棧、printf的任務(wù)給256到512字比較穩(wěn)妥如果你在任務(wù)里用snprintf格式化長字符串直接上512字以上否則遲早出事。實(shí)在拿不準(zhǔn)可以臨時(shí)把棧翻倍測試如果問題消失說明?？隙ú粔?。最后分享一個(gè)定位技巧在任務(wù)函數(shù)入口、出口和while(1)循環(huán)里分別打印或保存uxTaskGetStackHighWaterMark()的返回值這個(gè)接口能告訴你任務(wù)棧歷史最低剩余量單位是字。把高水位標(biāo)記記錄下來你就能準(zhǔn)確知道每個(gè)任務(wù)實(shí)際用了多少棧再據(jù)此優(yōu)化配置。5.2 中斷優(yōu)先級(jí)配置為何直接導(dǎo)致死機(jī)在裸機(jī)開發(fā)時(shí)你可能從來沒仔細(xì)想過NVIC中斷優(yōu)先級(jí)的具體數(shù)值。但一旦用上FreeRTOS中斷優(yōu)先級(jí)的配置就變成“安全紅線”級(jí)別的問題。核心原因在于FreeRTOS在臨界區(qū)是通過關(guān)中斷實(shí)現(xiàn)的它對你的中斷優(yōu)先級(jí)分成了兩組可以調(diào)用的系統(tǒng)API的如xQueueSendFromISR和不可以調(diào)用的。在Cortex-M處理器上數(shù)值越大優(yōu)先級(jí)越低。FreeRTOS通過configMAX_SYSCALL_INTERRUPT_PRIORITY來劃分邊界優(yōu)先級(jí)數(shù)值大于這個(gè)宏的中斷也就是邏輯優(yōu)先級(jí)低于宏會(huì)受調(diào)度器和臨界區(qū)保護(hù)可以在中斷里調(diào)用FromISR結(jié)尾的API優(yōu)先級(jí)數(shù)值小于或等于這個(gè)宏的中斷邏輯優(yōu)先級(jí)過高不受臨界區(qū)保護(hù)絕對不能在里面調(diào)用FreeRTOS的API否則可能直接死機(jī)或?qū)е孪到y(tǒng)不穩(wěn)定。我見過最典型的死法把外部中斷優(yōu)先級(jí)設(shè)為最低數(shù)值0邏輯最高優(yōu)先級(jí)然后在中斷服務(wù)函數(shù)里調(diào)用xQueueSendFromISR?？雌饋泶a沒問題實(shí)際跑起來卻是隨機(jī)死機(jī)。原因是臨界區(qū)關(guān)閉中斷的“范圍”覆蓋不到這個(gè)高優(yōu)先級(jí)中斷它可能在調(diào)度器正在修改鏈表時(shí)打斷系統(tǒng)把隊(duì)列結(jié)構(gòu)改壞。正確做法是把SysTick和PendSV中斷優(yōu)先級(jí)設(shè)為最高的數(shù)值邏輯最低比如在STM32上設(shè)15把普通外設(shè)中斷設(shè)為它和configMAX_SYSCALL_INTERRUPT_PRIORITY之間的合理值。CubeMX生成的代碼默認(rèn)會(huì)幫你設(shè)置好但如果你手動(dòng)寫寄存器初始化中斷一定要非常小心。建議所有用到的外設(shè)中斷優(yōu)先級(jí)統(tǒng)一給一個(gè)中間值既保證實(shí)時(shí)響應(yīng)又能安全調(diào)用FreeRTOS API。5.3 優(yōu)先級(jí)反轉(zhuǎn)和互斥量優(yōu)先級(jí)反轉(zhuǎn)這個(gè)概念很多人只在面試題里見過但實(shí)際項(xiàng)目中真的會(huì)踩坑。簡單描述就是一個(gè)高優(yōu)先級(jí)任務(wù)H在等待一個(gè)信號(hào)量而這個(gè)信號(hào)量被低優(yōu)先級(jí)任務(wù)L持有此時(shí)優(yōu)先級(jí)中等的任務(wù)M不斷就緒因?yàn)樗鼉?yōu)先級(jí)高于L導(dǎo)致L一直無法運(yùn)行、無法釋放信號(hào)量于是H也被“卡”住。表面上看是優(yōu)先級(jí)更高的H在等優(yōu)先級(jí)更低的M系統(tǒng)表現(xiàn)非常反直覺。FreeRTOS里解決優(yōu)先級(jí)反轉(zhuǎn)的標(biāo)準(zhǔn)方案是互斥量它能啟動(dòng)優(yōu)先級(jí)繼承機(jī)制。當(dāng)高優(yōu)先級(jí)任務(wù)H在等待互斥量時(shí)系統(tǒng)會(huì)臨時(shí)把持有互斥量的低優(yōu)先級(jí)任務(wù)L的優(yōu)先級(jí)提升到H的優(yōu)先級(jí)這樣M即使就緒也無法搶占LL順利運(yùn)行并釋放互斥量H立刻獲得資源繼續(xù)執(zhí)行。它和信號(hào)量的區(qū)別在于互斥量帶有所有權(quán)概念只能由持鎖任務(wù)自己釋放信號(hào)量主要用于事件通知和資源計(jì)數(shù)沒有優(yōu)先級(jí)繼承機(jī)制。我自己的習(xí)慣是只要任務(wù)是用來保護(hù)共享資源的就用互斥量而不是二值信號(hào)量只有需要做事件通知時(shí)才用二值信號(hào)量。這個(gè)選擇能省去大量時(shí)序問題的排查時(shí)間。用互斥量還要注意另一個(gè)細(xì)節(jié)FreeRTOS會(huì)在configUSE_RECURSIVE_MUTEXES開啟時(shí)支持遞歸互斥量也就是同一任務(wù)可以重復(fù)獲取同一把鎖但要成對調(diào)用xSemaphoreTake和xSemaphoreGive否則釋放次數(shù)不對永遠(yuǎn)鎖死。這個(gè)“優(yōu)先級(jí)反轉(zhuǎn)遞歸鎖”的組合算是我見過FreeRTOS項(xiàng)目里最復(fù)雜的交叉故障一旦出現(xiàn)沒有調(diào)試技巧真的會(huì)懷疑人生。我在接觸FreeRTOS的初期被中斷優(yōu)先級(jí)配置、堆棧溢出這些隱性坑折磨過不少次。后來養(yǎng)成了一個(gè)習(xí)慣每做一個(gè)新項(xiàng)目先花半天時(shí)間把FreeRTOSConfig.h里的所有宏過一遍搞清楚每一個(gè)開關(guān)是干什么的絕不拿來就用。這個(gè)習(xí)慣看起來慢實(shí)際上能省掉后面幾天的排查時(shí)間。這篇文章是FreeRTOS系列的第一篇重點(diǎn)是把“RTOS到底在解決什么問題”和“任務(wù)調(diào)度、隊(duì)列、互斥量這些基礎(chǔ)機(jī)制是怎么運(yùn)作的”講透。下一篇我會(huì)結(jié)合一個(gè)實(shí)際項(xiàng)目完整演示一個(gè)多任務(wù)系統(tǒng)從需求分析、任務(wù)劃分到編碼實(shí)現(xiàn)的全過程包括優(yōu)先級(jí)怎么定、隊(duì)列怎么規(guī)劃、棧大小怎么估算。那部分內(nèi)容比今天的更貼近實(shí)際工程到時(shí)候你可以直接照著做。