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