1. 搶占式調(diào)度器到底在搶什么概念拆解與價(jià)值分析1.1 “搶占”的本質(zhì)CPU是唯一的公共資源很多初學(xué)者看到“搶占式調(diào)度器”這幾個(gè)字第一反應(yīng)是“操作系統(tǒng)里才有的東西”離自己很遠(yuǎn)。我當(dāng)年第一次動(dòng)手寫它的時(shí)候也是這個(gè)心理可真正讀懂之后才發(fā)現(xiàn)它就是一套“在多個(gè)任務(wù)之間分配CPU使用權(quán)”的規(guī)則。CPU是唯一的公共資源而“搶占”這兩個(gè)字說的就是這套規(guī)則最硬核的動(dòng)作當(dāng)一個(gè)正在運(yùn)行的任務(wù)還沒主動(dòng)讓出CPU時(shí)調(diào)度器直接把它暫停把處理器交給另一個(gè)任務(wù)。打個(gè)比方搶占式調(diào)度就像馬路上跑著普通車輛突然救護(hù)車?yán)懢瘓?bào)前面的車必須靠邊暫停。這里“靠邊暫停”不是前車司機(jī)想不想讓的問題而是被規(guī)則強(qiáng)制執(zhí)行的。放在系統(tǒng)里也一樣低優(yōu)先級(jí)任務(wù)正在執(zhí)行高優(yōu)先級(jí)任務(wù)一就緒調(diào)度器馬上保存低優(yōu)先級(jí)任務(wù)的執(zhí)行現(xiàn)場(chǎng)切換到高優(yōu)先級(jí)任務(wù)。這個(gè)動(dòng)作就叫“搶占”。所以搶占式調(diào)度器真正“搶”的是什么是CPU是處理器當(dāng)前這條指令執(zhí)行權(quán)。而要做到這一點(diǎn)系統(tǒng)必須能回答三個(gè)問題現(xiàn)在誰在用CPU誰更有資格用切換的時(shí)候怎么做到無縫交接這三個(gè)問題分別對(duì)應(yīng)任務(wù)狀態(tài)管理、調(diào)度策略、上下文切換也就是我這篇博客要講的三個(gè)核心設(shè)計(jì)。搞明白這三件事手寫一個(gè)最小可用的搶占式調(diào)度器就不難了。1.2 協(xié)作式調(diào)度 vs 搶占式調(diào)度一個(gè)對(duì)比實(shí)驗(yàn)在動(dòng)手寫代碼之前我強(qiáng)烈建議先搞清楚搶占式調(diào)度和傳統(tǒng)的協(xié)作式調(diào)度之間差的到底是“代碼量”還是“設(shè)計(jì)思路”。二者最大的區(qū)別只有一個(gè)切換的主動(dòng)權(quán)在誰手里。協(xié)作式調(diào)度的經(jīng)典形態(tài)是這樣的// 最樸素的超級(jí)循環(huán) while (1) { task1(); // task1運(yùn)行完自然回到循環(huán) task2(); // task2運(yùn)行完自然回到循環(huán) }這種寫法下task1如果不主動(dòng)返回task2永遠(yuǎn)沒機(jī)會(huì)跑。就算用yield()讓出CPU的協(xié)作式RTOS本質(zhì)上也是靠任務(wù)自覺。一旦某個(gè)任務(wù)里出現(xiàn)一段死循環(huán)整個(gè)系統(tǒng)直接卡死。搶占式調(diào)度則把主動(dòng)權(quán)收回到了內(nèi)核手里。系統(tǒng)利用一個(gè)周期性中斷比如1ms觸發(fā)一次的系統(tǒng)節(jié)拍作為“心跳”每次心跳都會(huì)檢查當(dāng)前任務(wù)是否還被允許繼續(xù)占用CPU。如果此時(shí)有更高優(yōu)先級(jí)任務(wù)就緒或者當(dāng)前任務(wù)的時(shí)間片已經(jīng)用完內(nèi)核立刻發(fā)起上下文切換強(qiáng)制換人。我用一個(gè)表格把兩者的差異列清楚方便你對(duì)照著選型對(duì)比維度超級(jí)循環(huán)協(xié)作式調(diào)度搶占式調(diào)度切換時(shí)機(jī)任務(wù)結(jié)束返回任務(wù)主動(dòng)讓出任意時(shí)刻可被內(nèi)核強(qiáng)制最大風(fēng)險(xiǎn)單任務(wù)卡死全系統(tǒng)任務(wù)不讓出也會(huì)卡死需要處理共享數(shù)據(jù)競(jìng)爭實(shí)時(shí)性無保證弱實(shí)時(shí)強(qiáng)實(shí)時(shí)可預(yù)測(cè)實(shí)現(xiàn)復(fù)雜度極低較低較高典型應(yīng)用極簡控制/教學(xué)早期系統(tǒng)RTOS、嵌入式操作系統(tǒng)搶占式調(diào)度并不神秘它做的事就是在“協(xié)作式中斷”上疊加了一個(gè)“強(qiáng)制切換”能力。每一個(gè)搶占式調(diào)度器背后其實(shí)只有四個(gè)要素任務(wù)控制塊、就緒隊(duì)列、上下文切換、系統(tǒng)節(jié)拍。把這四件事想通之后下面的代碼寫起來就是水到渠成的事。2. 動(dòng)手前的核心設(shè)計(jì)TCB、就緒隊(duì)列與上下文切換2.1 TCB該存哪些信息調(diào)度的“戶口本”調(diào)度器要管理多個(gè)任務(wù)第一件事就是給每個(gè)任務(wù)建立一個(gè)“戶口本”系統(tǒng)里叫任務(wù)控制塊TCB。所有和任務(wù)相關(guān)的信息都記錄在這個(gè)結(jié)構(gòu)體里缺了哪項(xiàng)切換的時(shí)候都會(huì)出事。我寫的第一個(gè)最小版本TCB只保留了六個(gè)字段typedef struct tcb { uint32_t *sp; // 任務(wù)棧指針上下文切換時(shí)保存現(xiàn)場(chǎng) uint8_t priority; // 任務(wù)優(yōu)先級(jí)數(shù)值越小優(yōu)先級(jí)越高 uint8_t state; // 任務(wù)狀態(tài)就緒、運(yùn)行、阻塞 uint32_t slice; // 剩余時(shí)間片單位是系統(tǒng)節(jié)拍數(shù) void (*entry)(void *arg); // 任務(wù)入口函數(shù) struct tcb *next; // 用于串成鏈表指向下一個(gè)任務(wù) } tcb_t;這里最容易被忽略的是sp字段。每個(gè)任務(wù)都有自己獨(dú)立的棧運(yùn)行時(shí)棧指針指向哪完全靠這個(gè)字段記錄。搶占發(fā)生的那一刻調(diào)度器會(huì)把當(dāng)前任務(wù)的棧指針保存到TCB里下一次恢復(fù)該任務(wù)時(shí)再從這個(gè)字段讀出棧指針把寄存器現(xiàn)場(chǎng)彈回來。你可以把它理解成書簽每次被強(qiáng)制暫停CPU就把讀書進(jìn)度寫到這個(gè)書簽上下次接著讀。需要提醒的是不同任務(wù)之間哪怕入口函數(shù)一模一樣也必須有各自獨(dú)立的?？臻g。很多初學(xué)者圖省事讓兩個(gè)任務(wù)共用一塊棧跑起來一開搶占就“炸”原因正是高優(yōu)先級(jí)任務(wù)的函數(shù)調(diào)用會(huì)覆蓋低優(yōu)先級(jí)任務(wù)還在使用的棧數(shù)據(jù)。2.2 就緒隊(duì)列如何設(shè)計(jì)從鏈表到位圖的一次實(shí)踐有了TCB下一步是回答“誰有資格被選中”。最常見的設(shè)計(jì)是維護(hù)一張就緒表凡是處于就緒狀態(tài)的任務(wù)都掛到這上面。調(diào)度時(shí)從就緒表里挑出一個(gè)最合適的任務(wù)。我在最初版本用的是普通單向鏈表簡單是簡單但有一個(gè)痛點(diǎn)是查找最高優(yōu)先級(jí)任務(wù)時(shí)要遍歷整個(gè)鏈表任務(wù)數(shù)量一多延遲就不穩(wěn)定。后來參考了一些實(shí)時(shí)內(nèi)核的做法改用就緒位圖bitmap一個(gè)32位無符號(hào)整數(shù)就能記錄32個(gè)優(yōu)先級(jí)上的就緒情況。某一位置1表示該優(yōu)先級(jí)上至少有一個(gè)任務(wù)就緒。// 假設(shè)優(yōu)先級(jí)0最高優(yōu)先級(jí)31最低 static uint32_t ready_bitmap; // 某位為1說明該優(yōu)先級(jí)有就緒任務(wù) // 優(yōu)先級(jí)p的任務(wù)就緒 void ready_set(uint8_t p) { ready_bitmap | (1u p); } // 優(yōu)先級(jí)p的任務(wù)離開就緒態(tài) void ready_clear(uint8_t p) { ready_bitmap ~(1u p); }在Cortex-M3及以上平臺(tái)獲取最高優(yōu)先級(jí)就緒任務(wù)可以用一條匯編指令CLZ計(jì)算前導(dǎo)零個(gè)數(shù)配合位圖就能在常數(shù)時(shí)間內(nèi)完成tcb_t *schedule(void) { int prio; if (ready_bitmap 0) { return NULL; // 沒有就緒任務(wù) } prio 31 - __CLZ(ready_bitmap); // 找到最高優(yōu)先級(jí)的序號(hào) return priority_task_list[prio]; // 取出該優(yōu)先級(jí)上的任務(wù) }位圖方案的優(yōu)點(diǎn)是查找時(shí)間確定、邏輯容易驗(yàn)證缺點(diǎn)是有多少個(gè)優(yōu)先級(jí)就要付出多少1bit的代價(jià)。好在32個(gè)優(yōu)先級(jí)對(duì)絕大多數(shù)實(shí)際系統(tǒng)已經(jīng)綽綽有余。這其實(shí)也引出了另一個(gè)關(guān)鍵問題調(diào)度策略真的只有“選最高優(yōu)先級(jí)”這一條嗎不是。更完整的策略還包含同優(yōu)先級(jí)任務(wù)之間的時(shí)間片輪轉(zhuǎn)以及“如果說最高優(yōu)先級(jí)也在運(yùn)行新就緒的任務(wù)比它還高那馬上搶占”的判斷。這些我放到第四章細(xì)講。2.3 上下文切換為什么必須在PendSV里干上下文切換是搶占式調(diào)度器里技術(shù)含量最高的部分。它要做的就是把當(dāng)前任務(wù)CPU寄存器里的現(xiàn)場(chǎng)完整保存然后把新任務(wù)之前保存的現(xiàn)場(chǎng)恢復(fù)出來。具體來說要存檔的東西包括R0-R12通用寄存器、棧指針SP、鏈接寄存器LR、程序計(jì)數(shù)器PC、程序狀態(tài)寄存器xPSR。這些現(xiàn)場(chǎng)一旦缺一個(gè)恢復(fù)后任務(wù)就會(huì)“失憶”輕則數(shù)據(jù)錯(cuò)亂重則直接跑飛。但有一個(gè)問題這些切換動(dòng)作到底在什么時(shí)機(jī)執(zhí)行答案是必須在一個(gè)中斷處理函數(shù)里完成而不是在普通的任務(wù)代碼里。任務(wù)代碼運(yùn)行時(shí)的上下文是它自己的“私人物品”調(diào)度器一旦在任務(wù)上下文里修改SP或者調(diào)用切換函數(shù)會(huì)把當(dāng)前的運(yùn)行棧搞亂。更穩(wěn)妥的做法是借助一個(gè)專門的中斷在中斷處理程序里借“中斷機(jī)制的東風(fēng)”來做切換。我用的平臺(tái)是Cortex-M系列它提供兩個(gè)給OS用得很順手的工具SysTick定時(shí)器和PendSV異常。SysTick按時(shí)產(chǎn)生系統(tǒng)節(jié)拍相當(dāng)于心跳PendSV則被設(shè)計(jì)成專門留給操作系統(tǒng)做上下文切換的異常它的優(yōu)先級(jí)可以設(shè)為最低并且有一個(gè)特點(diǎn)如果切換請(qǐng)求進(jìn)來時(shí)還有其他中斷在處理PendSV會(huì)被“押后”到所有中斷都處理完之后再執(zhí)行。這一設(shè)計(jì)剛好避免了一個(gè)大坑——假如上下文切換打斷了一個(gè)中斷服務(wù)程序OS很難判斷此刻該不該切換而PendSV的延遲特性讓切換時(shí)機(jī)變得干凈安全。上下文切換的完整路徑是SysTick中斷觸發(fā) → 發(fā)現(xiàn)該切換了 → 置位PendSV的掛起位 → SysTick退出 → PendSV進(jìn)入 → 保存當(dāng)前現(xiàn)場(chǎng) → 選新任務(wù) → 恢復(fù)新現(xiàn)場(chǎng) → 返回。流程圖式的理解不難真正難的是棧上數(shù)據(jù)的排列順序。這個(gè)我在第三章的代碼里展開講解。3. 從零手寫的最小實(shí)現(xiàn)步驟與代碼逐段解析3.1 平臺(tái)和工具鏈怎么選手寫搶占式調(diào)度器最理想的學(xué)習(xí)平臺(tái)是帶片內(nèi)SysTick的32位MCU。我建議用Cortex-M3/M4內(nèi)核的開發(fā)板因?yàn)樗谟布献詣?dòng)幫我們做了一部分現(xiàn)場(chǎng)保存一旦進(jìn)入中斷硬件會(huì)先把xPSR、PC、LR、R12、R0-R3這8個(gè)寄存器壓入當(dāng)前棧中斷返回時(shí)再自動(dòng)彈出。這極大降低了手寫調(diào)度器的難度。RISC-V平臺(tái)也能做但需要自己處理的東西更多不適合第一次練手。工具鏈方面我用的是開源GCC交叉編譯器加一個(gè)調(diào)試器。環(huán)境配置就是三件套交叉編譯器、一個(gè)能燒錄調(diào)試的工具、一塊開發(fā)板。如果你手頭甚至沒有板子也可以用一款開源虛擬機(jī)模擬器先把調(diào)度邏輯調(diào)通跑通了再燒到真機(jī)上。我個(gè)人強(qiáng)烈建議走“先在模擬器上驗(yàn)證、再上真機(jī)”這條路后面能替你省下大量排查硬件問題的時(shí)間。3.2 五步搭出最小搶占式調(diào)度器下面我按自己實(shí)際操作時(shí)的順序來講每一步都給了代碼片段。需要注意這里展示的是一個(gè)“最小可用原型”專職演示搶占式調(diào)度器的核心機(jī)制不追求功能齊全。第一步定義任務(wù)棧與TCB數(shù)組#define TASK_STACK_SIZE 512 #define MAX_TASKS 2 static uint32_t task_stack0[TASK_STACK_SIZE]; static uint32_t task_stack1[TASK_STACK_SIZE]; static tcb_t tcb0; static tcb_t tcb1;任務(wù)棧為什么用uint32_t數(shù)組而不用uint8_t因?yàn)镃ortex-M的棧操作是4字節(jié)對(duì)齊的直接聲明32位數(shù)組?；刂诽烊话?字節(jié)對(duì)齊省去一堆對(duì)齊處理的麻煩。第二步初始化任務(wù)棧偽造一個(gè)“剛被搶占”的現(xiàn)場(chǎng)這是整個(gè)實(shí)現(xiàn)里最微妙的一步。任務(wù)是第一次運(yùn)行并沒有真正的“現(xiàn)場(chǎng)”可保存所以我們要在棧上預(yù)先偽造一份“如果任務(wù)剛剛被打斷應(yīng)該長什么樣”的寄存器布局。等第一次切換發(fā)生時(shí)恢復(fù)現(xiàn)場(chǎng)就跟往常一樣仿佛這個(gè)任務(wù)早就存在。void task_stack_init(tcb_t *tcb, void (*entry)(void *), uint32_t *stack_top) { uint32_t *s stack_top; // 模擬Cortex-M進(jìn)入中斷時(shí)硬件自動(dòng)壓棧的8個(gè)寄存器 *--s 0x01000000; // xPSRbit24必須置1表示Thumb模式 *--s (uint32_t)entry; // PC任務(wù)入口地址 *--s 0xFFFFFFFD; // LR任務(wù)一旦返回就進(jìn)異常 *--s 0x00000012; // R12 *--s 0x00000003; // R3 *--s 0x00000002; // R2 *--s 0x00000001; // R1 *--s 0x00000000; // R0 // 模擬PendSV處理程序中保存R4-R11這8個(gè)通用寄存器 for (int i 0; i 8; i) { *--s 0x00000000; } tcb-sp s; // 把偽造好的棧指針存進(jìn)TCB }初學(xué)時(shí)最容易在這里犯迷糊為什么壓棧順序是xPSR、PC、LR、R12、R3、R2、R1、R0然后再R4-R11答案很簡單Cortex-M中斷機(jī)制約定中斷返回時(shí)硬件按固定順序從棧中彈出8個(gè)寄存器從上到下依次是R0、R1、R2、R3、R12、LR、PC、xPSR。由于棧是向下增長的我們要預(yù)置這份布局就必須反向?qū)懭胍簿褪菑膞PSR開始寫最后寫R0。多出的R4-R11對(duì)應(yīng)PendSV處理程序里的“手動(dòng)保存區(qū)”。第三步實(shí)現(xiàn)SysTick心跳決定“要不要切”系統(tǒng)節(jié)拍是搶占式調(diào)度器的驅(qū)動(dòng)源。SysTick每1ms觸發(fā)一次中斷服務(wù)程序里把當(dāng)前任務(wù)的剩余時(shí)間片減一減到0就換任務(wù)void SysTick_Handler(void) { tcb_t *cur current_task; if (cur-slice 0) { cur-slice--; } if (cur-slice 0) { cur-slice DEFAULT_SLICE; // 重新填滿時(shí)間片 SCB-ICSR | (1UL 28); // 置位PendSV掛起位 } }這里只做了“觸發(fā)PendSV”的動(dòng)作真正的切換在PendSV里。為什么不在SysTick里直接切因?yàn)镾ysTick的中斷上下文可能嵌套在別的中斷中直接切換會(huì)讓調(diào)度器與正在處理的中斷糾纏不清。置位掛起位、等PendSV順便執(zhí)行才是干凈的做法。第四步實(shí)現(xiàn)PendSV上下文切換PendSV的處理函數(shù)是調(diào)度器的心臟我直接用匯編寫因?yàn)镃編譯器一旦介入寄存器保存的順序和時(shí)機(jī)就不再可控。下面是一個(gè)針對(duì)Cortex-M3/M4平臺(tái)的精簡實(shí)現(xiàn)__asm void PendSV_Handler(void) { // 1. 保存當(dāng)前任務(wù)現(xiàn)場(chǎng) MRS R0, PSP ; 讀當(dāng)前進(jìn)程棧指針 STMDB R0!, {R4-R11} ; 把R4-R11壓入當(dāng)前任務(wù)棧 LDR R1, current_task ; R1指向current_task指針變量 LDR R2, [R1] ; R2 current_task STR R0, [R2] ; 將新的SP寫回當(dāng)前任務(wù)的TCB-sp // 2. 調(diào)用調(diào)度函數(shù)選出下一個(gè)要運(yùn)行的任務(wù) BL schedule // 3. 更新current_task為新任務(wù)讀取其SP LDR R1, current_task STR R0, [R1] ; current_task 新任務(wù) LDR R0, [R0] ; R0 新任務(wù)的TCB-sp // 4. 恢復(fù)新任務(wù)的現(xiàn)場(chǎng) LDMIA R0!, {R4-R11} ; 彈出R4-R11 MSR PSP, R0 ; 更新進(jìn)程棧指針 BX LR ; 返回時(shí)硬件自動(dòng)彈出R0-R3、R12、LR、PC、xPSR }這個(gè)函數(shù)每次執(zhí)行就是一個(gè)完整的“交接儀式”。有一點(diǎn)一定要記住PendSV執(zhí)行期間Cortex-M硬件已經(jīng)把調(diào)用者現(xiàn)場(chǎng)固定保存在MSP主棧指針里我們操作的是PSP進(jìn)程棧指針也就是任務(wù)自己的棧。保存時(shí)用STMDB是“先遞減再存儲(chǔ)”恢復(fù)時(shí)用LDMIA“先加載再遞增”一壓一彈正好和棧的生長方向?qū)?yīng)。第五步創(chuàng)建任務(wù)并啟動(dòng)調(diào)度器任務(wù)棧初始化好了TCB也賦值了最后把系統(tǒng)跑起來void task_create(tcb_t *tcb, void (*entry)(void *), uint32_t priority, uint32_t slice, uint32_t *stack_top) { task_stack_init(tcb, entry, stack_top); tcb-priority priority; tcb-slice slice; tcb-state READY; ready_set(priority); } void scheduler_start(void) { // 關(guān)閉中斷選第一個(gè)任務(wù)打開中斷 __disable_irq(); current_task schedule(); current_task-state RUNNING; PSP current_task-sp; __enable_irq(); }scheduler_start的竅門是一開始沒有循環(huán)、沒有while(1)而是直接在特權(quán)模式下把第一個(gè)任務(wù)的棧指針寫入PSP然后開中斷。第一次SysTick到來時(shí)它會(huì)乖乖走上“保存→調(diào)度→恢復(fù)”的軌道。從此兩個(gè)任務(wù)在心跳的驅(qū)動(dòng)下交替運(yùn)行搶占式調(diào)度器就活起來了。3.3 三個(gè)關(guān)鍵參數(shù)怎么定節(jié)拍、棧大小、優(yōu)先級(jí)數(shù)量寫完原型之后接下來就是調(diào)參數(shù)。我最早踩的坑全在參數(shù)上所以單獨(dú)拿出來說說。系統(tǒng)節(jié)拍一般取1ms到10ms。太快比如0.1ms會(huì)讓調(diào)度器自身開銷占比過高系統(tǒng)大量時(shí)間花在切換上太慢比如100ms則實(shí)時(shí)性無法保證。我習(xí)慣先按應(yīng)用的需求定如果只是LED閃爍、按鍵掃描10ms足矣如果后面要跑通信協(xié)議棧、電機(jī)控制建議從1ms起步再測(cè)量CPU占用率。任務(wù)棧大小沒有一個(gè)公式能給出精確值最靠譜的是“估大不估小”。一般計(jì)算公式是最大函數(shù)調(diào)用深度 × 平均局部變量占用 最大中斷嵌套深度 × 中斷幀大小最后再加20%到30%的安全余量。Cortex-M中斷幀是8個(gè)寄存器約32字節(jié)如果考慮當(dāng)前正在處理的局部變量一次嵌套中斷通常需要100字節(jié)左右。512字節(jié)的棧只夠跑很淺的調(diào)用實(shí)際產(chǎn)品里任務(wù)棧經(jīng)常是1KB到4KB。優(yōu)先級(jí)數(shù)量位圖方案下8個(gè)或16個(gè)優(yōu)先級(jí)已經(jīng)能應(yīng)對(duì)大多數(shù)場(chǎng)景。優(yōu)先級(jí)越多調(diào)度邏輯越靈活但系統(tǒng)設(shè)計(jì)時(shí)也要面對(duì)更復(fù)雜的優(yōu)先級(jí)反轉(zhuǎn)問題。我的建議是開始只設(shè)兩個(gè)優(yōu)先級(jí)先把“搶占”的動(dòng)作驗(yàn)證明白再逐步擴(kuò)展。4. 容易翻車的幾個(gè)關(guān)鍵細(xì)節(jié)以及我的取舍4.1 臨界區(qū)保護(hù)搶占之前先看紅綠燈調(diào)度器能在“任意指令邊界”強(qiáng)制切換任務(wù)這帶來一個(gè)隱患如果任務(wù)A正在修改一個(gè)共享變量只寫了一半突然被打斷任務(wù)B也來讀寫這個(gè)變量數(shù)據(jù)就亂了。搶占式調(diào)度器對(duì)共享資源的保護(hù)方式和裸機(jī)程序完全不同。裸機(jī)程序只要關(guān)中斷就行但搶占式系統(tǒng)里還需要配合互斥鎖或者臨界區(qū)。第一種臨界區(qū)實(shí)現(xiàn)最簡單全關(guān)中斷。uint32_t enter_critical(void) { uint32_t primask __get_PRIMASK(); __disable_irq(); // 關(guān)中斷 return primask; } void exit_critical(uint32_t primask) { __set_PRIMASK(primask); // 恢復(fù)之前的中斷狀態(tài) }這種做法的缺點(diǎn)是關(guān)中斷會(huì)讓所有中斷暫時(shí)失效如果臨界區(qū)代碼太長系統(tǒng)實(shí)時(shí)性會(huì)明顯變差甚至丟中斷。我在最初版本里就這么干后來發(fā)現(xiàn)通信中斷被關(guān)久了會(huì)丟數(shù)據(jù)才意識(shí)到問題。第二種方案是Cortex-M3/M4提供的BASEPRI機(jī)制設(shè)置一個(gè)閾值只屏蔽優(yōu)先級(jí)低于某個(gè)值的中斷高優(yōu)先級(jí)中斷仍然可以響應(yīng)。這樣臨界區(qū)可以保護(hù)共享數(shù)據(jù)又不犧牲像通信這類高優(yōu)先級(jí)中斷的實(shí)時(shí)響應(yīng)。具體代碼就是往BASEPRI寄存器寫一個(gè)數(shù)字中斷保護(hù)結(jié)束后寫0。這個(gè)方案把“關(guān)中斷時(shí)間”縮短到很短代價(jià)是M0系列不支持代碼要做條件編譯。4.2 中斷嵌套、延遲搶占與PendSV的優(yōu)先級(jí)PendSV的優(yōu)先級(jí)是新手很容易忽略的大坑。我剛開始實(shí)現(xiàn)時(shí)把PendSV優(yōu)先級(jí)和其他中斷一樣設(shè)成0最高結(jié)果調(diào)試時(shí)頻繁出現(xiàn)奇怪的現(xiàn)象SysTick一觸發(fā)PendSV馬上跑把本應(yīng)在SysTick之后處理的某些中斷全部攪亂。正確做法是PendSV的優(yōu)先級(jí)必須設(shè)置為所有中斷里最低的那個(gè)。原因在于它的設(shè)計(jì)定位是“等一切安靜下來再做切換”。如果PendSV優(yōu)先級(jí)太高它可能在一個(gè)中斷服務(wù)程序還沒結(jié)束時(shí)就搶進(jìn)去那個(gè)中斷執(zhí)行到一半現(xiàn)場(chǎng)可能還沒保存或者棧指針異常強(qiáng)行切換后果不可預(yù)料。把PendSV設(shè)為最低它就會(huì)等所有更高中斷都處理完再執(zhí)行這就是“延遲搶占”的核心思想。這里還牽扯到中斷嵌套。Cortex-M中斷優(yōu)先級(jí)比正常任務(wù)高但中斷之間也能嵌套只要更高優(yōu)先級(jí)中斷來了同樣能打斷正在執(zhí)行的中斷服務(wù)程序。這對(duì)調(diào)度器意味著即使任務(wù)切換在PendSV里做中斷服務(wù)程序本身也得小心不要在嵌套過程中訪問調(diào)度器共享數(shù)據(jù)否則還是要加臨界區(qū)保護(hù)。4.3 時(shí)間片輪轉(zhuǎn)和優(yōu)先級(jí)如何優(yōu)雅地共存很多第一次手寫調(diào)度器的人會(huì)糾結(jié)一個(gè)問題既然高優(yōu)先級(jí)任務(wù)總是搶占那低優(yōu)先級(jí)任務(wù)是不是永遠(yuǎn)沒有機(jī)會(huì)跑答案是取決于高優(yōu)先級(jí)任務(wù)的運(yùn)行方式。如果高優(yōu)先級(jí)任務(wù)是一個(gè)帶阻塞操作的循環(huán)比如等待信號(hào)量、延時(shí)它會(huì)在阻塞時(shí)主動(dòng)讓出CPU把運(yùn)行機(jī)會(huì)還給低優(yōu)先級(jí)任務(wù)。這恰恰說明一個(gè)完整的搶占式調(diào)度器不能只有“搶占”這一個(gè)動(dòng)作還得有任務(wù)阻塞與喚醒機(jī)制。對(duì)于同優(yōu)先級(jí)的多個(gè)任務(wù)我采用時(shí)間片輪轉(zhuǎn)。每個(gè)任務(wù)分配一個(gè)時(shí)間片時(shí)間片用完系統(tǒng)強(qiáng)行把CPU交給下一個(gè)同優(yōu)先級(jí)任務(wù)。如果此時(shí)有更高優(yōu)先級(jí)任務(wù)就緒調(diào)度器優(yōu)先切到高優(yōu)先級(jí)任務(wù)高優(yōu)先級(jí)任務(wù)阻塞后再回到當(dāng)前優(yōu)先級(jí)隊(duì)列里繼續(xù)輪轉(zhuǎn)。實(shí)現(xiàn)上我維護(hù)了“每個(gè)優(yōu)先級(jí)下掛一串任務(wù)就緒列表”的數(shù)據(jù)結(jié)構(gòu)調(diào)度時(shí)先看位圖找最高優(yōu)先級(jí)到了優(yōu)先級(jí)內(nèi)部再按輪轉(zhuǎn)順序選任務(wù)。這樣的分層設(shè)計(jì)讓調(diào)度器的核心邏輯保持簡單擴(kuò)展也方便。后面你想加信號(hào)量、郵箱只需要改變?nèi)蝿?wù)的狀態(tài)和就緒位圖調(diào)度器的核心不必大改。5. 實(shí)操中的坑問題現(xiàn)象、排查思路與修復(fù)記錄5.1 系統(tǒng)一跑就HardFault先查棧溢出和棧對(duì)齊我第一次在真機(jī)上跑這個(gè)調(diào)度器開局就是HardFault。那一刻的心情如果你也調(diào)過嵌入式代碼一定能懂。冷靜下來按三個(gè)層次排查才定位到問題。第一步確認(rèn)棧是否溢出。我預(yù)先把每個(gè)任務(wù)棧的起始區(qū)域填滿一個(gè)特定字節(jié)比如0xCC跑一段時(shí)間后查看棧高水位看這個(gè)填充字節(jié)有沒有被沖掉。結(jié)果發(fā)現(xiàn)低優(yōu)先級(jí)任務(wù)棧的0xCC全沒了說明棧確實(shí)不夠用。把512字節(jié)加大到1024字節(jié)系統(tǒng)穩(wěn)定了不少。第二步查棧對(duì)齊。Cortex-M要求進(jìn)行某些操作時(shí)16字節(jié)對(duì)齊才能保證硬件正常工作。我的任務(wù)棧聲明是uint32_t數(shù)組天然4字節(jié)對(duì)齊但在偽造初始現(xiàn)場(chǎng)時(shí)壓棧次數(shù)是奇數(shù)還是偶數(shù)的細(xì)節(jié)會(huì)影響棧的最終對(duì)齊需要在壓棧后檢查sp 0x0F的值。當(dāng)時(shí)我壓了16個(gè)寄存器恰好保持對(duì)齊這個(gè)坑沒有踩到。第三步查LR和異常返回。任務(wù)入口函數(shù)一旦執(zhí)行到末尾LR里的0xFFFFFFFD會(huì)讓CPU進(jìn)入異常模式而異常模式里又沒有任何處理函數(shù)結(jié)果也是HardFault。這個(gè)在初始化時(shí)本來就要避免我建議任務(wù)入口函數(shù)永遠(yuǎn)是一個(gè)while(1)循環(huán)別讓自己“跑完”。5.2 高優(yōu)先級(jí)任務(wù)被卡死優(yōu)先級(jí)反轉(zhuǎn)的現(xiàn)場(chǎng)復(fù)現(xiàn)有一次調(diào)試我遇到一個(gè)比HardFault更難纏的現(xiàn)象高優(yōu)先級(jí)任務(wù)A明明就緒了卻始終得不到執(zhí)行反而是低優(yōu)先級(jí)任務(wù)C一直在跑。打印各處標(biāo)志位后我發(fā)現(xiàn)真正的原因是一個(gè)共享資源——互斥量——被中等優(yōu)先級(jí)任務(wù)B和低優(yōu)先級(jí)任務(wù)C之間的一串調(diào)用搞得“顛倒”了。場(chǎng)景是任務(wù)C先拿到了互斥量執(zhí)行到一半被任務(wù)A搶占任務(wù)A想申請(qǐng)同一個(gè)互斥量發(fā)現(xiàn)被C持有于是A只能等待可這時(shí)候任務(wù)B優(yōu)先級(jí)高于C、低于A一就緒立刻搶占C。C被B壓住根本沒機(jī)會(huì)釋放互斥量于是A被C間接“卡死”。這就是教科書上的優(yōu)先級(jí)反轉(zhuǎn)。按理論說A優(yōu)先級(jí)最高應(yīng)該最快完成但實(shí)際上它等著一個(gè)“未來才有機(jī)會(huì)跑的C”釋放資源。修復(fù)方案用的是優(yōu)先級(jí)繼承當(dāng)?shù)蛢?yōu)先級(jí)任務(wù)持有高優(yōu)先級(jí)任務(wù)所需的互斥量時(shí)把低優(yōu)先級(jí)任務(wù)的優(yōu)先級(jí)臨時(shí)提升到高優(yōu)先級(jí)任務(wù)的級(jí)別讓C先跑完、釋放資源、恢復(fù)原優(yōu)先級(jí)A再繼續(xù)執(zhí)行。代碼里就是在拿鎖/解鎖操作中動(dòng)態(tài)修改TCB的優(yōu)先級(jí)并重新調(diào)度。這個(gè)修復(fù)讓我對(duì)“調(diào)度器只是外殼資源管理才是靈魂”這句話有了深刻體會(huì)。5.3 上下文切換后數(shù)據(jù)錯(cuò)亂調(diào)試器怎么一步步定位還有一次兩個(gè)任務(wù)交替跑一陣后某個(gè)全局變量莫名其妙變成了垃圾值。我心想這多半是上下文切換時(shí)某個(gè)寄存器沒保存或沒恢復(fù)。打開調(diào)試器在PendSV入口和出口各下一個(gè)斷點(diǎn)觀察PSP寄存器和棧內(nèi)存區(qū)域發(fā)現(xiàn)了一個(gè)典型錯(cuò)誤我在“保存現(xiàn)場(chǎng)”時(shí)用了STMDB R0!, {R4-R11}更新了R0但后續(xù)“恢復(fù)現(xiàn)場(chǎng)”時(shí)又用同一個(gè)R0去找新任務(wù)的SP導(dǎo)致新任務(wù)的SP指針被舊任務(wù)的棧位置干擾。這種問題用眼睛盯代碼很難發(fā)現(xiàn)但調(diào)試器里逐指令單步執(zhí)行就一目了然。后來我養(yǎng)成了一個(gè)習(xí)慣每次寫完P(guān)endSV先用單個(gè)任務(wù)自啟動(dòng)確認(rèn)第一次切換正常再兩個(gè)任務(wù)對(duì)切重點(diǎn)觀察SP和棧數(shù)據(jù)最后才加第三個(gè)任務(wù)壓測(cè)。分階段驗(yàn)證能讓定位范圍縮小很多。5.4 避坑清單速查表我在實(shí)際調(diào)試中積累的這些經(jīng)驗(yàn)整理成一個(gè)速查表遇到問題可以照著查現(xiàn)象最可能原因處理辦法一啟動(dòng)就HardFault任務(wù)棧溢出 / 初始現(xiàn)場(chǎng)偽造錯(cuò)誤查棧水印核對(duì)壓棧順序每隔固定時(shí)間就進(jìn)異常SysTick頻率過高切換開銷過大調(diào)低節(jié)拍頻率優(yōu)化臨界區(qū)長度低優(yōu)先級(jí)任務(wù)始終不執(zhí)行高優(yōu)先級(jí)任務(wù)從不阻塞給高優(yōu)先級(jí)任務(wù)加延時(shí)/等待邏輯全局變量值時(shí)好時(shí)壞中斷修改共享數(shù)據(jù)沒加臨界區(qū)用臨界區(qū)或互斥量保護(hù)切換后返回地址跑飛PendSV中SP恢復(fù)順序錯(cuò)誤單步跟蹤核對(duì)進(jìn)出棧SP值PendSV一直不執(zhí)行PendSV優(yōu)先級(jí)被設(shè)成和SysTick相同或更高將PendSV設(shè)為所有可屏蔽中斷最低級(jí)6. 最后聊幾句個(gè)人心得手寫一個(gè)搶占式調(diào)度器最大的收獲不是“我會(huì)寫切換”這件事而是真正理解了操作系統(tǒng)為什么把調(diào)度器和中斷系統(tǒng)設(shè)計(jì)得如此緊密。那些平時(shí)用RTOS時(shí)覺得理所當(dāng)然的API比如“延時(shí)”“信號(hào)量”底層全靠一套精確的上下文切換在做支撐。紙上談兵一百遍不如自己把TCB建出來、把SysTick和PendSV跑通一遍來得扎實(shí)。如果讓我給剛開始動(dòng)手的人一個(gè)建議那就是第一版千萬不要貪多先讓兩個(gè)任務(wù)在SysTick驅(qū)動(dòng)下“輪流亮相”哪怕它們只負(fù)責(zé)翻轉(zhuǎn)變量跑通就是勝利。之后再慢慢加入優(yōu)先級(jí)、阻塞喚醒、資源鎖。我就是這么一步步踩過來的期間犧牲過好幾塊開發(fā)板調(diào)Sch的“黑盒時(shí)間”但最終換來的是對(duì)調(diào)度機(jī)制真正的掌控感。這個(gè)原型后面還能繼續(xù)擴(kuò)展的方向很多加軟件定時(shí)器、郵箱、信號(hào)量甚至把任務(wù)棧從靜態(tài)數(shù)組改成動(dòng)態(tài)分配做成一個(gè)微型RTOS。但不管怎么加核心始終是那套“保存現(xiàn)場(chǎng)、選人、恢復(fù)現(xiàn)場(chǎng)”的鐵三角。把這套機(jī)制用自己的手寫透一次以后再看任何RTOS的源碼都會(huì)有一種“原來如此”的親切感。