幾個(gè)月前我被手上一臺(tái) 32 位單片機(jī)搞得焦頭爛額一個(gè)溫控儀功能并不復(fù)雜就是按鍵面板、一路溫度傳感器、一組繼電器輸出外加數(shù)碼管顯示。結(jié)果裸機(jī)主循環(huán)里塞滿了 debounce 標(biāo)志、采樣定時(shí)標(biāo)志、串口協(xié)議狀態(tài)機(jī)光全局標(biāo)志就定義了十幾個(gè)。直到我認(rèn)真試了 QuarkTS 這個(gè)輕型調(diào)度內(nèi)核才算是把單片機(jī)軟件從“一堆 if 的迷宮”里解放出來。這篇文章不是講 Kernel 源碼解析也不是官方文檔翻譯而是我自己從零開始、在一顆普通 MCU 上完成移植的完整記錄和踩坑總結(jié)。給單片機(jī)“移植操作系統(tǒng)”這個(gè)詞聽起來嚇人但實(shí)際上 QuarkTS 并不要求你去改內(nèi)核源碼它更強(qiáng)調(diào)“配置 接好兩個(gè)硬件依賴”。真正需要你親自動(dòng)手的只有系統(tǒng) tick 源、臨界區(qū)保護(hù)再加上任務(wù)劃分。下面我把整個(gè)過程拆開講。1. 為什么我不建議一上來就上 FreeRTOSQuarkTS 的定位差別1.1 裸機(jī)主循環(huán)到了什么階段會(huì)撐不住我見過不少人的單片機(jī)項(xiàng)目是這樣一個(gè)套路主循環(huán)里寫一個(gè)巨大的 while(1)每隔 10ms 掃描一次按鍵每隔 50ms 刷新一次數(shù)碼管每隔 200ms 讀一次傳感器中間再穿插串口接收解析。最初功能少這種寫法沒什么問題一旦業(yè)務(wù)變多你會(huì)發(fā)現(xiàn)每個(gè)功能模塊都要“見縫插針”地?cái)D進(jìn)這個(gè)大循環(huán)修改一個(gè)地方的延時(shí)另一處的響應(yīng)時(shí)間就跟著漂。更難受的是中斷里攢了一堆事件標(biāo)志主循環(huán)里到處查標(biāo)志。查著查著代碼就變成一團(tuán)毛線。這個(gè)階段你不是缺一個(gè)功能而是缺一套“如何組織多個(gè)并發(fā)業(yè)務(wù)”的框架。往小了說這是軟件結(jié)構(gòu)問題往大了說你需要一個(gè)能在小型 MCU 上跑起來的多任務(wù)環(huán)境。但這里有個(gè)陷阱多數(shù)人第一反應(yīng)是上實(shí)時(shí)操作系統(tǒng)比如搶占式調(diào)度的那一類。1.2 協(xié)作式調(diào)度與搶占式調(diào)度的一字之差QuarkTS 本身是協(xié)作式調(diào)度內(nèi)核和常見的搶占式 RTOS 有本質(zhì)區(qū)別。搶占式內(nèi)核會(huì)在任意時(shí)刻打斷一個(gè)任務(wù)切換給另一個(gè)高優(yōu)先級(jí)任務(wù)這需要完整的上下文切換、優(yōu)先級(jí)反轉(zhuǎn)保護(hù)、互斥量等機(jī)制。而協(xié)作式調(diào)度器依賴每個(gè)任務(wù)主動(dòng)讓出 CPU內(nèi)核只負(fù)責(zé)維護(hù)“該輪到誰跑”不需要在任意位置保存和恢復(fù)寄存器現(xiàn)場(chǎng)所以代碼量和 RAM 占用都能壓得非常低。我用一個(gè)表把差別講清楚對(duì)比維度搶占式 RTOS協(xié)作式調(diào)度QuarkTS 這一類切換時(shí)機(jī)任何時(shí)刻由調(diào)度器決定任務(wù)主動(dòng)讓出yield或等待事件上下文切換開銷較大需要保存完整寄存器組小執(zhí)行流相對(duì)可預(yù)測(cè)共享資源保護(hù)需要互斥量/信號(hào)量/禁中斷天然少很多競(jìng)爭(zhēng)配合臨界區(qū)即可任務(wù)最長(zhǎng)運(yùn)行時(shí)間由時(shí)間片/優(yōu)先級(jí)約束靠任務(wù)自律一個(gè)任務(wù)死循環(huán)其余全卡適用 MCU中高端RAM 幾十 KB 以上小 RAM、定時(shí)器資源少、業(yè)務(wù)為事件驅(qū)動(dòng)關(guān)鍵的“一字之差”就在這里搶占式靠強(qiáng)制協(xié)作式靠自覺。對(duì)大多數(shù)工業(yè)傳感器、小家電控制、儀器儀表這類項(xiàng)目來說業(yè)務(wù)天然是“輪詢 事件響應(yīng)”協(xié)作式不僅能滿足需求還省掉了大量同步機(jī)制。你不需要寫互斥鎖不需要擔(dān)心優(yōu)先級(jí)反轉(zhuǎn)寫代碼的心智負(fù)擔(dān)小很多。1.3 到底什么時(shí)候才算“從零開始移植”很多官方移植教程都假設(shè)你有一塊廠商的開發(fā)板直接用現(xiàn)成工程配置。而我這次說的“從零開始”是指你手頭只有一顆裸 MCU、一塊自繪 PCB沒有現(xiàn)成模板所有東西從芯片啟動(dòng)文件開始搭。這種場(chǎng)景下QuarkTS 反而是很友好的選擇它不綁定某個(gè)特定內(nèi)核不要求你一定用 SysTick也不要求你有 RTOS 專用的 heap 管理只要你把 tick 和臨界區(qū)接好剩下的就是業(yè)務(wù)任務(wù)劃分。如果你的項(xiàng)目滿足下面幾條我覺得可以放心往下走任務(wù)數(shù)量在幾個(gè)到十幾個(gè)之間不需要復(fù)雜的優(yōu)先級(jí)搶占大部分工作是周期性輪詢或者等待事件后短時(shí)間處理RAM 資源緊張不希望在底層機(jī)制上耗掉太多空間你希望代碼易讀、易調(diào)試不想處理太多異步打斷。2. 硬件相關(guān)的只有兩條腿系統(tǒng) tick 與臨界區(qū)2.1 tick 是調(diào)度器的心跳但不是時(shí)間片在傳統(tǒng) RTOS 里tick 是時(shí)間片輪轉(zhuǎn)的基礎(chǔ)一個(gè) tick 之后調(diào)度器可能強(qiáng)行切換任務(wù)。QuarkTS 的 tick 不是這個(gè)角色它主要用來驅(qū)動(dòng)軟件定時(shí)器、超時(shí)判斷、時(shí)間戳等待。換句話說tick 是心跳負(fù)責(zé)“記時(shí)間”不是負(fù)責(zé)“搶 CPU”。這意味著 tick 周期選擇不用太激進(jìn)。我見過有人為了“實(shí)時(shí)性”把 tick 設(shè)到 1kHz、甚至 10kHz結(jié)果任務(wù)都在等著讓出中斷卻把 CPU 消耗了大半。一般來說 1kHz1ms 一次已經(jīng)比較穩(wěn)如果你的業(yè)務(wù)對(duì)超時(shí)不敏感用 100Hz10ms也行。我的建議是先用 1kHz理由很簡(jiǎn)單QuarkTS 里的事件等待、延時(shí)函數(shù)、軟件定時(shí)器大多以 tick 為單位1ms 粒度對(duì)大多數(shù)傳感交互足夠了而且 32 位 MCU 處理一次 tick 中斷的耗時(shí)通常在幾微秒以內(nèi)。2.2 SysTick 配置與重裝載值計(jì)算Cortex-M 內(nèi)核自帶 SysTick這是最省事的 tick 源。它本質(zhì)上是一個(gè) 24 位遞減計(jì)數(shù)器減到 0 時(shí)觸發(fā)中斷并自動(dòng)重裝。配置的核心是算重裝載值重裝載值 SysTick 輸入時(shí)鐘頻率 / 目標(biāo) tick 頻率 - 1如果你用內(nèi)核時(shí)鐘做 SysTick 時(shí)鐘源假設(shè) MCU 主頻是 72MHz目標(biāo) 1ms tick那么重裝載值 72_000_000 / 1_000 - 1 71999用 CMSIS 接口一句話就能完成初始化volatile uint32_t g_tick_count 0; void BSP_Tick_Init(void) { SysTick_Config(SystemCoreClock / 1000); /* 1ms 一次中斷 */ NVIC_SetPriority(SysTick_IRQn, 0xFF); /* 優(yōu)先級(jí)放到最低 */ }SysTick_Config 是標(biāo)準(zhǔn) CMSIS 接口它會(huì)自動(dòng)設(shè)置重裝載值并開中斷。SysTick 優(yōu)先級(jí)我建議給到最低原因后面“踩坑日志”里專門說。如果芯片沒有 SysTick那就隨便挑一個(gè)通用定時(shí)器的更新中斷用同樣的思路配置溢出周期 1ms中斷里做同一件事。2.3 臨界區(qū)調(diào)度器對(duì)中斷的“短暫禁令”臨界區(qū)用于保護(hù)共享數(shù)據(jù)。當(dāng)任務(wù)正在修改一個(gè)結(jié)構(gòu)體、一個(gè)變量時(shí)突然來了中斷中斷里又改了同樣的數(shù)據(jù)那么任務(wù)恢復(fù)后拿到的數(shù)據(jù)可能是半新半舊的。QuarkTS 在操作系統(tǒng)內(nèi)部會(huì)用臨界區(qū)保護(hù)自己的任務(wù)鏈表你寫業(yè)務(wù)代碼時(shí)凡是涉及任務(wù)與中斷共享的變量也應(yīng)該自己加臨界區(qū)。Cortex-M 上最簡(jiǎn)單可靠的臨界區(qū)就是開關(guān)全局中斷#define ENTER_CRITICAL() __disable_irq() #define EXIT_CRITICAL() __enable_irq()__disable_irq 實(shí)際操作的是 PRIMASK 寄存器也就是把除 NMI 和 Fault 之外的所有中斷都屏蔽掉。它執(zhí)行時(shí)間極短對(duì)實(shí)時(shí)性影響很小。關(guān)鍵是臨界區(qū)代碼必須短不要在里面做延時(shí)、打印、或者等待外設(shè)。臨界區(qū)是給“改一個(gè)變量、插入一個(gè)節(jié)點(diǎn)”這種微操作用的不是給你跑業(yè)務(wù)邏輯用的。至于 QuarkTS 自身怎么調(diào)用臨界區(qū)不同小版本的宏名可能不同。你下載源碼后在配置頭文件里都會(huì)找到類似“臨界區(qū)實(shí)現(xiàn)方式”的地方把我上面這兩個(gè)宏填進(jìn)去即可。如果你用的 MCU 不是 Cortex-M比如是老 8 位單片機(jī)那就用它的全局中斷開關(guān)匯編指令原理完全一樣。3. 按需裁剪讓內(nèi)核為這臺(tái)單片機(jī)“瘦身”3.1 配置頭文件要回答的三個(gè)問題拿到 QuarkTS 源碼后別急著往工程里拖先打開配置頭文件。它就像一張問卷問你這臺(tái)單片機(jī)準(zhǔn)備承擔(dān)多少業(yè)務(wù)。核心問題大概有三個(gè)最多同時(shí)存在多少個(gè)任務(wù)這里說的是“已創(chuàng)建的任務(wù)”不是“可能運(yùn)行的任務(wù)”按峰值算。需要用多少個(gè)軟件定時(shí)器、消息隊(duì)列、事件標(biāo)志這些資源每種都要預(yù)先分配內(nèi)存寧少勿多。要不要開啟某些高級(jí)特性比如粘性調(diào)度、任務(wù)狀態(tài)機(jī)輔助等用不上就關(guān)閉。我自己的習(xí)慣是先把業(yè)務(wù)盤一遍。比如一個(gè)溫控項(xiàng)目用到的任務(wù)可能就是按鍵掃描、LED 刷新、傳感器采集、控制運(yùn)算、串口協(xié)議處理一共五六個(gè)。軟件定時(shí)器可能要用一兩個(gè)做超時(shí)看門。消息隊(duì)列一個(gè)放傳感器數(shù)據(jù)。事件標(biāo)志兩三個(gè)做喚醒。那就按這個(gè)量配置不要一上來拷貝一個(gè)大工程的全功能配置否則一個(gè) 32KB RAM 的芯片很容易被各種池子吃掉一大半。3.2 任務(wù)棧給每個(gè)任務(wù)劃一塊“私有內(nèi)存”協(xié)作式調(diào)度下任務(wù)函數(shù)本質(zhì)是普通函數(shù)的持續(xù)調(diào)用過程函數(shù)里的局部變量、函數(shù)調(diào)用鏈上的臨時(shí)量都放在棧上。QuarkTS 要求你為每個(gè)任務(wù)準(zhǔn)備一段獨(dú)立的棧空間典型做法是靜態(tài)數(shù)組#define TASK_STACK_SIZE 256 /* 單位word */ static uint32_t task_led_stack[TASK_STACK_SIZE]; static uint32_t task_key_stack[TASK_STACK_SIZE];這里的 256 是“字”不是“字節(jié)”。在 32 位 MCU 上256 字等于 1KB RAM 空間。為什么不用動(dòng)態(tài)分配嵌入式系統(tǒng)動(dòng)態(tài)分配容易產(chǎn)生碎片也增加不確定性靜態(tài)數(shù)組簡(jiǎn)單、可預(yù)測(cè)、還能在調(diào)試器里直接查看。如果你手頭 RAM 緊張可以精簡(jiǎn)任務(wù)里的局部變量然后逐步下降棧大小直到逼近臨界值。注意如果任務(wù)里調(diào)用了 printf、浮點(diǎn)格式化這類工具棧需求會(huì)猛漲單這種調(diào)用就可能吃掉幾百字節(jié)。所以我一般在協(xié)議解析任務(wù)里禁止浮點(diǎn)格式化寧可手動(dòng)轉(zhuǎn)字符串。關(guān)于棧大小是否夠我強(qiáng)烈建議做一個(gè)“填坑測(cè)試”在創(chuàng)建任務(wù)前用特定填充字節(jié)比如 0xAA把整塊任務(wù)棧刷一遍運(yùn)行一段時(shí)間后檢查棧尾還剩多少 0xAA 沒被覆蓋。這個(gè)技巧簡(jiǎn)單但極其有用能直觀告訴你每個(gè)任務(wù)真實(shí)峰值棧用量是多少。3.3 裁剪后如何驗(yàn)證 ROM 和 RAM 預(yù)算配置完編譯一次編譯器會(huì)輸出 code 和 data 的占用統(tǒng)計(jì)。以我那個(gè)項(xiàng)目為例QuarkTS 內(nèi)核自身 ROM 開銷大概在幾 KB 量級(jí)RAM 開銷大頭是你給任務(wù)、隊(duì)列、定時(shí)器分配的靜態(tài)數(shù)組而不是內(nèi)核本身。如果你發(fā)現(xiàn)靜態(tài)數(shù)據(jù)比預(yù)期大很多別急著懷疑內(nèi)核回去看自己是不是任務(wù)棧開得太大、消息池塞了太多條。我見過有人把每個(gè)任務(wù)棧都開了 4KB美其名曰“保險(xiǎn)”結(jié)果一個(gè)本來 16KB RAM 的芯片直接爆掉。正確的姿勢(shì)是先按業(yè)務(wù)估算一個(gè)保守值跑起來之后用前面說的填充法實(shí)測(cè)再反復(fù)壓縮到安全邊界以內(nèi)。嵌入式開發(fā)里“內(nèi)存是擠出來的”一點(diǎn)都不夸張。4. 第一個(gè)任務(wù)跑起來從 main 到調(diào)度循環(huán)的完整骨架4.1 main 函數(shù)的初始化順序任務(wù)棧、內(nèi)核配置都準(zhǔn)備好以后main 函數(shù)里的順序就成了關(guān)鍵。我的模板大致是這樣#include quarkts.h #include bsp.h /* 任務(wù)函數(shù)聲明 */ static void Task_Led(void *arg); static void Task_Key(void *arg); /* 任務(wù)棧 */ static uint32_t stack_led[128]; static uint32_t stack_key[256]; int main(void) { BSP_Init(); /* 時(shí)鐘、GPIO、串口等基礎(chǔ)外設(shè) */ /* 1. 內(nèi)核初始化接口具體以你的版本頭文件為準(zhǔn) */ QK_Init(); /* 2. 創(chuàng)建任務(wù) */ QK_TaskCreate(Task_Led, QK_PRIO_LOW, stack_led, sizeof(stack_led), NULL); QK_TaskCreate(Task_Key, QK_PRIO_HIGH, stack_key, sizeof(stack_key), NULL); /* 3. 啟動(dòng)調(diào)度器。啟動(dòng)后 main 通常不再返回 */ QK_SchedulerStart(); while (1) { /* 如果調(diào)度器返回說明配置有問題 */ } }一句話說明先初始化底層外設(shè)再初始化內(nèi)核然后創(chuàng)建任務(wù)最后啟動(dòng)調(diào)度。順序不要反。如果你在內(nèi)核初始化之前就去調(diào)用延時(shí)有系統(tǒng)函數(shù)或者在外設(shè)還沒跑起來前就創(chuàng)建依賴該外設(shè)的任務(wù)大概率會(huì)遇到奇怪的初始化失敗。另外調(diào)度器一旦啟動(dòng)main 函數(shù)就被“接管”了后面不要再想著返回編譯器和調(diào)試器都不喜歡這個(gè)假設(shè)。4.2 任務(wù)函數(shù)的生命周期與“永不返回”原則剛才代碼里任務(wù)函數(shù) Task_Led 和 Task_Key 都是我自己寫的。它們的簽名類似普通 C 函數(shù)都有一個(gè) void* 參數(shù)但行為上有幾條硬性規(guī)則任務(wù)函數(shù)應(yīng)當(dāng)在 for(;;) 里無限循環(huán)不要在末尾 return循環(huán)體內(nèi)不能長(zhǎng)時(shí)間占用 CPU要主動(dòng)讓出或者等待事件一個(gè)任務(wù)的任務(wù)函數(shù)入口會(huì)被調(diào)用一旦函數(shù)退出這個(gè)任務(wù)就徹底結(jié)束了這種情況要視為異常。協(xié)作式調(diào)度下任務(wù)函數(shù)就像合租室友里的一群人每個(gè)人用完廁所要主動(dòng)出來否則其他人永遠(yuǎn)等不到。你在任務(wù)里寫 while(1) 等待一個(gè)外部電平變化卻不主動(dòng)讓出那等價(jià)于把整個(gè)系統(tǒng)都暫停了。4.3 一個(gè) LED 閃爍 按鍵輪詢的最小例子下面給一個(gè)最小但完整的例子你可以直接抄到自己的工程里改一改static void Task_Led(void *arg) { (void)arg; for (;;) { LED_Toggle(); QK_DelayMs(500); /* 固定延時(shí) 500ms內(nèi)部會(huì)主動(dòng)讓出 */ } } static void Task_Key(void *arg) { (void)arg; for (;;) { if (Key_Scan() KEY_PRESSED) { Buzzer_On(); } else { Buzzer_Off(); } QK_Yield(); /* 主動(dòng)讓出 CPU */ } }注意看 Task_Led 里的 QK_DelayMs它不是裸機(jī)里的 delay 空循環(huán)而是在等待超時(shí)期間把 CPU 讓給其他任務(wù)這正是協(xié)作式調(diào)度的魅力。Task_Key 每輪掃描一次后主動(dòng)讓出好讓 LED 任務(wù)有執(zhí)行機(jī)會(huì)。兩個(gè)任務(wù)就這么互相配合誰也不把 CPU 獨(dú)吞。接口名仍然以你下載版本的發(fā)布頭文件為準(zhǔn)但邏輯結(jié)構(gòu)就是這樣。4.4 第一個(gè)任務(wù)的驗(yàn)證方法跑起來之后第一件事不是寫一堆日志而是先在調(diào)試器里看兩個(gè)任務(wù)棧指針是否正常推進(jìn)、調(diào)度器切了沒有。我的土辦法是在兩個(gè)任務(wù)里各翻轉(zhuǎn)一個(gè) GPIO然后用示波器觀察波形如果 LED 任務(wù)里的 GPIO 以 500ms 周期翻轉(zhuǎn)說明延時(shí)任務(wù)工作正常按鍵任務(wù)里的 GPIO 高頻翻轉(zhuǎn)說明任務(wù)循環(huán)沒有被卡死兩個(gè)波形互不阻塞說明調(diào)度器切換成功。這個(gè)方法比 printf 可靠因?yàn)?printf 本身可能拖慢任務(wù)、引入不可預(yù)期的時(shí)序。等波形穩(wěn)定了再考慮串口日志輸出。5. 任務(wù)不是各干各的事件標(biāo)志和輕量隊(duì)列怎么用5.1 事件標(biāo)志解決“等條件”而不是“查條件”裸機(jī)里判斷條件最常見的寫法是全局標(biāo)志位比如if (adc_done_flag key_pressed_flag) { ... }任務(wù)少的時(shí)候行得通任務(wù)一多你就要考慮“誰在等這個(gè)條件”“條件滿足后該醒誰”。QuarkTS 這類內(nèi)核通常給你事件標(biāo)志任務(wù)可以阻塞在某些位上等內(nèi)核來通知。事件標(biāo)志適合表達(dá)“某個(gè)事件發(fā)生了”這種邏輯比如傳感器轉(zhuǎn)換完成定時(shí)時(shí)間到串口收到完整一幀按鍵按下。用事件標(biāo)志之后任務(wù)不再反復(fù)輪詢而是“睡”在一個(gè)或多個(gè)位上條件滿足后內(nèi)核會(huì)自動(dòng)把它喚醒。多人合租的場(chǎng)景里這就是“別人告訴你水開了”而不是“你一直盯著水壺”。代碼語義更清楚CPU 利用率也更高。5.2 輕量隊(duì)列傳遞數(shù)據(jù)事件標(biāo)志只能表達(dá)“事情發(fā)生了”表達(dá)不了“發(fā)生了的具體內(nèi)容”。比如溫控項(xiàng)目里一個(gè)任務(wù)負(fù)責(zé)采樣 ADC另一個(gè)任務(wù)負(fù)責(zé)控溫采樣值從哪傳過去共享變量是一種方案但交叉訪問容易出問題更好的方案是輕量消息隊(duì)列。生產(chǎn)者任務(wù)把 ADC 結(jié)果塞進(jìn)隊(duì)列消費(fèi)任務(wù)等待隊(duì)列非空后取走/* 配置頭文件里預(yù)留消息隊(duì)列并指定一條隊(duì)列尺寸 */ static void Task_Collect(void *arg) { for (;;) { uint16_t raw ADC_GetValue(); QK_QueueSend(adc_queue, raw, sizeof(raw)); QK_DelayMs(10); } } static void Task_Control(void *arg) { for (;;) { uint16_t raw; if (QK_QueueReceive(adc_queue, raw, QK_WAIT_FOREVER) QK_OK) { /* 根據(jù) raw 計(jì)算 PWM 輸出 */ Control_Temperature(raw); } } }隊(duì)列的好處是解耦生產(chǎn)者和消費(fèi)者各自按自己的節(jié)奏工作中間多出的數(shù)據(jù)由隊(duì)列緩沖。隊(duì)列深度別開太大我是根據(jù)生產(chǎn)周期和消費(fèi)速度算的。比如生產(chǎn)任務(wù)每 10ms 發(fā)一條消費(fèi)任務(wù)處理一條要 30ms那么隊(duì)列至少要有三條左右的緩沖我一般再留 50% 余量開五條既安全又不浪費(fèi) RAM。5.3 軟件定時(shí)器的合理姿勢(shì)QuarkTS 一般還提供軟件定時(shí)器這跟硬件定時(shí)器是兩碼事它適合“固定時(shí)間到了要做什么”的場(chǎng)景。比如設(shè)備需要每隔 2 秒做一次自檢用軟件定時(shí)器比在任務(wù)里延時(shí)更清晰。但要注意回調(diào)函數(shù)里不要做耗時(shí)操作否則同樣會(huì)拖住調(diào)度器。我的習(xí)慣是定時(shí)器回調(diào)里只置事件標(biāo)志真正的檢查邏輯放到對(duì)應(yīng)任務(wù)里去執(zhí)行保證“通知”和“干活”分開。6. 我在實(shí)際移植過程中踩過的五個(gè)坑6.1 坑一tick 中斷優(yōu)先級(jí)設(shè)得比臨界區(qū)還高最早我圖省事把 SysTick 優(yōu)先級(jí)設(shè)得很高想著“時(shí)間最重要”。結(jié)果很詭異任務(wù)切來切去偶爾死機(jī)而且不是必現(xiàn)。找了一下午發(fā)現(xiàn)原因系統(tǒng)臨界區(qū)關(guān)閉全局中斷后高優(yōu)先級(jí) SysTick 依然可以打入而 tick 處理函數(shù)里又試圖修改內(nèi)核的任務(wù)鏈表。臨界區(qū)想保護(hù)的正是這份鏈表的一致性結(jié)果反被打斷鏈表改到一半被改第二次系統(tǒng)當(dāng)然崩潰。解決的規(guī)范做法是把 SysTick 優(yōu)先級(jí)設(shè)到最低同時(shí)保證 ISR 里不調(diào)用任何內(nèi)核操作接口只做最輕量的計(jì)時(shí)通知。如果你必須在高優(yōu)先級(jí)中斷里發(fā)數(shù)據(jù)也不要直接操作隊(duì)列而是先放到一個(gè) volatile 標(biāo)記里由普通任務(wù)去“消費(fèi)”。6.2 坑二在協(xié)作任務(wù)里用裸機(jī) delay 磨時(shí)間新上手最容易犯的錯(cuò)就是把原來裸機(jī)里的軟件延時(shí)函數(shù)原封不動(dòng)搬進(jìn)任務(wù)for (i 0; i 10000; i); /* 這就是個(gè)炸彈 */在裸機(jī)里這行代碼只是讓主循環(huán)慢一點(diǎn)在協(xié)作式調(diào)度器里它會(huì)讓整個(gè)系統(tǒng)凍結(jié)到這個(gè)循環(huán)結(jié)束。因?yàn)閰f(xié)作式調(diào)度靠任務(wù)主動(dòng)讓出你一個(gè)空循環(huán)占住 CPU其他任務(wù)包括 tick 處理函數(shù)之外的業(yè)務(wù)全都等著。正確做法是把延時(shí)換成 QuarkTS 提供的延時(shí)等待接口或者干脆把“等待一段時(shí)間”設(shè)計(jì)成事件/定時(shí)器觸發(fā)而不是死等。6.3 坑三棧溢出表現(xiàn)為各種“不可能”某天我發(fā)現(xiàn)一個(gè)任務(wù)運(yùn)行一會(huì)兒后另一個(gè)毫不相干的變量被改成了 0x00就像鬧鬼。調(diào)試器看變量值變了看代碼路徑又完全沒寫過這個(gè)變量。最后排查無果試著把疑似任務(wù)棧擴(kuò)大一倍現(xiàn)象消失。這就是棧溢出的典型表現(xiàn)任務(wù)棧不夠用函數(shù)局部變量壓棧時(shí)越界把相鄰的全局變量或另一個(gè)任務(wù)的棧踩掉了。從此以后我給自己定了一條規(guī)矩每個(gè)任務(wù)第一次跑通之后都要做“填坑測(cè)試”。初始化時(shí)把任務(wù)棧全部填成 0xAA正常運(yùn)行幾小時(shí)后檢查棧尾字節(jié)是否還是 0xAA如果變了說明這任務(wù)運(yùn)行過一段較深的調(diào)用鏈棧不夠。這個(gè)辦法雖然土但在小內(nèi)存 MCU 上是真能救命。6.4 坑四編譯器優(yōu)化改變了共享變量的行為早期我有個(gè)共享變量從中斷里更新主任務(wù)里普通讀取。開調(diào)試模式正常一開 Level 2 優(yōu)化任務(wù)那邊看到的數(shù)據(jù)就明顯“滯后”。原因很簡(jiǎn)單編譯器認(rèn)為那個(gè)變量在任務(wù)循環(huán)里沒人改就把讀取操作優(yōu)化成只從寄存器拿值了。中斷雖然改了內(nèi)存里的值任務(wù)這邊卻還在用緩存的舊值。解決方式就兩個(gè)字volatile。凡是中斷和任務(wù)共享的變量一律用 volatile 修飾或者干脆通過隊(duì)列/事件標(biāo)志傳遞讓編譯器別做過度優(yōu)化。還有一個(gè)小技巧別指望“把優(yōu)化等級(jí)降低”就當(dāng)修復(fù)了那只代表你掩蓋了代碼里的數(shù)據(jù)依賴問題。6.5 坑五分不清“阻塞等待”與“讓出 CPU”事件標(biāo)志等待、隊(duì)列接收這類操作內(nèi)部一般是阻塞等待也就是任務(wù)會(huì)被掛起讓出 CPU直到事件到達(dá)。這是好的。但如果我在一個(gè)任務(wù)里寫了這樣的代碼while (GPIO_ReadPin(PORT, PIN) HIGH) { /* 等待某個(gè)外部信號(hào)拉低 */ }這就變成了“死磕”外部信號(hào)不來這個(gè)任務(wù)永遠(yuǎn)占用 CPU其他任務(wù)全部停工。這不是內(nèi)核的問題是協(xié)作式開發(fā)的紀(jì)律問題。凡是等待外部事件都要通過事件標(biāo)志、隊(duì)列或者延時(shí)輪詢來讓出 CPU絕不能用一個(gè)不加讓出的 while 循環(huán)直接等。我的心得是寫任務(wù)函數(shù)之前先在紙上把每個(gè)任務(wù)畫成“事件流”。任務(wù)醒來、干活、讓出、等什么、醒來之后干什么一步步畫清楚再寫代碼坑就能避掉一大半。QuarkTS 不是萬能的調(diào)度器它要求開發(fā)人員有清晰的協(xié)作意識(shí)但一旦適應(yīng)了這套事件驅(qū)動(dòng)的寫法開發(fā)效率真的比在裸機(jī)里放大一堆標(biāo)志高太多了。如果你也在考慮把某個(gè)小項(xiàng)目往 QuarkTS 上遷建議先從最精簡(jiǎn)的配置開始一個(gè) LED 任務(wù)、一個(gè)按鍵任務(wù)、一個(gè)串口任務(wù)跑通之后再逐步加隊(duì)列、軟件定時(shí)器。第一版別追求功能齊全先把“讓出 CPU”和“事件驅(qū)動(dòng)”的感覺找到后面就順了。