先級對比及遷移避坑指南)
做嵌入式這幾年只要一聊RTOS十有八九先問“跑幾個任務(wù)、棧開多大”。其實還有一個更底層的問題——線程優(yōu)先級。Zephyr和FreeRTOS在這件事上的思路完全不同從FreeRTOS遷到Zephyr時優(yōu)先級方向幾乎是反著來的很多人第一個坑就踩在這里。這篇文章就專門拆開“線程優(yōu)先級”這個點把兩邊的模型、源碼表現(xiàn)、實際遷移方法、優(yōu)先級翻轉(zhuǎn)、時間片、SMP場景下的差異一次講清楚。適合正用STM32CubeMX搭FreeRTOS項目的朋友也適合準(zhǔn)備轉(zhuǎn)向Zephyr做多協(xié)議/多核項目的開發(fā)者哪怕你只是面試前想搞明白任務(wù)優(yōu)先級和中斷優(yōu)先級到底差在哪這篇也能直接當(dāng)復(fù)習(xí)資料用。1. 優(yōu)先級模型的根本差異一個看數(shù)字大小一個看正負(fù)1.1 FreeRTOS的“數(shù)字越大越優(yōu)先”FreeRTOS的線程優(yōu)先級規(guī)則非常簡單直接取值范圍從0到configMAX_PRIORITIES - 1數(shù)值越大優(yōu)先級越高。0是最低優(yōu)先級通常被空閑任務(wù)Idle Task占用用戶任務(wù)一般至少從1開始往上排。比如你在CubeMX里配置一個任務(wù)優(yōu)先級為3、另一個為1那么優(yōu)先級3的任務(wù)只要進(jìn)入就緒態(tài)就能馬上搶占優(yōu)先級1的任務(wù)。這個模型在代碼層面很好理解TCB里存一個uxPriority字段調(diào)度器每次挑選任務(wù)時找“uxPriority最大且處于就緒態(tài)”的任務(wù)。因為數(shù)值越大越優(yōu)先所以它天然適合用位圖快速查找最高優(yōu)先級這也是FreeRTOS能夠做到O(1)調(diào)度的核心原因之一。實際項目里我見過不少人把優(yōu)先級理解成“分層越細(xì)越好”一個項目里從1到5排了十來個等級。其實FreeRTOS的優(yōu)先級數(shù)量不是越多越好。優(yōu)先級越多調(diào)度器維護(hù)就緒鏈表和位圖的開銷越大而且高優(yōu)先級任務(wù)過多搶占低優(yōu)先級任務(wù)更容易被“餓死”。官方文檔也建議優(yōu)先級數(shù)量夠用就行不必追求十幾二十個。1.2 Zephyr的“數(shù)字越小越優(yōu)先”與協(xié)作/搶占兩級體系到了Zephyr這邊規(guī)則直接反過來數(shù)字越小優(yōu)先級越高。而且它不是單純“反一下”這么簡單因為Zephyr把線程優(yōu)先級分成兩段——負(fù)數(shù)是協(xié)作式Cooperative優(yōu)先級非負(fù)數(shù)是搶占式Preemptive優(yōu)先級。具體來說協(xié)作式線程的可配置優(yōu)先級范圍是-CONFIG_NUM_COOP_PRIORITIES到-1搶占式線程的可配置優(yōu)先級范圍是0到CONFIG_NUM_PREEMPT_PRIORITIES - 1。比如你配置CONFIG_NUM_COOP_PRIORITIES2、CONFIG_NUM_PREEMPT_PRIORITIES6那么合法優(yōu)先級就是-2、-1、0、1、2、3、4、5。其中-2最高5最低。為什么負(fù)數(shù)反而是最高優(yōu)先級因為Zephyr調(diào)度器統(tǒng)一按“數(shù)值最小者先執(zhí)行”來選線程。負(fù)數(shù)天然小于所有非負(fù)數(shù)所以協(xié)作式線程整體上排在所有搶占式線程前面。但有個重要前提協(xié)作式線程一旦開始運行即使更高優(yōu)先級的搶占式線程就緒了也不能打斷它必須等協(xié)作式線程主動調(diào)用k_yield()、k_sleep()或者等待某個內(nèi)核對象時調(diào)度器才有機(jī)會切換到其他線程。這個設(shè)計其實是把“非搶占調(diào)度”和“搶占調(diào)度”融合進(jìn)了同一個優(yōu)先級體系而不是像FreeRTOS那樣所有任務(wù)默認(rèn)都是搶占式的。你在FreeRTOS里幾乎不會碰到“任務(wù)不讓出CPU就沒法切走”的情況但在Zephyr里如果協(xié)作式線程寫了個死循環(huán)且沒有任何阻塞調(diào)用整個系統(tǒng)都能被它卡死。1.3 一張表看懂映射關(guān)系兩邊的核心差異可以先壓成一張表后面再逐一展開對比項FreeRTOSZephyr優(yōu)先級方向數(shù)字越大越優(yōu)先數(shù)字越小越優(yōu)先默認(rèn)最低優(yōu)先級0空閑任務(wù)占用CONFIG_NUM_PREEMPT_PRIORITIES - 1數(shù)值最大是否有系統(tǒng)級空閑任務(wù)有優(yōu)先級0有優(yōu)先級低于所有用戶可配優(yōu)先級協(xié)作式線程無單獨概念普通任務(wù)可被搶占負(fù)優(yōu)先級線程運行后不可被搶占需主動讓出搶占式線程所有普通任務(wù)非負(fù)優(yōu)先級線程優(yōu)先級范圍0 ~configMAX_PRIORITIES - 1-CONFIG_NUM_COOP_PRIORITIES~CONFIG_NUM_PREEMPT_PRIORITIES - 1動態(tài)修改APIvTaskPrioritySetk_thread_priority_set遷移時最粗暴但有效的方法就是做一個“相對等級映射表”。比如FreeRTOS任務(wù)優(yōu)先級1到4對應(yīng)Zephyr的3、2、1、0保持次序不變即可。后面第三節(jié)我會用一個實際STM32工程舉例。2. 從源碼層面看優(yōu)先級“藏”在哪里2.1 FreeRTOSTCB優(yōu)先級與就緒位圖FreeRTOS的每個任務(wù)核心數(shù)據(jù)結(jié)構(gòu)叫tskTaskControlBlock簡稱TCB里面存著當(dāng)前優(yōu)先級uxPriority和初始優(yōu)先級uxBasePriority。uxBasePriority的主要用途是配合互斥量的優(yōu)先級繼承機(jī)制在解鎖后恢復(fù)原來的優(yōu)先級。這東西在日常應(yīng)用層開發(fā)中看不到但排查優(yōu)先級翻轉(zhuǎn)問題時會非常有用。就緒狀態(tài)的任務(wù)會按優(yōu)先級被掛到一組鏈表數(shù)組里也就是pxReadyTasksLists[configMAX_PRIORITIES]同一優(yōu)先級的多個就緒任務(wù)串在同一個鏈表中。調(diào)度器找一個最高優(yōu)先級任務(wù)時會先通過位圖找到“當(dāng)前最高非空優(yōu)先級”再從這個優(yōu)先級對應(yīng)的鏈表中取出第一個任務(wù)。這就是FreeRTOS所謂O(1)調(diào)度的時間來源。當(dāng)你調(diào)用vTaskPrioritySet()修改一個任務(wù)的優(yōu)先級時內(nèi)核會把該任務(wù)從原來優(yōu)先級的就緒鏈表摘下來改成新優(yōu)先級后再重新插入對應(yīng)的鏈表。如果這個任務(wù)本來就在運行而且新優(yōu)先級比當(dāng)前運行任務(wù)更高內(nèi)核會立刻請求一次上下文切換。這也是FreeRTOS動態(tài)優(yōu)先級能立即生效的原因。源碼層面的另一個關(guān)鍵是portGET_HIGHEST_PRIORITY這類宏。在Cortex-M平臺上它通常借助一個32位位圖變量用CLZ指令或者查表法快速找到最高優(yōu)先級。不同MCU移植層可能會微調(diào)但思路都一樣。如果你只是用CubeMX生成模板一般不關(guān)心這些但真正遇到“調(diào)度延遲異?！边@類問題就得回到這里看是哪個宏拖慢了查找速度。2.2 Zephyrk_thread.prio與統(tǒng)一就緒隊列Zephyr的線程內(nèi)核對象是struct k_thread優(yōu)先級字段就叫prio一個普通的signed int。創(chuàng)建線程時可以指定優(yōu)先級比如用K_THREAD_DEFINE宏定義線程時第三個參數(shù)就是優(yōu)先級也可以用k_thread_create()動態(tài)創(chuàng)建傳入優(yōu)先級參數(shù)。和FreeRTOS“每個優(yōu)先級一個鏈表”不同Zephyr內(nèi)核里維護(hù)的是一個統(tǒng)一的就緒隊列_ready_q所有就緒線程都塞到這個隊列里按優(yōu)先級排序并用位圖輔助快速找到“數(shù)值最小且非空的優(yōu)先級”。從調(diào)度算法上說它同樣是近似O(1)的但數(shù)據(jù)結(jié)構(gòu)上比FreeRTOS更統(tǒng)一。由于優(yōu)先級是int類型源碼里可以直接比較比如內(nèi)核在決定“當(dāng)前線程還能不能繼續(xù)跑”時會拿當(dāng)前線程優(yōu)先級和就緒隊列頭部線程優(yōu)先級做比較。如果就緒隊列頭部的線程優(yōu)先級數(shù)值更小說明出現(xiàn)了更高優(yōu)先級的搶占式線程調(diào)度器就會觸發(fā)切換。Zephyr還允許你通過k_thread_priority_set()在運行期修改線程優(yōu)先級。這個API和FreeRTOS的vTaskPrioritySet()行為不完全一樣如果目標(biāo)線程是搶占式線程且新優(yōu)先級足夠高調(diào)度器可能立即重新調(diào)度如果目標(biāo)線程是協(xié)作式線程那么即使改了優(yōu)先級也要等到它主動讓出CPU后才可能切換過去。說白了協(xié)作式優(yōu)先級更像“下一次調(diào)度時的排序權(quán)重”而不是“馬上就能搶占的開關(guān)”。2.3 動態(tài)優(yōu)先級修改的調(diào)度差異很多從FreeRTOS遷到Zephyr的人會把vTaskPrioritySet(task, 3)直接翻譯成k_thread_priority_set(thread, 3)覺得結(jié)果一樣。實際上方向不一樣在FreeRTOS里你把任務(wù)優(yōu)先級改成3是“升位”在Zephyr里改成3反而會“降位”。這不是API用法問題而是優(yōu)先級模型本身的差異。更隱蔽的是協(xié)作式線程的優(yōu)先級修改。在FreeRTOS中不存在“協(xié)作式任務(wù)不可被搶占”的概念所有任務(wù)只要處于就緒態(tài)且優(yōu)先級更高就能切走當(dāng)前任務(wù)。Zephyr里則不同你讓一個協(xié)作式線程從-2改成-1它依然不會立刻被打斷它可能正在一個循環(huán)里做密集型計算改完優(yōu)先級后系統(tǒng)看起來毫無反應(yīng)直到它主動讓出CPU。所以我的建議是凡是涉及動態(tài)調(diào)整優(yōu)先級的代碼一定要在寫注釋時標(biāo)明“當(dāng)前代碼運行在線程上下文還是中斷上下文”“目標(biāo)線程是協(xié)作式還是搶占式”。這兩個條件決定了下一次調(diào)度到底何時發(fā)生踩過一次協(xié)作式線程的坑以后你會對這句話印象特別深。3. 實際項目中的優(yōu)先級分配與遷移以STM32LVGL為例3.1 FreeRTOS項目里我慣用的優(yōu)先級分檔先拿一個典型的STM32F407項目舉例跑LVGL做界面顯示外接溫濕度傳感器用Wi-Fi模塊上報數(shù)據(jù)再加幾個按鍵輸入。這種項目用CubeMX配置FreeRTOS非常順手任務(wù)不會太多我一般這么排優(yōu)先級任務(wù)功能FreeRTOS優(yōu)先級網(wǎng)絡(luò)通信任務(wù)Wi-Fi數(shù)據(jù)收發(fā)、協(xié)議解析4業(yè)務(wù)邏輯任務(wù)傳感器數(shù)據(jù)融合、狀態(tài)機(jī)3LVGL刷新任務(wù)調(diào)用lv_task_handler或lv_timer_handler2按鍵/事件派發(fā)讀取GPIO、投遞事件到隊列2喂狗與統(tǒng)計任務(wù)喂獨立看門狗、打印任務(wù)棧水位1空閑任務(wù)系統(tǒng)自動創(chuàng)建0這里我特意把網(wǎng)絡(luò)通信排到最高因為Wi-Fi模塊如果處理不及時緩沖區(qū)會被塞滿導(dǎo)致丟包LVGL刷新排到中等保證界面不卡但又不至于搶走網(wǎng)絡(luò)資源喂狗任務(wù)排最低因為正常運行時所有任務(wù)都應(yīng)該活著如果優(yōu)先級高的任務(wù)卡死了喂狗任務(wù)也得不到執(zhí)行看門狗才能正確復(fù)位系統(tǒng)。這個方案在FreeRTOS下穩(wěn)定性很好。但如果直接平移去Zephyr不做方向反轉(zhuǎn)LVGL任務(wù)排2、網(wǎng)絡(luò)任務(wù)排4那Zephyr會把4當(dāng)成最低優(yōu)先級結(jié)果就是網(wǎng)絡(luò)任務(wù)餓死Wi-Fi瘋狂丟包。你查半天都查不出邏輯問題直到打印線程優(yōu)先級才發(fā)現(xiàn)數(shù)值反過來用了。3.2 遷移到Zephyr時的映射表做法在Zephyr上重建這套任務(wù)我會先在prj.conf里定義好優(yōu)先級空間CONFIG_NUM_PREEMPT_PRIORITIES6 CONFIG_NUM_COOP_PRIORITIES2這樣Zephyr的搶占式優(yōu)先級就是0到5協(xié)作式優(yōu)先級是-2和-1。接下來按相對次序做映射原FreeRTOS優(yōu)先級角色映射到Zephyr4網(wǎng)絡(luò)通信0搶占最高3業(yè)務(wù)邏輯1搶占2LVGL刷新2搶占2按鍵/事件2搶占同LVGL同優(yōu)先級1喂狗/統(tǒng)計3搶占最低無關(guān)鍵傳感器采集-1協(xié)作可選用代碼寫就是K_THREAD_DEFINE(net_thread, NET_STACK_SIZE, net_task, NULL, NULL, NULL, 0, 0, 0); K_THREAD_DEFINE(bus_logic_thread, LOGIC_STACK_SIZE, logic_task, NULL, NULL, NULL, 1, 0, 0); K_THREAD_DEFINE(lvgl_thread, LVGL_STACK_SIZE, lvgl_task, NULL, NULL, NULL, 2, 0, 0); K_THREAD_DEFINE(wdg_thread, WDG_STACK_SIZE, wdg_task, NULL, NULL, NULL, 3, 0, 0);注意映射時不能只看數(shù)值要看“相對順序”。FreeRTOS的4變成Zephyr的0FreeRTOS的1變成Zephyr的3次序完全反過來但任務(wù)之間的搶占關(guān)系保持原樣。如果你有任務(wù)需要相當(dāng)嚴(yán)格的時序控制比如傳感器啟動序列、電機(jī)抱閘控制可以考慮放到協(xié)作式優(yōu)先級-1或-2。但要保證這個任務(wù)絕對不能死循環(huán)必須周期性地k_sleep()或k_yield()。3.3 最容易踩的“方向反轉(zhuǎn)”坑我見過最典型的低級錯誤是把FreeRTOS任務(wù)優(yōu)先級原封不動寫進(jìn)Zephyr比如網(wǎng)絡(luò)任務(wù)寫4、LVGL任務(wù)寫2。結(jié)果網(wǎng)絡(luò)任務(wù)變成了最低優(yōu)先級只要LVGL在跑網(wǎng)絡(luò)就得不到調(diào)度。這種問題比邏輯bug更難發(fā)現(xiàn)因為它不會直接報錯只是系統(tǒng)“變慢”。排查手段其實很簡單用串口把每個線程的優(yōu)先級和狀態(tài)打出來。FreeRTOS可以用vTaskList()打印Task ListZephyr可以在shell里用kernel threads命令查看線程優(yōu)先級、狀態(tài)、棧使用率。兩邊都有現(xiàn)成工具不要靠猜。另外一個次生坑是“同優(yōu)先級任務(wù)的時間片”。FreeRTOS默認(rèn)開啟時間片同優(yōu)先級任務(wù)之間會自動輪轉(zhuǎn)Zephyr雖然也支持時間片但需要CONFIG_TIMESLICING開啟而且默認(rèn)可能不開啟。如果Zephyr里L(fēng)VGL任務(wù)和按鍵任務(wù)都排優(yōu)先級2但沒有開時間片那么兩個任務(wù)之間如果都不互相yield誰先拿到CPU誰就獨占按鍵任務(wù)可能長時間得不到執(zhí)行。所以遷移后的測試一定要覆蓋“同優(yōu)先級任務(wù)是否都能被調(diào)度到”這一條。4. 優(yōu)先級翻轉(zhuǎn)、中斷優(yōu)先級與互斥等待4.1 優(yōu)先級繼承兩邊都有但別搞混優(yōu)先級翻轉(zhuǎn)是RTOS開發(fā)員必知的問題低優(yōu)先級任務(wù)持有互斥量高優(yōu)先級任務(wù)在等這個互斥量此時中優(yōu)先級任務(wù)一直搶占CPU低優(yōu)先級任務(wù)沒法釋放鎖高優(yōu)先級任務(wù)就被無限拖延。解決手段是優(yōu)先級繼承也就是臨時把低優(yōu)先級任務(wù)的優(yōu)先級提高到等待它的最高優(yōu)先級任務(wù)的級別。FreeRTOS的普通二值信號量不做優(yōu)先級繼承但互斥量Mutex做了。注意這里說的互斥量是指xSemaphoreCreateMutex()創(chuàng)建的那個而不是用二值信號量“手動實現(xiàn)”的互斥。很多新手用二值信號量做臨界區(qū)保護(hù)遇到高優(yōu)先級任務(wù)被餓死就是沒用真正的互斥量。Zephyr的k_mutex同樣實現(xiàn)了優(yōu)先級繼承。如果你需要多線程共享外設(shè)緩沖區(qū)、LVGL顯示緩沖區(qū)這類資源直接用k_mutex而不是k_sem。這里有一個容易混淆的點信號量在某些場景下也能達(dá)到互斥效果但它沒有優(yōu)先級繼承機(jī)制在高并發(fā)系統(tǒng)中就是一顆定時炸彈。我自己做項目時凡是保護(hù)共享資源的鎖一律用k_mutex信號量只用來做事件通知和資源計數(shù)。4.2 中斷優(yōu)先級與線程優(yōu)先級是兩套系統(tǒng)“FreeRTOS的任務(wù)優(yōu)先級與中斷優(yōu)先級區(qū)別”幾乎是面試必問。任務(wù)優(yōu)先級決定的是“就緒任務(wù)誰先被調(diào)度”而中斷優(yōu)先級是硬件中斷控制器Cortex-M的NVIC決定的。任務(wù)優(yōu)先級再高中斷來了它也得讓路只不過中斷服務(wù)程序一般很短只做最少量工作把重的活兒通過隊列或信號量交給任務(wù)去處理。FreeRTOS里中斷服務(wù)程序里調(diào)用API一般要用帶FromISR后綴的版本比如xQueueSendFromISR。而且如果中斷優(yōu)先級高于configMAX_SYSCALL_INTERRUPT_PRIORITY這個中斷里不能調(diào)FreeRTOS API。這個約束很多人會忽略一旦踩到直接跑飛。Zephyr的體系里中斷優(yōu)先級和線程優(yōu)先級也是兩個完全獨立的維度。ISR運行在中斷上下文里沒有任務(wù)優(yōu)先級一說ISR里可以調(diào)用部分Zephyr API比如k_sem_give、k_msgq_put但最終喚醒哪個線程還是看線程優(yōu)先級。你可以用生活常識來記任務(wù)優(yōu)先級是“排隊號”中斷優(yōu)先級是“VIP插隊卡”兩套牌子不是一個體系誰也不能替代誰。4.3 隊列、消息隊列與看門狗中的優(yōu)先級陷阱消息隊列和看門狗也是優(yōu)先級問題的高發(fā)區(qū)。FreeRTOS的隊列xQueueSend、Zephyr的k_msgq_put都屬于典型的內(nèi)核對象當(dāng)多個任務(wù)同時等同一個隊列時喚醒順序一般按優(yōu)先級從高到低排。這本身不算錯但會帶來一個隱藏問題高優(yōu)先級任務(wù)如果瘋狂生產(chǎn)消息低優(yōu)先級消費者可能一直搶不到隊列項。我遇到過的一個實際案例一個傳感器任務(wù)以200Hz頻率往消息隊列里塞數(shù)據(jù)UI任務(wù)從隊列里取數(shù)據(jù)刷新界面由于傳感器任務(wù)優(yōu)先級高隊列幾乎總是滿的UI任務(wù)每次只能拿到最新幾條觸控響應(yīng)變得特別“飄”。最后把UI任務(wù)優(yōu)先級提上去再把傳感器采集任務(wù)和數(shù)據(jù)處理任務(wù)之間做了“只保留最新值”的覆蓋策略問題才解決?？撮T狗這邊喂狗任務(wù)本身也是一種任務(wù)它的優(yōu)先級選擇很講究。如果把喂狗任務(wù)設(shè)得比業(yè)務(wù)任務(wù)還高那就算業(yè)務(wù)任務(wù)卡死喂狗任務(wù)照樣運行看門狗永遠(yuǎn)不復(fù)位整個監(jiān)控形同虛設(shè)。反過來喂狗任務(wù)優(yōu)先級太低系統(tǒng)稍微繁忙一點就喂不上狗出現(xiàn)誤復(fù)位。比較穩(wěn)妥的做法是把喂狗任務(wù)優(yōu)先級放到項目里的“最低業(yè)務(wù)優(yōu)先級檔位”讓它能正常運行但一旦關(guān)鍵高優(yōu)先級任務(wù)卡死它也很快得不到調(diào)度從而觸發(fā)復(fù)位。這個思路在FreeRTOS和Zephyr下都一樣。5. 時間片、空閑線程與調(diào)度器行為差異5.1 同優(yōu)先級輪轉(zhuǎn)時間片的開關(guān)不同F(xiàn)reeRTOS在默認(rèn)配置下多個同優(yōu)先級就緒任務(wù)會按時間片輪轉(zhuǎn)調(diào)度。這個行為由configUSE_TIME_SLICING控制如果把它配置成0同優(yōu)先級任務(wù)之間就不會自動輪轉(zhuǎn)得靠任務(wù)自己調(diào)用taskYIELD()或者被更高優(yōu)先級任務(wù)打斷否則先運行的任務(wù)可能一直占著CPU。Zephyr的時間片控制更分散一些。全局上有個CONFIG_TIMESLICING開關(guān)還有CONFIG_TIMESLICE_SIZE之類配置項。而且Zephyr的時間片只對“搶占式且非負(fù)優(yōu)先級”的線程生效協(xié)作式線程沒有時間片概念必須主動讓出。這一點其實是Zephyr把“協(xié)作式”貫徹到底的結(jié)果既然你選擇了不可被搶占那么時間片也不應(yīng)該再強(qiáng)制切割你。所以遷移時要注意FreeRTOS默認(rèn)同優(yōu)先級任務(wù)可以自動輪轉(zhuǎn)Zephyr如果沒開時間片或者時間片配置不合適同優(yōu)先級任務(wù)在必要時必須自行k_yield()。在一些Zephyr老版本里還有CONFIG_TIMESLICE_SIZE單位從tick改成毫秒之類的變化升級內(nèi)核時要去查版本遷移文檔。5.2 協(xié)作式線程的“讓權(quán)”義務(wù)Zephyr的協(xié)作式線程是很多人從FreeRTOS遷移后最容易翻車的地方。協(xié)作式線程一旦進(jìn)入運行態(tài)調(diào)度器不會因為其他更高優(yōu)先級線程就緒而把它切走。也就是說如果你在一個協(xié)作式線程里寫了類似這樣的代碼while (1) { /* 大量計算 */ }那么這個線程會獨占CPU其他所有線程哪怕優(yōu)先級是搶占式0也全部得不到調(diào)度直到系統(tǒng)看門狗復(fù)位。正確做法是協(xié)作式線程的每個主要循環(huán)節(jié)點都要主動讓出CPU常見手段包括調(diào)用k_yield()主動放棄當(dāng)前時間片調(diào)用k_sleep()進(jìn)入睡眠指定時間調(diào)用k_sem_take()、k_mutex_lock()等阻塞API等待內(nèi)核對象調(diào)用k_msgq_get()等隊列接收API等待數(shù)據(jù)到達(dá)。協(xié)作式線程最適合的場景是某段代碼希望原子地執(zhí)行多個操作又不希望被其他線程打斷。你把它放到負(fù)優(yōu)先級保證調(diào)度器優(yōu)先選擇它它運行期間又不會被打斷相當(dāng)于實現(xiàn)了“用戶態(tài)的臨界區(qū)”。但它絕不能一直“不退位”。5.3 誰在處理空閑線程FreeRTOS的空閑任務(wù)優(yōu)先級是0在普通任務(wù)未全部就緒時占用CPU。你可以用vApplicationIdleHook()往空閑任務(wù)里掛一些低優(yōu)先級的工作比如系統(tǒng)進(jìn)入低功耗模式的檢查、CPU使用率統(tǒng)計。有一點要注意空閑任務(wù)里絕對不能調(diào)用任何阻塞API否則系統(tǒng)調(diào)度器可能失去“兜底”線程。Zephyr也有空閑線程但它的優(yōu)先級被定義得比所有用戶可配置優(yōu)先級都低而且一般不建議用戶往里面塞業(yè)務(wù)邏輯。Zephyr的思路是讓空閑線程自動執(zhí)行CPU低功耗指令配合電源管理子系統(tǒng)來做節(jié)能。用戶想統(tǒng)計CPU占用率可以用Zephyr的內(nèi)置監(jiān)測或定時器。你不需要也不應(yīng)該干預(yù)空閑線程內(nèi)容因為內(nèi)核調(diào)度器選擇空閑線程意味著“此刻確實沒有任何用戶線程可以運行”。6. 多核與SMP優(yōu)先級是不是還夠用6.1 FreeRTOS SMP的優(yōu)先級處理如果你在TC387這類多核MCU上跑FreeRTOS用的多半是帶SMP擴(kuò)展的FreeRTOS版本。多核SMP下全局就緒隊列是所有核心共享的多個核同時修改就緒隊列或優(yōu)先級位圖就必須要引入調(diào)度器鎖。官方SMP版本已經(jīng)做了這部分工作但使用時的注意事項不少。典型問題是兩個核心可能同時運行兩個同優(yōu)先級的就緒任務(wù)這在單核下是不可能的但在SMP下是常態(tài)。所以“全局最高優(yōu)先級任務(wù)一定在跑”這個經(jīng)驗在多核下會變復(fù)雜它可能正在核0上跑而核1跑著一個稍低優(yōu)先級的任務(wù)。要考慮真正的實時性必須配合CPU親和力把關(guān)鍵任務(wù)綁定到指定核心。FreeRTOS SMP的優(yōu)先級方向沒有變依然是數(shù)字越大越優(yōu)先。但涉及動態(tài)優(yōu)先級修改時vTaskPrioritySet()在多核環(huán)境下可能觸發(fā)多個核心的調(diào)度器操作如果中斷屏蔽和鎖沒有處理好會出現(xiàn)就緒鏈表錯亂。遇到這類問題優(yōu)先排查是不是在中斷服務(wù)程序里改了任務(wù)優(yōu)先級。6.2 Zephyr原生SMP的優(yōu)先級與CPU親和Zephyr對SMP的支持是內(nèi)核原生的配置CONFIG_SMPy后可以搭配k_thread_cpu_pin()或k_thread_cpu_mask()這類API控制線程跑在哪個核上。線程優(yōu)先級本身仍是全局的數(shù)字越小越優(yōu)先的規(guī)則不會因為多核而改變。Zephyr的多核調(diào)度器會保證每個空閑核盡量從全局就緒隊列中取最高優(yōu)先級線程運行。這里一個容易忽略的點是Zephyr的協(xié)作式線程在多核下依然不可被搶占但它占用的只是“當(dāng)前核”另一個核還是可以運行其他任務(wù)的。所以在多核Zephyr系統(tǒng)里協(xié)作式線程導(dǎo)致“整個系統(tǒng)卡死”的可能性比單核小但也會占住一個核不放造成CPU資源分配不均。如果你的項目要從FreeRTOS單核遷到Zephyr多核建議先把優(yōu)先級映射做好再考慮CPU親和力。很多人在單核上調(diào)得好好的優(yōu)先級表到多核下亂了是因為沒分清“線程優(yōu)先級”和“核心綁定”是兩種資源控制手段。優(yōu)先級管的是搶CPU先后親和力管的是允許用哪個CPU兩者疊加才是完整的調(diào)度畫像。7. 優(yōu)先級問題排查與常見坑7.1 高優(yōu)先級任務(wù)餓死其他任務(wù)怎么定位高優(yōu)先級任務(wù)餓死低優(yōu)先級任務(wù)最典型的癥狀是低優(yōu)先級任務(wù)“完全不動”但系統(tǒng)沒有死機(jī)看門狗也不復(fù)位。因為高優(yōu)先級任務(wù)一直在正常執(zhí)行、正常喂狗只是低優(yōu)先級任務(wù)沒機(jī)會跑。FreeRTOS下可以用vTaskList()或uxTaskGetSystemState()把每個任務(wù)的狀態(tài)、優(yōu)先級、棧水位打出來重點看某幾個任務(wù)是否長期停留在“Ready”但從未“Running”。Zephyr下最方便的是接上shell敲kernel threads命令觀察每個線程的“prio”和“state”。如果某個低優(yōu)先級線程一直是thread pending或者ready但CPU時間幾乎為零基本可以判定是餓死。定位到之后優(yōu)先檢查兩件事一是它等的事件是否真的在發(fā)生二是它的優(yōu)先級和上游事件產(chǎn)生任務(wù)的優(yōu)先級關(guān)系。很多時候不是優(yōu)先級本身錯了而是消息產(chǎn)生者優(yōu)先級太高直接把消費者堵死了。7.2 協(xié)作式線程占死CPU的現(xiàn)場Zephyr里協(xié)作式線程占死CPU的現(xiàn)場很容易識別系統(tǒng)看起來“死了”但如果你接了調(diào)試器敲暫停會發(fā)現(xiàn)程序停在一個你完全沒預(yù)料到的循環(huán)里更新PC指針一看就是某個協(xié)作式線程的while(1)。FreeRTOS不會有這種問題因為所有任務(wù)都是搶占式的只要tick中斷還在任務(wù)最終會被切走。我的排查經(jīng)驗是遇到Zephyr系統(tǒng)卡死先不要在業(yè)務(wù)流程里找bug先看線程狀態(tài)。如果卡住的線程是負(fù)優(yōu)先級十有八九是協(xié)作式線程沒讓出CPU。快速驗證方法是在那個循環(huán)里臨時加一個k_sleep(K_MSEC(1))如果系統(tǒng)“復(fù)活”說明就是它占死了CPU。后續(xù)再根據(jù)實際邏輯設(shè)計合理的讓出點。7.3 棧溢出、看門狗與優(yōu)先級的關(guān)系棧溢出和優(yōu)先級看著不相關(guān)實際關(guān)聯(lián)很深。高優(yōu)先級任務(wù)頻繁搶占會讓低優(yōu)先級任務(wù)在被搶占時反復(fù)保存現(xiàn)場棧的使用水位比“連續(xù)運行”時要高。如果低優(yōu)先級任務(wù)棧本來就給得緊高壓調(diào)度下更容易溢出。FreeRTOS可以開啟configCHECK_FOR_STACK_OVERFLOW在棧溢出鉤子里抓現(xiàn)場也可以用uxTaskGetStackHighWaterMark()看任務(wù)棧剩余量。Zephyr在Cortex-M上可以開CONFIG_MPU_STACK_GUARD線程一旦越界訪問會觸發(fā)MPU異常比裸奔更好排查。看門狗的問題也經(jīng)常和優(yōu)先級綁定在一起。我見過一個案子系統(tǒng)偶爾復(fù)位看門狗任務(wù)優(yōu)先級設(shè)得比通信任務(wù)低通信任務(wù)在某個異常分支里進(jìn)入了長循環(huán)喂狗任務(wù)一直得不到執(zhí)行看門狗復(fù)位?？雌饋硎恰巴ㄐ湃蝿?wù)卡死導(dǎo)致復(fù)位”本質(zhì)是優(yōu)先級和看門狗設(shè)計配合的問題。后來把喂狗任務(wù)優(yōu)先級提了一檔同時在通信任務(wù)超時分支里主動taskYIELD()復(fù)位問題就消失了。這是典型的“用優(yōu)先級策略喂狗”案例。7.4 面試與學(xué)習(xí)向優(yōu)先級相關(guān)高頻題如果你是在準(zhǔn)備面試下面幾個問題值得提前吃透FreeRTOS任務(wù)優(yōu)先級和中斷優(yōu)先級的區(qū)別是什么FreeRTOS中優(yōu)先級數(shù)值越大越優(yōu)先Zephyr中相反為什么Zephyr要這樣設(shè)計什么是優(yōu)先級反轉(zhuǎn)互斥量的優(yōu)先級繼承機(jī)制怎么解決這個問題Zephyr的協(xié)作式線程為什么不能被搶占中斷能打斷它嗎前兩個問題考的是基礎(chǔ)第三個考的是并發(fā)意識第四個考的是對調(diào)度模型的理解。把這些理解了很多RTOS面試題其實都是同一套底層邏輯。你要是已經(jīng)把前面的章節(jié)讀完這幾個問題應(yīng)該都能用自己的話答出來。最后再分享一個我自己的習(xí)慣所有RTOS項目的優(yōu)先級定義一定要集中收斂到一個頭文件里別散落在各個任務(wù)的實現(xiàn)中?？缙脚_遷移時只要改這個映射頭文件其他代碼幾乎不用動。這也是我從FreeRTOS遷到Zephyr后最受益的一招越大的項目越明顯。每次寫新任務(wù)第一件事不是寫邏輯而是去優(yōu)先級那個表里找位置想清楚它應(yīng)該壓誰、讓誰、和誰平級。優(yōu)先級這東西設(shè)計時多想一分鐘調(diào)試時少熬十小時。 FreeRTOS與Zephyr線程優(yōu)先級對比及遷移避坑指南
做嵌入式這幾年只要一聊RTOS十有八九先問“跑幾個任務(wù)、棧開多大”。其實還有一個更底層的問題——線程優(yōu)先級。Zephyr和FreeRTOS在這件事上的思路完全不同從FreeRTOS遷到Zephyr時優(yōu)先級方向幾乎是反著來的很多人第一個坑就踩在這里。這篇文章就專門拆開“線程優(yōu)先級”這個點把兩邊的模型、源碼表現(xiàn)、實際遷移方法、優(yōu)先級翻轉(zhuǎn)、時間片、SMP場景下的差異一次講清楚。適合正用STM32CubeMX搭FreeRTOS項目的朋友也適合準(zhǔn)備轉(zhuǎn)向Zephyr做多協(xié)議/多核項目的開發(fā)者哪怕你只是面試前想搞明白任務(wù)優(yōu)先級和中斷優(yōu)先級到底差在哪這篇也能直接當(dāng)復(fù)習(xí)資料用。1. 優(yōu)先級模型的根本差異一個看數(shù)字大小一個看正負(fù)1.1 FreeRTOS的“數(shù)字越大越優(yōu)先”FreeRTOS的線程優(yōu)先級規(guī)則非常簡單直接取值范圍從0到configMAX_PRIORITIES - 1數(shù)值越大優(yōu)先級越高。0是最低優(yōu)先級通常被空閑任務(wù)Idle Task占用用戶任務(wù)一般至少從1開始往上排。比如你在CubeMX里配置一個任務(wù)優(yōu)先級為3、另一個為1那么優(yōu)先級3的任務(wù)只要進(jìn)入就緒態(tài)就能馬上搶占優(yōu)先級1的任務(wù)。這個模型在代碼層面很好理解TCB里存一個uxPriority字段調(diào)度器每次挑選任務(wù)時找“uxPriority最大且處于就緒態(tài)”的任務(wù)。因為數(shù)值越大越優(yōu)先所以它天然適合用位圖快速查找最高優(yōu)先級這也是FreeRTOS能夠做到O(1)調(diào)度的核心原因之一。實際項目里我見過不少人把優(yōu)先級理解成“分層越細(xì)越好”一個項目里從1到5排了十來個等級。其實FreeRTOS的優(yōu)先級數(shù)量不是越多越好。優(yōu)先級越多調(diào)度器維護(hù)就緒鏈表和位圖的開銷越大而且高優(yōu)先級任務(wù)過多搶占低優(yōu)先級任務(wù)更容易被“餓死”。官方文檔也建議優(yōu)先級數(shù)量夠用就行不必追求十幾二十個。1.2 Zephyr的“數(shù)字越小越優(yōu)先”與協(xié)作/搶占兩級體系到了Zephyr這邊規(guī)則直接反過來數(shù)字越小優(yōu)先級越高。而且它不是單純“反一下”這么簡單因為Zephyr把線程優(yōu)先級分成兩段——負(fù)數(shù)是協(xié)作式Cooperative優(yōu)先級非負(fù)數(shù)是搶占式Preemptive優(yōu)先級。具體來說協(xié)作式線程的可配置優(yōu)先級范圍是-CONFIG_NUM_COOP_PRIORITIES到-1搶占式線程的可配置優(yōu)先級范圍是0到CONFIG_NUM_PREEMPT_PRIORITIES - 1。比如你配置CONFIG_NUM_COOP_PRIORITIES2、CONFIG_NUM_PREEMPT_PRIORITIES6那么合法優(yōu)先級就是-2、-1、0、1、2、3、4、5。其中-2最高5最低。為什么負(fù)數(shù)反而是最高優(yōu)先級因為Zephyr調(diào)度器統(tǒng)一按“數(shù)值最小者先執(zhí)行”來選線程。負(fù)數(shù)天然小于所有非負(fù)數(shù)所以協(xié)作式線程整體上排在所有搶占式線程前面。但有個重要前提協(xié)作式線程一旦開始運行即使更高優(yōu)先級的搶占式線程就緒了也不能打斷它必須等協(xié)作式線程主動調(diào)用k_yield()、k_sleep()或者等待某個內(nèi)核對象時調(diào)度器才有機(jī)會切換到其他線程。這個設(shè)計其實是把“非搶占調(diào)度”和“搶占調(diào)度”融合進(jìn)了同一個優(yōu)先級體系而不是像FreeRTOS那樣所有任務(wù)默認(rèn)都是搶占式的。你在FreeRTOS里幾乎不會碰到“任務(wù)不讓出CPU就沒法切走”的情況但在Zephyr里如果協(xié)作式線程寫了個死循環(huán)且沒有任何阻塞調(diào)用整個系統(tǒng)都能被它卡死。1.3 一張表看懂映射關(guān)系兩邊的核心差異可以先壓成一張表后面再逐一展開對比項FreeRTOSZephyr優(yōu)先級方向數(shù)字越大越優(yōu)先數(shù)字越小越優(yōu)先默認(rèn)最低優(yōu)先級0空閑任務(wù)占用CONFIG_NUM_PREEMPT_PRIORITIES - 1數(shù)值最大是否有系統(tǒng)級空閑任務(wù)有優(yōu)先級0有優(yōu)先級低于所有用戶可配優(yōu)先級協(xié)作式線程無單獨概念普通任務(wù)可被搶占負(fù)優(yōu)先級線程運行后不可被搶占需主動讓出搶占式線程所有普通任務(wù)非負(fù)優(yōu)先級線程優(yōu)先級范圍0 ~configMAX_PRIORITIES - 1-CONFIG_NUM_COOP_PRIORITIES~CONFIG_NUM_PREEMPT_PRIORITIES - 1動態(tài)修改APIvTaskPrioritySetk_thread_priority_set遷移時最粗暴但有效的方法就是做一個“相對等級映射表”。比如FreeRTOS任務(wù)優(yōu)先級1到4對應(yīng)Zephyr的3、2、1、0保持次序不變即可。后面第三節(jié)我會用一個實際STM32工程舉例。2. 從源碼層面看優(yōu)先級“藏”在哪里2.1 FreeRTOSTCB優(yōu)先級與就緒位圖FreeRTOS的每個任務(wù)核心數(shù)據(jù)結(jié)構(gòu)叫tskTaskControlBlock簡稱TCB里面存著當(dāng)前優(yōu)先級uxPriority和初始優(yōu)先級uxBasePriority。uxBasePriority的主要用途是配合互斥量的優(yōu)先級繼承機(jī)制在解鎖后恢復(fù)原來的優(yōu)先級。這東西在日常應(yīng)用層開發(fā)中看不到但排查優(yōu)先級翻轉(zhuǎn)問題時會非常有用。就緒狀態(tài)的任務(wù)會按優(yōu)先級被掛到一組鏈表數(shù)組里也就是pxReadyTasksLists[configMAX_PRIORITIES]同一優(yōu)先級的多個就緒任務(wù)串在同一個鏈表中。調(diào)度器找一個最高優(yōu)先級任務(wù)時會先通過位圖找到“當(dāng)前最高非空優(yōu)先級”再從這個優(yōu)先級對應(yīng)的鏈表中取出第一個任務(wù)。這就是FreeRTOS所謂O(1)調(diào)度的時間來源。當(dāng)你調(diào)用vTaskPrioritySet()修改一個任務(wù)的優(yōu)先級時內(nèi)核會把該任務(wù)從原來優(yōu)先級的就緒鏈表摘下來改成新優(yōu)先級后再重新插入對應(yīng)的鏈表。如果這個任務(wù)本來就在運行而且新優(yōu)先級比當(dāng)前運行任務(wù)更高內(nèi)核會立刻請求一次上下文切換。這也是FreeRTOS動態(tài)優(yōu)先級能立即生效的原因。源碼層面的另一個關(guān)鍵是portGET_HIGHEST_PRIORITY這類宏。在Cortex-M平臺上它通常借助一個32位位圖變量用CLZ指令或者查表法快速找到最高優(yōu)先級。不同MCU移植層可能會微調(diào)但思路都一樣。如果你只是用CubeMX生成模板一般不關(guān)心這些但真正遇到“調(diào)度延遲異?！边@類問題就得回到這里看是哪個宏拖慢了查找速度。2.2 Zephyrk_thread.prio與統(tǒng)一就緒隊列Zephyr的線程內(nèi)核對象是struct k_thread優(yōu)先級字段就叫prio一個普通的signed int。創(chuàng)建線程時可以指定優(yōu)先級比如用K_THREAD_DEFINE宏定義線程時第三個參數(shù)就是優(yōu)先級也可以用k_thread_create()動態(tài)創(chuàng)建傳入優(yōu)先級參數(shù)。和FreeRTOS“每個優(yōu)先級一個鏈表”不同Zephyr內(nèi)核里維護(hù)的是一個統(tǒng)一的就緒隊列_ready_q所有就緒線程都塞到這個隊列里按優(yōu)先級排序并用位圖輔助快速找到“數(shù)值最小且非空的優(yōu)先級”。從調(diào)度算法上說它同樣是近似O(1)的但數(shù)據(jù)結(jié)構(gòu)上比FreeRTOS更統(tǒng)一。由于優(yōu)先級是int類型源碼里可以直接比較比如內(nèi)核在決定“當(dāng)前線程還能不能繼續(xù)跑”時會拿當(dāng)前線程優(yōu)先級和就緒隊列頭部線程優(yōu)先級做比較。如果就緒隊列頭部的線程優(yōu)先級數(shù)值更小說明出現(xiàn)了更高優(yōu)先級的搶占式線程調(diào)度器就會觸發(fā)切換。Zephyr還允許你通過k_thread_priority_set()在運行期修改線程優(yōu)先級。這個API和FreeRTOS的vTaskPrioritySet()行為不完全一樣如果目標(biāo)線程是搶占式線程且新優(yōu)先級足夠高調(diào)度器可能立即重新調(diào)度如果目標(biāo)線程是協(xié)作式線程那么即使改了優(yōu)先級也要等到它主動讓出CPU后才可能切換過去。說白了協(xié)作式優(yōu)先級更像“下一次調(diào)度時的排序權(quán)重”而不是“馬上就能搶占的開關(guān)”。2.3 動態(tài)優(yōu)先級修改的調(diào)度差異很多從FreeRTOS遷到Zephyr的人會把vTaskPrioritySet(task, 3)直接翻譯成k_thread_priority_set(thread, 3)覺得結(jié)果一樣。實際上方向不一樣在FreeRTOS里你把任務(wù)優(yōu)先級改成3是“升位”在Zephyr里改成3反而會“降位”。這不是API用法問題而是優(yōu)先級模型本身的差異。更隱蔽的是協(xié)作式線程的優(yōu)先級修改。在FreeRTOS中不存在“協(xié)作式任務(wù)不可被搶占”的概念所有任務(wù)只要處于就緒態(tài)且優(yōu)先級更高就能切走當(dāng)前任務(wù)。Zephyr里則不同你讓一個協(xié)作式線程從-2改成-1它依然不會立刻被打斷它可能正在一個循環(huán)里做密集型計算改完優(yōu)先級后系統(tǒng)看起來毫無反應(yīng)直到它主動讓出CPU。所以我的建議是凡是涉及動態(tài)調(diào)整優(yōu)先級的代碼一定要在寫注釋時標(biāo)明“當(dāng)前代碼運行在線程上下文還是中斷上下文”“目標(biāo)線程是協(xié)作式還是搶占式”。這兩個條件決定了下一次調(diào)度到底何時發(fā)生踩過一次協(xié)作式線程的坑以后你會對這句話印象特別深。3. 實際項目中的優(yōu)先級分配與遷移以STM32LVGL為例3.1 FreeRTOS項目里我慣用的優(yōu)先級分檔先拿一個典型的STM32F407項目舉例跑LVGL做界面顯示外接溫濕度傳感器用Wi-Fi模塊上報數(shù)據(jù)再加幾個按鍵輸入。這種項目用CubeMX配置FreeRTOS非常順手任務(wù)不會太多我一般這么排優(yōu)先級任務(wù)功能FreeRTOS優(yōu)先級網(wǎng)絡(luò)通信任務(wù)Wi-Fi數(shù)據(jù)收發(fā)、協(xié)議解析4業(yè)務(wù)邏輯任務(wù)傳感器數(shù)據(jù)融合、狀態(tài)機(jī)3LVGL刷新任務(wù)調(diào)用lv_task_handler或lv_timer_handler2按鍵/事件派發(fā)讀取GPIO、投遞事件到隊列2喂狗與統(tǒng)計任務(wù)喂獨立看門狗、打印任務(wù)棧水位1空閑任務(wù)系統(tǒng)自動創(chuàng)建0這里我特意把網(wǎng)絡(luò)通信排到最高因為Wi-Fi模塊如果處理不及時緩沖區(qū)會被塞滿導(dǎo)致丟包LVGL刷新排到中等保證界面不卡但又不至于搶走網(wǎng)絡(luò)資源喂狗任務(wù)排最低因為正常運行時所有任務(wù)都應(yīng)該活著如果優(yōu)先級高的任務(wù)卡死了喂狗任務(wù)也得不到執(zhí)行看門狗才能正確復(fù)位系統(tǒng)。這個方案在FreeRTOS下穩(wěn)定性很好。但如果直接平移去Zephyr不做方向反轉(zhuǎn)LVGL任務(wù)排2、網(wǎng)絡(luò)任務(wù)排4那Zephyr會把4當(dāng)成最低優(yōu)先級結(jié)果就是網(wǎng)絡(luò)任務(wù)餓死Wi-Fi瘋狂丟包。你查半天都查不出邏輯問題直到打印線程優(yōu)先級才發(fā)現(xiàn)數(shù)值反過來用了。3.2 遷移到Zephyr時的映射表做法在Zephyr上重建這套任務(wù)我會先在prj.conf里定義好優(yōu)先級空間CONFIG_NUM_PREEMPT_PRIORITIES6 CONFIG_NUM_COOP_PRIORITIES2這樣Zephyr的搶占式優(yōu)先級就是0到5協(xié)作式優(yōu)先級是-2和-1。接下來按相對次序做映射原FreeRTOS優(yōu)先級角色映射到Zephyr4網(wǎng)絡(luò)通信0搶占最高3業(yè)務(wù)邏輯1搶占2LVGL刷新2搶占2按鍵/事件2搶占同LVGL同優(yōu)先級1喂狗/統(tǒng)計3搶占最低無關(guān)鍵傳感器采集-1協(xié)作可選用代碼寫就是K_THREAD_DEFINE(net_thread, NET_STACK_SIZE, net_task, NULL, NULL, NULL, 0, 0, 0); K_THREAD_DEFINE(bus_logic_thread, LOGIC_STACK_SIZE, logic_task, NULL, NULL, NULL, 1, 0, 0); K_THREAD_DEFINE(lvgl_thread, LVGL_STACK_SIZE, lvgl_task, NULL, NULL, NULL, 2, 0, 0); K_THREAD_DEFINE(wdg_thread, WDG_STACK_SIZE, wdg_task, NULL, NULL, NULL, 3, 0, 0);注意映射時不能只看數(shù)值要看“相對順序”。FreeRTOS的4變成Zephyr的0FreeRTOS的1變成Zephyr的3次序完全反過來但任務(wù)之間的搶占關(guān)系保持原樣。如果你有任務(wù)需要相當(dāng)嚴(yán)格的時序控制比如傳感器啟動序列、電機(jī)抱閘控制可以考慮放到協(xié)作式優(yōu)先級-1或-2。但要保證這個任務(wù)絕對不能死循環(huán)必須周期性地k_sleep()或k_yield()。3.3 最容易踩的“方向反轉(zhuǎn)”坑我見過最典型的低級錯誤是把FreeRTOS任務(wù)優(yōu)先級原封不動寫進(jìn)Zephyr比如網(wǎng)絡(luò)任務(wù)寫4、LVGL任務(wù)寫2。結(jié)果網(wǎng)絡(luò)任務(wù)變成了最低優(yōu)先級只要LVGL在跑網(wǎng)絡(luò)就得不到調(diào)度。這種問題比邏輯bug更難發(fā)現(xiàn)因為它不會直接報錯只是系統(tǒng)“變慢”。排查手段其實很簡單用串口把每個線程的優(yōu)先級和狀態(tài)打出來。FreeRTOS可以用vTaskList()打印Task ListZephyr可以在shell里用kernel threads命令查看線程優(yōu)先級、狀態(tài)、棧使用率。兩邊都有現(xiàn)成工具不要靠猜。另外一個次生坑是“同優(yōu)先級任務(wù)的時間片”。FreeRTOS默認(rèn)開啟時間片同優(yōu)先級任務(wù)之間會自動輪轉(zhuǎn)Zephyr雖然也支持時間片但需要CONFIG_TIMESLICING開啟而且默認(rèn)可能不開啟。如果Zephyr里L(fēng)VGL任務(wù)和按鍵任務(wù)都排優(yōu)先級2但沒有開時間片那么兩個任務(wù)之間如果都不互相yield誰先拿到CPU誰就獨占按鍵任務(wù)可能長時間得不到執(zhí)行。所以遷移后的測試一定要覆蓋“同優(yōu)先級任務(wù)是否都能被調(diào)度到”這一條。4. 優(yōu)先級翻轉(zhuǎn)、中斷優(yōu)先級與互斥等待4.1 優(yōu)先級繼承兩邊都有但別搞混優(yōu)先級翻轉(zhuǎn)是RTOS開發(fā)員必知的問題低優(yōu)先級任務(wù)持有互斥量高優(yōu)先級任務(wù)在等這個互斥量此時中優(yōu)先級任務(wù)一直搶占CPU低優(yōu)先級任務(wù)沒法釋放鎖高優(yōu)先級任務(wù)就被無限拖延。解決手段是優(yōu)先級繼承也就是臨時把低優(yōu)先級任務(wù)的優(yōu)先級提高到等待它的最高優(yōu)先級任務(wù)的級別。FreeRTOS的普通二值信號量不做優(yōu)先級繼承但互斥量Mutex做了。注意這里說的互斥量是指xSemaphoreCreateMutex()創(chuàng)建的那個而不是用二值信號量“手動實現(xiàn)”的互斥。很多新手用二值信號量做臨界區(qū)保護(hù)遇到高優(yōu)先級任務(wù)被餓死就是沒用真正的互斥量。Zephyr的k_mutex同樣實現(xiàn)了優(yōu)先級繼承。如果你需要多線程共享外設(shè)緩沖區(qū)、LVGL顯示緩沖區(qū)這類資源直接用k_mutex而不是k_sem。這里有一個容易混淆的點信號量在某些場景下也能達(dá)到互斥效果但它沒有優(yōu)先級繼承機(jī)制在高并發(fā)系統(tǒng)中就是一顆定時炸彈。我自己做項目時凡是保護(hù)共享資源的鎖一律用k_mutex信號量只用來做事件通知和資源計數(shù)。4.2 中斷優(yōu)先級與線程優(yōu)先級是兩套系統(tǒng)“FreeRTOS的任務(wù)優(yōu)先級與中斷優(yōu)先級區(qū)別”幾乎是面試必問。任務(wù)優(yōu)先級決定的是“就緒任務(wù)誰先被調(diào)度”而中斷優(yōu)先級是硬件中斷控制器Cortex-M的NVIC決定的。任務(wù)優(yōu)先級再高中斷來了它也得讓路只不過中斷服務(wù)程序一般很短只做最少量工作把重的活兒通過隊列或信號量交給任務(wù)去處理。FreeRTOS里中斷服務(wù)程序里調(diào)用API一般要用帶FromISR后綴的版本比如xQueueSendFromISR。而且如果中斷優(yōu)先級高于configMAX_SYSCALL_INTERRUPT_PRIORITY這個中斷里不能調(diào)FreeRTOS API。這個約束很多人會忽略一旦踩到直接跑飛。Zephyr的體系里中斷優(yōu)先級和線程優(yōu)先級也是兩個完全獨立的維度。ISR運行在中斷上下文里沒有任務(wù)優(yōu)先級一說ISR里可以調(diào)用部分Zephyr API比如k_sem_give、k_msgq_put但最終喚醒哪個線程還是看線程優(yōu)先級。你可以用生活常識來記任務(wù)優(yōu)先級是“排隊號”中斷優(yōu)先級是“VIP插隊卡”兩套牌子不是一個體系誰也不能替代誰。4.3 隊列、消息隊列與看門狗中的優(yōu)先級陷阱消息隊列和看門狗也是優(yōu)先級問題的高發(fā)區(qū)。FreeRTOS的隊列xQueueSend、Zephyr的k_msgq_put都屬于典型的內(nèi)核對象當(dāng)多個任務(wù)同時等同一個隊列時喚醒順序一般按優(yōu)先級從高到低排。這本身不算錯但會帶來一個隱藏問題高優(yōu)先級任務(wù)如果瘋狂生產(chǎn)消息低優(yōu)先級消費者可能一直搶不到隊列項。我遇到過的一個實際案例一個傳感器任務(wù)以200Hz頻率往消息隊列里塞數(shù)據(jù)UI任務(wù)從隊列里取數(shù)據(jù)刷新界面由于傳感器任務(wù)優(yōu)先級高隊列幾乎總是滿的UI任務(wù)每次只能拿到最新幾條觸控響應(yīng)變得特別“飄”。最后把UI任務(wù)優(yōu)先級提上去再把傳感器采集任務(wù)和數(shù)據(jù)處理任務(wù)之間做了“只保留最新值”的覆蓋策略問題才解決?？撮T狗這邊喂狗任務(wù)本身也是一種任務(wù)它的優(yōu)先級選擇很講究。如果把喂狗任務(wù)設(shè)得比業(yè)務(wù)任務(wù)還高那就算業(yè)務(wù)任務(wù)卡死喂狗任務(wù)照樣運行看門狗永遠(yuǎn)不復(fù)位整個監(jiān)控形同虛設(shè)。反過來喂狗任務(wù)優(yōu)先級太低系統(tǒng)稍微繁忙一點就喂不上狗出現(xiàn)誤復(fù)位。比較穩(wěn)妥的做法是把喂狗任務(wù)優(yōu)先級放到項目里的“最低業(yè)務(wù)優(yōu)先級檔位”讓它能正常運行但一旦關(guān)鍵高優(yōu)先級任務(wù)卡死它也很快得不到調(diào)度從而觸發(fā)復(fù)位。這個思路在FreeRTOS和Zephyr下都一樣。5. 時間片、空閑線程與調(diào)度器行為差異5.1 同優(yōu)先級輪轉(zhuǎn)時間片的開關(guān)不同F(xiàn)reeRTOS在默認(rèn)配置下多個同優(yōu)先級就緒任務(wù)會按時間片輪轉(zhuǎn)調(diào)度。這個行為由configUSE_TIME_SLICING控制如果把它配置成0同優(yōu)先級任務(wù)之間就不會自動輪轉(zhuǎn)得靠任務(wù)自己調(diào)用taskYIELD()或者被更高優(yōu)先級任務(wù)打斷否則先運行的任務(wù)可能一直占著CPU。Zephyr的時間片控制更分散一些。全局上有個CONFIG_TIMESLICING開關(guān)還有CONFIG_TIMESLICE_SIZE之類配置項。而且Zephyr的時間片只對“搶占式且非負(fù)優(yōu)先級”的線程生效協(xié)作式線程沒有時間片概念必須主動讓出。這一點其實是Zephyr把“協(xié)作式”貫徹到底的結(jié)果既然你選擇了不可被搶占那么時間片也不應(yīng)該再強(qiáng)制切割你。所以遷移時要注意FreeRTOS默認(rèn)同優(yōu)先級任務(wù)可以自動輪轉(zhuǎn)Zephyr如果沒開時間片或者時間片配置不合適同優(yōu)先級任務(wù)在必要時必須自行k_yield()。在一些Zephyr老版本里還有CONFIG_TIMESLICE_SIZE單位從tick改成毫秒之類的變化升級內(nèi)核時要去查版本遷移文檔。5.2 協(xié)作式線程的“讓權(quán)”義務(wù)Zephyr的協(xié)作式線程是很多人從FreeRTOS遷移后最容易翻車的地方。協(xié)作式線程一旦進(jìn)入運行態(tài)調(diào)度器不會因為其他更高優(yōu)先級線程就緒而把它切走。也就是說如果你在一個協(xié)作式線程里寫了類似這樣的代碼while (1) { /* 大量計算 */ }那么這個線程會獨占CPU其他所有線程哪怕優(yōu)先級是搶占式0也全部得不到調(diào)度直到系統(tǒng)看門狗復(fù)位。正確做法是協(xié)作式線程的每個主要循環(huán)節(jié)點都要主動讓出CPU常見手段包括調(diào)用k_yield()主動放棄當(dāng)前時間片調(diào)用k_sleep()進(jìn)入睡眠指定時間調(diào)用k_sem_take()、k_mutex_lock()等阻塞API等待內(nèi)核對象調(diào)用k_msgq_get()等隊列接收API等待數(shù)據(jù)到達(dá)。協(xié)作式線程最適合的場景是某段代碼希望原子地執(zhí)行多個操作又不希望被其他線程打斷。你把它放到負(fù)優(yōu)先級保證調(diào)度器優(yōu)先選擇它它運行期間又不會被打斷相當(dāng)于實現(xiàn)了“用戶態(tài)的臨界區(qū)”。但它絕不能一直“不退位”。5.3 誰在處理空閑線程FreeRTOS的空閑任務(wù)優(yōu)先級是0在普通任務(wù)未全部就緒時占用CPU。你可以用vApplicationIdleHook()往空閑任務(wù)里掛一些低優(yōu)先級的工作比如系統(tǒng)進(jìn)入低功耗模式的檢查、CPU使用率統(tǒng)計。有一點要注意空閑任務(wù)里絕對不能調(diào)用任何阻塞API否則系統(tǒng)調(diào)度器可能失去“兜底”線程。Zephyr也有空閑線程但它的優(yōu)先級被定義得比所有用戶可配置優(yōu)先級都低而且一般不建議用戶往里面塞業(yè)務(wù)邏輯。Zephyr的思路是讓空閑線程自動執(zhí)行CPU低功耗指令配合電源管理子系統(tǒng)來做節(jié)能。用戶想統(tǒng)計CPU占用率可以用Zephyr的內(nèi)置監(jiān)測或定時器。你不需要也不應(yīng)該干預(yù)空閑線程內(nèi)容因為內(nèi)核調(diào)度器選擇空閑線程意味著“此刻確實沒有任何用戶線程可以運行”。6. 多核與SMP優(yōu)先級是不是還夠用6.1 FreeRTOS SMP的優(yōu)先級處理如果你在TC387這類多核MCU上跑FreeRTOS用的多半是帶SMP擴(kuò)展的FreeRTOS版本。多核SMP下全局就緒隊列是所有核心共享的多個核同時修改就緒隊列或優(yōu)先級位圖就必須要引入調(diào)度器鎖。官方SMP版本已經(jīng)做了這部分工作但使用時的注意事項不少。典型問題是兩個核心可能同時運行兩個同優(yōu)先級的就緒任務(wù)這在單核下是不可能的但在SMP下是常態(tài)。所以“全局最高優(yōu)先級任務(wù)一定在跑”這個經(jīng)驗在多核下會變復(fù)雜它可能正在核0上跑而核1跑著一個稍低優(yōu)先級的任務(wù)。要考慮真正的實時性必須配合CPU親和力把關(guān)鍵任務(wù)綁定到指定核心。FreeRTOS SMP的優(yōu)先級方向沒有變依然是數(shù)字越大越優(yōu)先。但涉及動態(tài)優(yōu)先級修改時vTaskPrioritySet()在多核環(huán)境下可能觸發(fā)多個核心的調(diào)度器操作如果中斷屏蔽和鎖沒有處理好會出現(xiàn)就緒鏈表錯亂。遇到這類問題優(yōu)先排查是不是在中斷服務(wù)程序里改了任務(wù)優(yōu)先級。6.2 Zephyr原生SMP的優(yōu)先級與CPU親和Zephyr對SMP的支持是內(nèi)核原生的配置CONFIG_SMPy后可以搭配k_thread_cpu_pin()或k_thread_cpu_mask()這類API控制線程跑在哪個核上。線程優(yōu)先級本身仍是全局的數(shù)字越小越優(yōu)先的規(guī)則不會因為多核而改變。Zephyr的多核調(diào)度器會保證每個空閑核盡量從全局就緒隊列中取最高優(yōu)先級線程運行。這里一個容易忽略的點是Zephyr的協(xié)作式線程在多核下依然不可被搶占但它占用的只是“當(dāng)前核”另一個核還是可以運行其他任務(wù)的。所以在多核Zephyr系統(tǒng)里協(xié)作式線程導(dǎo)致“整個系統(tǒng)卡死”的可能性比單核小但也會占住一個核不放造成CPU資源分配不均。如果你的項目要從FreeRTOS單核遷到Zephyr多核建議先把優(yōu)先級映射做好再考慮CPU親和力。很多人在單核上調(diào)得好好的優(yōu)先級表到多核下亂了是因為沒分清“線程優(yōu)先級”和“核心綁定”是兩種資源控制手段。優(yōu)先級管的是搶CPU先后親和力管的是允許用哪個CPU兩者疊加才是完整的調(diào)度畫像。7. 優(yōu)先級問題排查與常見坑7.1 高優(yōu)先級任務(wù)餓死其他任務(wù)怎么定位高優(yōu)先級任務(wù)餓死低優(yōu)先級任務(wù)最典型的癥狀是低優(yōu)先級任務(wù)“完全不動”但系統(tǒng)沒有死機(jī)看門狗也不復(fù)位。因為高優(yōu)先級任務(wù)一直在正常執(zhí)行、正常喂狗只是低優(yōu)先級任務(wù)沒機(jī)會跑。FreeRTOS下可以用vTaskList()或uxTaskGetSystemState()把每個任務(wù)的狀態(tài)、優(yōu)先級、棧水位打出來重點看某幾個任務(wù)是否長期停留在“Ready”但從未“Running”。Zephyr下最方便的是接上shell敲kernel threads命令觀察每個線程的“prio”和“state”。如果某個低優(yōu)先級線程一直是thread pending或者ready但CPU時間幾乎為零基本可以判定是餓死。定位到之后優(yōu)先檢查兩件事一是它等的事件是否真的在發(fā)生二是它的優(yōu)先級和上游事件產(chǎn)生任務(wù)的優(yōu)先級關(guān)系。很多時候不是優(yōu)先級本身錯了而是消息產(chǎn)生者優(yōu)先級太高直接把消費者堵死了。7.2 協(xié)作式線程占死CPU的現(xiàn)場Zephyr里協(xié)作式線程占死CPU的現(xiàn)場很容易識別系統(tǒng)看起來“死了”但如果你接了調(diào)試器敲暫停會發(fā)現(xiàn)程序停在一個你完全沒預(yù)料到的循環(huán)里更新PC指針一看就是某個協(xié)作式線程的while(1)。FreeRTOS不會有這種問題因為所有任務(wù)都是搶占式的只要tick中斷還在任務(wù)最終會被切走。我的排查經(jīng)驗是遇到Zephyr系統(tǒng)卡死先不要在業(yè)務(wù)流程里找bug先看線程狀態(tài)。如果卡住的線程是負(fù)優(yōu)先級十有八九是協(xié)作式線程沒讓出CPU。快速驗證方法是在那個循環(huán)里臨時加一個k_sleep(K_MSEC(1))如果系統(tǒng)“復(fù)活”說明就是它占死了CPU。后續(xù)再根據(jù)實際邏輯設(shè)計合理的讓出點。7.3 棧溢出、看門狗與優(yōu)先級的關(guān)系棧溢出和優(yōu)先級看著不相關(guān)實際關(guān)聯(lián)很深。高優(yōu)先級任務(wù)頻繁搶占會讓低優(yōu)先級任務(wù)在被搶占時反復(fù)保存現(xiàn)場棧的使用水位比“連續(xù)運行”時要高。如果低優(yōu)先級任務(wù)棧本來就給得緊高壓調(diào)度下更容易溢出。FreeRTOS可以開啟configCHECK_FOR_STACK_OVERFLOW在棧溢出鉤子里抓現(xiàn)場也可以用uxTaskGetStackHighWaterMark()看任務(wù)棧剩余量。Zephyr在Cortex-M上可以開CONFIG_MPU_STACK_GUARD線程一旦越界訪問會觸發(fā)MPU異常比裸奔更好排查。看門狗的問題也經(jīng)常和優(yōu)先級綁定在一起。我見過一個案子系統(tǒng)偶爾復(fù)位看門狗任務(wù)優(yōu)先級設(shè)得比通信任務(wù)低通信任務(wù)在某個異常分支里進(jìn)入了長循環(huán)喂狗任務(wù)一直得不到執(zhí)行看門狗復(fù)位?？雌饋硎恰巴ㄐ湃蝿?wù)卡死導(dǎo)致復(fù)位”本質(zhì)是優(yōu)先級和看門狗設(shè)計配合的問題。后來把喂狗任務(wù)優(yōu)先級提了一檔同時在通信任務(wù)超時分支里主動taskYIELD()復(fù)位問題就消失了。這是典型的“用優(yōu)先級策略喂狗”案例。7.4 面試與學(xué)習(xí)向優(yōu)先級相關(guān)高頻題如果你是在準(zhǔn)備面試下面幾個問題值得提前吃透FreeRTOS任務(wù)優(yōu)先級和中斷優(yōu)先級的區(qū)別是什么FreeRTOS中優(yōu)先級數(shù)值越大越優(yōu)先Zephyr中相反為什么Zephyr要這樣設(shè)計什么是優(yōu)先級反轉(zhuǎn)互斥量的優(yōu)先級繼承機(jī)制怎么解決這個問題Zephyr的協(xié)作式線程為什么不能被搶占中斷能打斷它嗎前兩個問題考的是基礎(chǔ)第三個考的是并發(fā)意識第四個考的是對調(diào)度模型的理解。把這些理解了很多RTOS面試題其實都是同一套底層邏輯。你要是已經(jīng)把前面的章節(jié)讀完這幾個問題應(yīng)該都能用自己的話答出來。最后再分享一個我自己的習(xí)慣所有RTOS項目的優(yōu)先級定義一定要集中收斂到一個頭文件里別散落在各個任務(wù)的實現(xiàn)中?？缙脚_遷移時只要改這個映射頭文件其他代碼幾乎不用動。這也是我從FreeRTOS遷到Zephyr后最受益的一招越大的項目越明顯。每次寫新任務(wù)第一件事不是寫邏輯而是去優(yōu)先級那個表里找位置想清楚它應(yīng)該壓誰、讓誰、和誰平級。優(yōu)先級這東西設(shè)計時多想一分鐘調(diào)試時少熬十小時。