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