定時(shí)器模擬任務(wù)：手寫輕量級任務(wù)調(diào)度器)
在實(shí)際的嵌入式項(xiàng)目里任務(wù)調(diào)度并不是引入 RTOS 之后才需要考慮的問題。很多基于 STM32、51、Arduino 的裸機(jī)項(xiàng)目代碼一開始是從流水燈開始的等按鍵、傳感器、顯示、通信模塊都加進(jìn)來之后main 函數(shù)里通常會變成一個(gè)巨大的 while(1) 循環(huán)各種功能按固定順序輪流執(zhí)行。表面上看每個(gè)功能都能跑但某個(gè)函數(shù)內(nèi)部一旦加了一段延時(shí)或等待整個(gè)系統(tǒng)的實(shí)時(shí)性就會明顯下降。這時(shí)定時(shí)器模擬任務(wù)就成為一種非常實(shí)用的裸機(jī)架構(gòu)升級手段用定時(shí)器中斷產(chǎn)生統(tǒng)一時(shí)基把大循環(huán)拆成多個(gè)可獨(dú)立調(diào)度的周期任務(wù)讓程序具備接近時(shí)間片輪轉(zhuǎn)的調(diào)度效果。這篇文章會從超級大循環(huán)的代碼缺陷講起解釋定時(shí)器模擬任務(wù)的基本概念再給出一個(gè)可以在 STM32 上直接運(yùn)行的輕量任務(wù)調(diào)度器實(shí)現(xiàn)。代碼不依賴 RTOS卻可以復(fù)現(xiàn) FreeRTOS 里最重要的周期性任務(wù)調(diào)度思路適合想理解嵌入式調(diào)度原理、準(zhǔn)備嵌入式面試、或者想把裸機(jī)項(xiàng)目改造成更規(guī)范架構(gòu)的開發(fā)者。1. 定時(shí)器模擬任務(wù)概念從超級大循環(huán)到事件驅(qū)動架構(gòu)1.1 超級大循環(huán)能用但會逐漸失控的程序結(jié)構(gòu)裸機(jī)項(xiàng)目最常見的代碼結(jié)構(gòu)是超級大循環(huán)也叫前后臺系統(tǒng)中的后臺部分。前臺是中斷后臺就是 main 函數(shù)里的一個(gè)死循環(huán)。典型的寫法是把按鍵掃描、傳感器讀取、屏幕刷新、協(xié)議解析全部放在同一個(gè) while(1) 中int main(void) { while (1) { key_scan(); sensor_read(); display_update(); protocol_process(); } }這種結(jié)構(gòu)在功能很少時(shí)非常直觀代碼從上往下執(zhí)行邏輯清楚。但問題會隨著功能增加而暴露出來。假設(shè)sensor_read()里使用阻塞延時(shí)等待傳感器轉(zhuǎn)換完成比如讀取一個(gè)需要 10ms 才能穩(wěn)定的 ADC 采樣結(jié)果那么這 10ms 內(nèi)key_scan()和display_update()都在等待。用戶按下的按鍵不會立即響應(yīng)屏幕刷新也會卡頓。更嚴(yán)重的是如果某個(gè)通信函數(shù)使用超時(shí)循環(huán)等待應(yīng)答而這個(gè)超時(shí)時(shí)間寫得比較長整個(gè)系統(tǒng)的反應(yīng)速度會被拉得很差。超級大循環(huán)的缺點(diǎn)可以歸結(jié)為三點(diǎn)實(shí)時(shí)性差。一個(gè)任務(wù)的阻塞會拖累所有后續(xù)任務(wù)。擴(kuò)展性差。新增一個(gè)功能就要插入循環(huán)某處還要小心會不會影響現(xiàn)有任務(wù)的執(zhí)行周期。時(shí)序不可控。每個(gè)功能的執(zhí)行頻率完全取決于循環(huán)整體運(yùn)行時(shí)間無法保證固定周期。所以當(dāng)項(xiàng)目里出現(xiàn)“某個(gè)任務(wù)稍微延遲幾毫秒系統(tǒng)表現(xiàn)就異常”的情況時(shí)需要的就是一種能把“任務(wù)”和“時(shí)間”解耦的架構(gòu)。1.2 定時(shí)器如何把大循環(huán)改造成多任務(wù)結(jié)構(gòu)要解決阻塞問題最直接的辦法是引入定時(shí)器。定時(shí)器產(chǎn)生固定頻率的中斷比如每 1ms 中斷一次。每次中斷時(shí)一個(gè)全局計(jì)數(shù)變量加一。主循環(huán)里不再按固定順序盲目執(zhí)行所有函數(shù)而是根據(jù)當(dāng)前計(jì)數(shù)判斷該執(zhí)行哪個(gè)任務(wù)。這種做法的本質(zhì)是把“時(shí)間”從“任務(wù)代碼”中抽出來用一個(gè)獨(dú)立時(shí)基驅(qū)動所有任務(wù)。每個(gè)任務(wù)不再自己用 delay 制造延時(shí)而是通過調(diào)度器判斷“現(xiàn)在是否到了該運(yùn)行的時(shí)刻”。這樣即使某個(gè)任務(wù)內(nèi)部有短暫阻塞其他任務(wù)也只會延遲最多一個(gè)任務(wù)周期的運(yùn)行時(shí)間而不是被整個(gè)阻塞住。從架構(gòu)角度看這種改動就實(shí)現(xiàn)了事件驅(qū)動定時(shí)器中斷產(chǎn)生周期事件也就是 tick。主循環(huán)根據(jù) tick 判斷事件類型并調(diào)用對應(yīng)處理函數(shù)。各任務(wù)從主動延時(shí)等待變成被動輪詢執(zhí)行。事件驅(qū)動架構(gòu)的最大收益是任務(wù)之間的耦合被大幅降低。按鍵掃描可以作為 10ms 周期任務(wù)運(yùn)行LED 閃爍可以作為 500ms 周期任務(wù)運(yùn)行傳感器數(shù)據(jù)解析可以作為 100ms 周期任務(wù)運(yùn)行它們互不修改對方的代碼。1.3 定時(shí)器模擬任務(wù)與 RTOS 任務(wù)調(diào)度的關(guān)系定時(shí)器模擬任務(wù)這個(gè)概念最容易被誤解成“用定時(shí)器做延時(shí)”。實(shí)際上它模擬的是 RTOS 最基本的調(diào)度機(jī)制按照時(shí)間片決定哪個(gè)任務(wù)運(yùn)行。FreeRTOS 這類系統(tǒng)也有一個(gè)滴答定時(shí)器也就是 SysTick用來產(chǎn)生系統(tǒng)時(shí)基。每次 tick 中斷時(shí)內(nèi)核檢查是否有更高優(yōu)先級的任務(wù)進(jìn)入就緒態(tài)然后保存當(dāng)前任務(wù)上下文切換到下一個(gè)任務(wù)。裸機(jī)里的定時(shí)器模擬任務(wù)少了上下文切換保存恢復(fù)這一層任務(wù)之間是通過函數(shù)調(diào)用完成的但仍然包含了三個(gè)核心抽象系統(tǒng)時(shí)基周期中斷維護(hù)的 tick 計(jì)數(shù)。任務(wù)控制塊記錄每個(gè)任務(wù)的函數(shù)指針、周期和狀態(tài)。調(diào)度邏輯根據(jù)時(shí)間差決定當(dāng)前該運(yùn)行哪個(gè)任務(wù)。下面用一張表對比三種常見方案便于理解定位項(xiàng)目超級大循環(huán)定時(shí)器模擬任務(wù)FreeRTOS時(shí)基來源無統(tǒng)一時(shí)基依賴延時(shí)函數(shù)定時(shí)器中斷滴答定時(shí)器任務(wù)切換方式順序執(zhí)行周期輪詢調(diào)度高優(yōu)先級搶占或時(shí)間片輪轉(zhuǎn)任務(wù)阻塞影響全系統(tǒng)卡住只影響當(dāng)前周期當(dāng)前任務(wù)阻塞其他任務(wù)繼續(xù)上下文保存無無寄存器現(xiàn)場保存與恢復(fù)適用場景功能少、邏輯簡單裸機(jī)中等復(fù)雜度項(xiàng)目多任務(wù)、強(qiáng)實(shí)時(shí)、復(fù)雜交互從這張表可以看出定時(shí)器模擬任務(wù)并不是一個(gè)最終方案而是一個(gè)理解 RTOS 調(diào)度機(jī)制的中間臺階。把裸機(jī)調(diào)度器寫明白之后再去看 FreeRTOS 的任務(wù)切換流程會容易得多。2. 實(shí)驗(yàn)環(huán)境與定時(shí)器選型先準(zhǔn)備好硬件和時(shí)基2.1 硬件平臺與軟件工具這套調(diào)度器實(shí)現(xiàn)依賴一個(gè)周期中斷以及一個(gè)能夠輸出 printf 串口信息的調(diào)試環(huán)境。這里以最常見的 STM32F103C8T6 為例因?yàn)樗?SysTick 定時(shí)器是 Cortex-M 內(nèi)核自帶的配置簡單不占用外部外設(shè)。項(xiàng)目推薦選擇說明主控芯片STM32F103C8T6基于 Cortex-M3支持 SysTick定時(shí)器SysTick內(nèi)核定時(shí)器不必依賴外部 TIM 資源開發(fā)環(huán)境STM32CubeIDE 或 Keil MDK兩者都可以在線調(diào)試驅(qū)動庫HAL 庫或標(biāo)準(zhǔn)庫不影響調(diào)度器核心邏輯輔助工具串口助手、邏輯分析儀用于觀察任務(wù)執(zhí)行周期如果手頭沒有 STM32也可以用其他帶 SysTick 的 Cortex-M 芯片或者用 51 單片機(jī)的外部定時(shí)器。核心思想是一樣的只是寄存器操作不同。2.2 選擇 SysTick 還是通用定時(shí)器SysTick 是 ARM Cortex-M 內(nèi)核自帶的一個(gè) 24 位遞減計(jì)數(shù)器它不占用 TIM2、TIM3 這類通用定時(shí)器資源。很多項(xiàng)目會把通用定時(shí)器留給 PWM 輸出、輸入捕獲、編碼器計(jì)數(shù)等硬件功能因此用 SysTick 做系統(tǒng)時(shí)基是更合理的選擇。使用 HAL 庫時(shí)要注意HAL_Init()默認(rèn)會配置 SysTick 工作為 1ms 時(shí)基并提供HAL_Delay()延時(shí)函數(shù)。如果自己也要用 SysTick 做調(diào)度時(shí)基存在兩種做法直接復(fù)用 HAL 的 1ms 時(shí)基在SysTick_Handler里同時(shí)調(diào)用HAL_IncTick()和自己維護(hù)的g_tick_ms。完全脫離 HAL 的 SysTick 管理改用 TIM2 或者普通定時(shí)器做調(diào)度時(shí)基。第一種做法代碼更少適合快速跑通。第二種做法與 HAL 解耦適合以后遷移到其他芯片。下面示例以第一種做法為主因?yàn)樗鼙M快驗(yàn)證調(diào)度器邏輯。2.3 時(shí)基頻率和重載值的計(jì)算方法定時(shí)器模擬任務(wù)需要先確定一個(gè)基準(zhǔn) tick 周期。常見的選擇是 1ms因?yàn)榇蠖鄶?shù)裸機(jī)任務(wù)的周期都是 5ms、10ms、100ms、500ms 這類整數(shù)倍。如果任務(wù)周期要求到微秒級1ms 時(shí)基就不夠用但那屬于更高精度的實(shí)時(shí)控制范疇調(diào)度器設(shè)計(jì)的思路需要另外調(diào)整。SysTick 的配置關(guān)鍵在于重載值計(jì)算。SysTick 是一個(gè)向下計(jì)數(shù)的定時(shí)器從重載值遞減到 0然后產(chǎn)生中斷并自動重新加載。重載值公式為重載值 SysTick 時(shí)鐘頻率 / 期望中斷頻率 - 1以 STM32F103C8T6 在 HCLK 72MHz 為例SysTick 輸入時(shí)鐘如果按 HCLK 計(jì)算 重載值 72,000,000 / 1000 - 1 71,999得到 1ms 中斷一次的結(jié)果。使用 HAL 庫時(shí)HAL_InitTick(PRIORITY)已經(jīng)按類似方式配置好可以不再手動配置。但理解這個(gè)計(jì)算過程仍然重要因?yàn)閾Q到不同主頻的芯片時(shí)錯(cuò)誤的重載值會導(dǎo)致 tick 周期變成幾毫秒甚至幾十毫秒而調(diào)度器表面的周期參數(shù)并不會告訴你真相只能通過串口或示波器觀察。3. 手寫一個(gè)輕量任務(wù)調(diào)度器從定義任務(wù)表開始3.1 任務(wù)控制塊描述一個(gè)任務(wù)需要哪些信息要讓定時(shí)器模擬多個(gè)任務(wù)第一步是定義任務(wù)控制塊。一個(gè)任務(wù)需要記錄四個(gè)信息任務(wù)函數(shù)指針、執(zhí)行周期、上次運(yùn)行時(shí)間、是否啟用。#define TASK_MAX_NUM 8 typedef struct { void (*p_task_func)(void); uint32_t period_ms; uint32_t last_run_ms; uint8_t enabled; } task_ctrl_t; static task_ctrl_t g_task_table[TASK_MAX_NUM]; static volatile uint32_t g_tick_ms 0;這里p_task_func是任務(wù)函數(shù)入口period_ms是任務(wù)的周期last_run_ms記錄上一次執(zhí)行時(shí)的 tick 值enabled控制任務(wù)是否參與調(diào)度。任務(wù)表用靜態(tài)數(shù)組保存初始化為全空。g_tick_ms必須加volatile因?yàn)樗鼤谥袛嗬锉恍薷闹餮h(huán)里被讀取。如果不加volatile編譯器可能把變量優(yōu)化到寄存器中導(dǎo)致判斷條件看不到中斷里的更新。初始化函數(shù)也在這里補(bǔ)上void scheduler_init(void) { for (uint8_t i 0; i TASK_MAX_NUM; i) { g_task_table[i].p_task_func NULL; g_task_table[i].period_ms 0; g_task_table[i].last_run_ms 0; g_task_table[i].enabled 0; } g_tick_ms 0; }初始化時(shí)把函數(shù)指針清空用p_task_func NULL表示該槽位可以注冊新任務(wù)。這里不用單獨(dú)的“空閑”標(biāo)志是為了簡化結(jié)構(gòu)體。3.2 系統(tǒng)時(shí)基在定時(shí)器中斷里維護(hù)全局 tickSysTick 中斷是調(diào)度器的唯一時(shí)間來源。中斷處理函數(shù)里只做一件事累加g_tick_ms。不要在中斷里直接調(diào)用任務(wù)函數(shù)這是一個(gè)非常重要的邊界。void SysTick_Handler(void) { HAL_IncTick(); // HAL 庫自身的 tick維持 HAL_Delay 工作 g_tick_ms; }如果工程不使用 HAL 庫可以把第一行去掉只保留g_tick_ms。這么做的原則是中斷處理函數(shù)必須短小精悍盡量只做標(biāo)志記錄、計(jì)數(shù)累加這類微秒級操作。把任務(wù)函數(shù)放進(jìn)中斷里會讓中斷占用時(shí)間變長還可能因?yàn)楣蚕碜兞吭L問造成不可預(yù)知的問題。3.3 調(diào)度主循環(huán)用差值進(jìn)行周期判定調(diào)度器的主循環(huán)是整個(gè)任務(wù)調(diào)度的核心。它不斷掃描任務(wù)表判斷每個(gè)任務(wù)是否到達(dá)執(zhí)行時(shí)刻到達(dá)則調(diào)用任務(wù)函數(shù)。void scheduler_run(void) { while (1) { for (uint8_t i 0; i TASK_MAX_NUM; i) { if (g_task_table[i].enabled 0) { continue; } if (g_task_table[i].p_task_func NULL) { continue; } if ((uint32_t)(g_tick_ms - g_task_table[i].last_run_ms) g_task_table[i].period_ms) { g_task_table[i].last_run_ms g_tick_ms; g_task_table[i].p_task_func(); } } } }這里的核心是(uint32_t)(g_tick_ms - g_task_table[i].last_run_ms) g_task_table[i].period_ms。使用差值而不是絕對值比較可以避免g_tick_ms從 0xFFFFFFFF 回繞到 0 時(shí)判斷出錯(cuò)。假設(shè)g_tick_ms翻轉(zhuǎn)只要兩個(gè)值都是uint32_t差值計(jì)算仍然能得到正確的時(shí)間間隔。主循環(huán)看起來還是超級大循環(huán)但運(yùn)行邏輯已經(jīng)不一樣。它不是在順序執(zhí)行所有功能而是讓每個(gè)任務(wù)按照自己的周期被調(diào)度。任務(wù)函數(shù)內(nèi)部的while(1)循環(huán)應(yīng)當(dāng)拆解成單次執(zhí)行邏輯跑完就返回等待下一次調(diào)度。3.4 任務(wù)注冊與主程序整合新增任務(wù)的接口如下uint8_t scheduler_add_task(void (*p_func)(void), uint32_t period_ms) { for (uint8_t i 0; i TASK_MAX_NUM; i) { if (g_task_table[i].p_task_func NULL) { g_task_table[i].p_task_func p_func; g_task_table[i].period_ms period_ms; g_task_table[i].last_run_ms g_tick_ms; g_task_table[i].enabled 1; return 1; } } return 0; }注冊成功后返回 1任務(wù)表已滿時(shí)返回 0。這樣在上層可以打印注冊失敗信息避免函數(shù)指針為 NULL 的任務(wù)被注冊后引發(fā)問題。主程序整合示例如下int main(void) { HAL_Init(); SystemClock_Config(); MX_USART1_UART_Init(); scheduler_init(); scheduler_add_task(task_led_toggle, 500); scheduler_add_task(task_key_scan, 10); scheduler_run(); }task_led_toggle是一個(gè) 500ms 周期的 LED 翻轉(zhuǎn)任務(wù)task_key_scan是一個(gè) 10ms 周期的按鍵掃描任務(wù)。兩個(gè)任務(wù)互不阻塞各自按周期運(yùn)行。如果之后要增加一個(gè) 100ms 的傳感器讀取任務(wù)只需要再寫一個(gè)任務(wù)函數(shù)并調(diào)用一次scheduler_add_task。4. 深入關(guān)鍵實(shí)現(xiàn)細(xì)節(jié)中斷、阻塞、臨界區(qū)與狀態(tài)機(jī)4.1 中斷里只做標(biāo)記任務(wù)交給主循環(huán)裸機(jī)調(diào)度器最容易踩的坑是寫代碼時(shí)覺得“在中斷里執(zhí)行任務(wù)更實(shí)時(shí)”于是在定時(shí)器中斷里直接調(diào)用任務(wù)函數(shù)。初看好像沒問題但系統(tǒng)復(fù)雜度一上去問題就暴露出來。一方面中斷里執(zhí)行耗時(shí)任務(wù)會阻塞其他中斷響應(yīng)尤其是串口、外部中斷這類實(shí)時(shí)性要求較高的中斷。另一方面中斷環(huán)境下的執(zhí)行時(shí)機(jī)不可控如果兩個(gè)中斷同時(shí)打過來嵌套優(yōu)先級不能精確控制時(shí)程序的執(zhí)行順序會變得不確定。推薦做法是中斷里修改標(biāo)志位或計(jì)數(shù)。主循環(huán)里檢查標(biāo)志位并執(zhí)行任務(wù)。緊急任務(wù)使用專門的高優(yōu)先級外部中斷而不是把所有事情都放在定時(shí)器中斷里。這樣寫出來的程序中斷響應(yīng)時(shí)間和任務(wù)執(zhí)行時(shí)間可以分開評估。定時(shí)器中斷占用時(shí)間可以保持在幾微秒以內(nèi)任務(wù)執(zhí)行時(shí)間則由主循環(huán)統(tǒng)籌。4.2 周期判斷為什么用差值而不要比較絕對值新手寫調(diào)度器時(shí)最容易寫成下面的形式if (g_tick_ms task_table[i].last_run_ms task_table[i].period_ms)這種寫法在g_tick_ms很小的時(shí)候沒有問題但last_run_ms period_ms一旦超過 0xFFFFFFFF就會發(fā)生無符號整數(shù)溢出結(jié)果變成一個(gè)很小的數(shù)導(dǎo)致條件永遠(yuǎn)不成立任務(wù)停止調(diào)度。解決方法是使用差值的寫法if ((uint32_t)(g_tick_ms - task_table[i].last_run_ms) task_table[i].period_ms)g_tick_ms - last_run_ms本身就是兩個(gè)uint32_t的差值符合 C 語言的無符號整數(shù)回繞規(guī)則。只要兩個(gè)數(shù)之間的真實(shí)間隔不超過 2 的 32 次方毫秒即大約 49.7 天這個(gè)判斷都是正確的。對于大多數(shù)嵌入式設(shè)備正常運(yùn)行時(shí)間不會超過這個(gè)值但寫成差值比較更穩(wěn)妥也更接近 RTOS 內(nèi)部的時(shí)間判斷思路。4.3 任務(wù)函數(shù)必須避免阻塞必要時(shí)用狀態(tài)機(jī)改寫調(diào)度器只解決了“何時(shí)啟動任務(wù)”的問題并沒有解決“任務(wù)運(yùn)行多久”的問題。如果任務(wù)函數(shù)內(nèi)部使用HAL_Delay(100)或一個(gè)超時(shí)循環(huán)等待那么這次運(yùn)行會占用 100ms其他所有任務(wù)都要等待這么長時(shí)間。這就是部分項(xiàng)目把超級大循環(huán)改造成定時(shí)器調(diào)度之后實(shí)際效果依然不好的原因任務(wù)本身的阻塞沒有消除只是從代碼結(jié)構(gòu)上看變成了多任務(wù)。解決阻塞問題最有效的方法是狀態(tài)機(jī)。一個(gè)任務(wù)看似復(fù)雜其實(shí)通常可以拆分成幾步每步只需幾毫秒甚至幾微秒。任務(wù)函數(shù)每次被調(diào)度時(shí)推進(jìn)一個(gè)狀態(tài)而不是從頭到尾執(zhí)行完整流程。以按鍵防抖為例阻塞寫法是void key_scan(void) { if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) 0) { HAL_Delay(20); if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) 0) { // 按鍵確認(rèn) } } }這里HAL_Delay(20)在key_scan內(nèi)部阻塞 20ms影響所有其他任務(wù)。狀態(tài)機(jī)寫法如下typedef enum { KEY_IDLE, KEY_CHECK, KEY_CONFIRM } key_fsm_t; static key_fsm_t g_key_fsm KEY_IDLE; static uint32_t g_key_start_ms 0; void task_key_scan_fsm(void) { switch (g_key_fsm) { case KEY_IDLE: if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) 0) { g_key_start_ms g_tick_ms; g_key_fsm KEY_CHECK; } break; case KEY_CHECK: if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) ! 0) { g_key_fsm KEY_IDLE; } else if ((uint32_t)(g_tick_ms - g_key_start_ms) 20) { g_key_fsm KEY_CONFIRM; } break; case KEY_CONFIRM: // 執(zhí)行按鍵業(yè)務(wù)邏輯 g_key_fsm KEY_IDLE; break; default: g_key_fsm KEY_IDLE; break; } }這個(gè)任務(wù)每個(gè)周期只執(zhí)行一次 switch 判斷不阻塞也不等待。防抖時(shí)間由g_key_start_ms和當(dāng)前g_tick_ms的差值來判斷。實(shí)踐里凡是遇到任務(wù)內(nèi)部出現(xiàn)while(條件)、HAL_Delay、超時(shí)等待都值得改成狀態(tài)機(jī)或其他非阻塞寫法。4.4 共享數(shù)據(jù)的臨界區(qū)保護(hù)調(diào)度器里的任務(wù)表通常只在啟動階段注冊運(yùn)行過程中很少修改。但如果業(yè)務(wù)代碼需要在運(yùn)行期間動態(tài)啟停任務(wù)修改enabled字段時(shí)就要小心。g_task_table會被主循環(huán)里的scheduler_run()讀取如果某個(gè)低優(yōu)先級中斷或回調(diào)里也修改任務(wù)表可能產(chǎn)生競爭條件。簡單的保護(hù)方式是在修改任務(wù)表時(shí)關(guān)閉中斷修改完再打開__disable_irq(); g_task_table[0].enabled 0; __enable_irq();__disable_irq()和__enable_irq()是 CMSIS 提供的全局中斷開關(guān)函數(shù)適用于裸機(jī)工程。關(guān)閉中斷的時(shí)間必須極短只保護(hù)關(guān)鍵賦值語句不能在保護(hù)區(qū)內(nèi)調(diào)用耗時(shí)函數(shù)。更細(xì)的臨界區(qū)保護(hù)還可以使用PRIMASK的操作或BASEPRI的優(yōu)先級屏蔽方式裸機(jī)工程里先用全局開關(guān)最直觀。需要注意的是如果工程同時(shí)使用斷言、打印函數(shù)不要在關(guān)中斷狀態(tài)下調(diào)用 printf因?yàn)?UART 發(fā)送等待會拉長關(guān)中斷時(shí)間。5. 運(yùn)行驗(yàn)證與常見問題排查5.1 用串口打印或 GPIO 波形驗(yàn)證調(diào)度是否正確調(diào)度器寫完不能只看程序有沒有報(bào)錯(cuò)還要確認(rèn)每個(gè)任務(wù)的執(zhí)行周期真實(shí)符合預(yù)期。最直接的辦法是在任務(wù)函數(shù)里打印 tick 時(shí)間戳。void task_led_toggle(void) { printf(led toggle at %lu ms\r\n, (unsigned long)g_tick_ms); }串口輸出如果穩(wěn)定出現(xiàn) 500ms 的間隔說明調(diào)度周期正確。如果間隔一會兒 500ms一會兒 800ms說明任務(wù)內(nèi)部有阻塞或者有高優(yōu)先級中斷長時(shí)間打斷主循環(huán)。另一種辦法是讓任務(wù)函數(shù)翻轉(zhuǎn)一個(gè) GPIOvoid task_led_toggle(void) { HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); }用邏輯分析儀或示波器測量該引腳電平變化周期。如果兩個(gè)上升沿之間是 1000ms說明 500ms 周期任務(wù)正確。這個(gè)方法比串口更準(zhǔn)確因?yàn)樗灰蕾嚧诎l(fā)送耗時(shí)也不會被 printf 阻塞影響。5.2 常見工程問題與排查對照表問題現(xiàn)象可能原因檢查方式解決方案任務(wù)周期明顯偏大任務(wù)函數(shù)內(nèi)部有阻塞延時(shí)在任務(wù)前后打印 tick 差值用狀態(tài)機(jī)內(nèi)部計(jì)時(shí)替代阻塞某個(gè)任務(wù)一直不執(zhí)行enabled未置 1 或函數(shù)指針為空檢查注冊返回值確認(rèn)scheduler_add_task返回 1加入新任務(wù)后老任務(wù)亂套任務(wù)表槽位沖突或數(shù)組越界檢查TASK_MAX_NUM和注冊函數(shù)增大任務(wù)表容量檢查是否越界寫調(diào)度器優(yōu)化后不運(yùn)行g(shù)_tick_ms沒加 volatile查看匯編或關(guān)閉優(yōu)化對比給全局共享變量加 volatile使用 HAL_Delay 后程序卡死HAL_Delay 依賴 SysTick而 SysTick 被高優(yōu)先級中斷搶占或關(guān)閉檢查中斷優(yōu)先級配置和全局中斷開關(guān)不要在關(guān)中斷中調(diào)用 HAL_Delay串口打印亂碼波特率不匹配或時(shí)鐘配置錯(cuò)誤檢查 UART 初始化、時(shí)鐘樹重新配置系統(tǒng)時(shí)鐘和串口參數(shù)5.3 一套可復(fù)用的排查順序遇到任務(wù)調(diào)度不符合預(yù)期時(shí)按以下順序排查可以快速縮小范圍確認(rèn)定時(shí)器中斷有沒有觸發(fā)。在SysTick_Handler里打斷點(diǎn)或者翻轉(zhuǎn)一個(gè)調(diào)試 GPIO。確認(rèn)g_tick_ms在持續(xù)增長。串口打印一次該值隔一秒再看。確認(rèn)任務(wù)注冊是否成功。檢查scheduler_add_task返回值排除任務(wù)表已滿。確認(rèn)任務(wù)表的enabled是否為 1函數(shù)指針是否為 NULL。確認(rèn)周期判斷條件是否使用了差值寫法而不是絕對值相加寫法。確認(rèn)任務(wù)函數(shù)是否能正常返回。任務(wù)函數(shù)如果陷入死循環(huán)調(diào)度主循環(huán)自然無法繼續(xù)。最后檢查中斷優(yōu)先級。如果 SysTick 優(yōu)先級被設(shè)得很高而某外設(shè)中斷持有一個(gè)長時(shí)間的臨界區(qū)就可能導(dǎo)致系統(tǒng)時(shí)基被延遲。這套順序適合大部分裸機(jī)調(diào)度器問題。核心思路是先從“時(shí)間有沒有走”開始再檢查“任務(wù)有沒有被掃描到”最后再看“任務(wù)執(zhí)行完沒有”。6. 從裸機(jī)調(diào)度器到 FreeRTOS架構(gòu)演進(jìn)的下一步6.1 定時(shí)器模擬任務(wù)與 RTOS 的本質(zhì)區(qū)別定時(shí)器模擬任務(wù)已經(jīng)具備任務(wù)、時(shí)基、周期調(diào)度的雛形但它和 FreeRTOS 仍然有本質(zhì)區(qū)別。裸機(jī)調(diào)度器沒有任務(wù)上下文切換任務(wù)之間通過函數(shù)調(diào)用完成當(dāng)前任務(wù)運(yùn)行完成后才能輪到下一個(gè)任務(wù)。FreeRTOS 則在 tick 中斷里保存當(dāng)前任務(wù)的寄存器現(xiàn)場再從就緒任務(wù)表里找到最高優(yōu)先級任務(wù)恢復(fù)它的現(xiàn)場并跳轉(zhuǎn)執(zhí)行。FreeRTOS 的任務(wù)切換完整流程大致是滴答定時(shí)器觸發(fā)中斷進(jìn)入xPortSysTickHandler保存當(dāng)前任務(wù)棧指針和寄存器然后調(diào)用vTaskSwitchContext查找下一個(gè)就緒任務(wù)最后恢復(fù)新任務(wù)上下文并退出中斷。這套機(jī)制使得一個(gè)任務(wù)即使被阻塞操作系統(tǒng)也能立馬切換到其他任務(wù)而不是像裸機(jī)調(diào)度器那樣必須等任務(wù)函數(shù)返回。理解這個(gè)區(qū)別很重要。定時(shí)器模擬任務(wù)更接近“協(xié)作式調(diào)度”每個(gè)任務(wù)必須主動讓出 CPU 控制權(quán)。RTOS 是“搶占式調(diào)度”高優(yōu)先級任務(wù)可以打斷低優(yōu)先級任務(wù)。6.2 何時(shí)應(yīng)該遷移到 RTOS定時(shí)器模擬任務(wù)適合任務(wù)數(shù)量穩(wěn)定、執(zhí)行時(shí)間相對固定、不需要復(fù)雜同步機(jī)制的裸機(jī)項(xiàng)目。當(dāng)項(xiàng)目出現(xiàn)下面這些跡象時(shí)就可以認(rèn)真考慮引入 FreeRTOS多個(gè)任務(wù)需要同時(shí)等待不同的事件例如等待串口發(fā)送完成等待按鍵釋放等待傳感器就緒。任務(wù)之間需要傳遞數(shù)據(jù)用全局變量已經(jīng)很難維護(hù)。某個(gè)任務(wù)執(zhí)行時(shí)間不均最壞情況下會影響其他任務(wù)周期。需要互斥量、信號量、消息隊(duì)列這類同步原語而不是自己手工實(shí)現(xiàn)臨界區(qū)。遷移 RTOS 并不意味把原來的裸機(jī)代碼推倒重寫。任務(wù)函數(shù)思想可以保留只是把void task_led_toggle(void)改成帶無限循環(huán)的任務(wù)函數(shù)并使用vTaskDelay或任務(wù)通知替代周期判斷。6.3 遷移時(shí)可以保留的設(shè)計(jì)與需要新增的機(jī)制定時(shí)器模擬任務(wù)里的以下幾點(diǎn)遷移到 RTOS 后依然有效任務(wù)劃分粒度。按鍵掃描、顯示刷新、協(xié)議解析拆分成獨(dú)立任務(wù)這個(gè)劃分思路直接可用。狀態(tài)機(jī)編程方法。狀態(tài)機(jī)在裸機(jī)和 RTOS 里都是消除阻塞的通用手段。周期任務(wù)思想。RTOS 中可以用軟件定時(shí)器或vTaskDelayUntil實(shí)現(xiàn)類似效果。需要新增的機(jī)制主要是同步和通信。裸機(jī)共享變量可以繼續(xù)用但更好的是加入隊(duì)列或信號量讓任務(wù)之間通過消息交互。例如按鍵任務(wù)檢測到按下后不再直接設(shè)置某個(gè)全局標(biāo)志而是向隊(duì)列發(fā)送一個(gè)按鍵事件顯示任務(wù)接收后更新界面。這樣數(shù)據(jù)流更清晰也方便以后擴(kuò)展多個(gè)任務(wù)同時(shí)消費(fèi)事件。6.4 生產(chǎn)環(huán)境中的額外保障無論使用裸機(jī)調(diào)度器還是 RTOS進(jìn)入生產(chǎn)環(huán)境前都要額外關(guān)注幾點(diǎn)。第一點(diǎn)是看門狗。調(diào)度主循環(huán)崩潰時(shí)定時(shí)器中斷可能還在跑tick 繼續(xù)增長程序看起來像活著。建議獨(dú)立監(jiān)控一個(gè)低頻任務(wù)看它是否能按周期翻轉(zhuǎn)“喂狗標(biāo)志”不能則復(fù)位系統(tǒng)。第二點(diǎn)是日志開關(guān)。調(diào)試階段的printf指令在生產(chǎn)環(huán)境要考慮是否保留保留時(shí)建議用宏控制#define LOG_ENABLE 1 #if LOG_ENABLE #define LOG_INFO(fmt, ...) printf(fmt, ##__VA_ARGS__) #else #define LOG_INFO(fmt, ...) #endif第三點(diǎn)是系統(tǒng)時(shí)基穩(wěn)定性。SysTick 是內(nèi)核定時(shí)器但如果某段代碼長時(shí)間關(guān)中斷SysTick 中斷會被延遲時(shí)基就不準(zhǔn)。任何臨界區(qū)都要控制執(zhí)行時(shí)間。第四點(diǎn)是任務(wù)表越界保護(hù)。公開接口內(nèi)部要做參數(shù)檢查和數(shù)組索引檢查避免函數(shù)指針數(shù)組越界寫導(dǎo)致程序跑飛。定時(shí)器模擬任務(wù)是嵌入式軟件設(shè)計(jì)架構(gòu)里一個(gè)承上啟下的概念。它沒有 RTOS 那樣復(fù)雜的調(diào)度算法卻能讓人真正理解“任務(wù)”“時(shí)基”“周期調(diào)度”是怎么一回事。建議先在一個(gè)最小開發(fā)板上把調(diào)度器跑通觀察不同任務(wù)周期的輸出再把阻塞任務(wù)改造成狀態(tài)機(jī)最后對比 RTOS 的調(diào)度機(jī)制。這一套走下來再回頭看 FreeRTOS 源碼里的任務(wù)切換流程會順暢得多。 STM32裸機(jī)定時(shí)器模擬任務(wù)：手寫輕量級任務(wù)調(diào)度器
在實(shí)際的嵌入式項(xiàng)目里任務(wù)調(diào)度并不是引入 RTOS 之后才需要考慮的問題。很多基于 STM32、51、Arduino 的裸機(jī)項(xiàng)目代碼一開始是從流水燈開始的等按鍵、傳感器、顯示、通信模塊都加進(jìn)來之后main 函數(shù)里通常會變成一個(gè)巨大的 while(1) 循環(huán)各種功能按固定順序輪流執(zhí)行。表面上看每個(gè)功能都能跑但某個(gè)函數(shù)內(nèi)部一旦加了一段延時(shí)或等待整個(gè)系統(tǒng)的實(shí)時(shí)性就會明顯下降。這時(shí)定時(shí)器模擬任務(wù)就成為一種非常實(shí)用的裸機(jī)架構(gòu)升級手段用定時(shí)器中斷產(chǎn)生統(tǒng)一時(shí)基把大循環(huán)拆成多個(gè)可獨(dú)立調(diào)度的周期任務(wù)讓程序具備接近時(shí)間片輪轉(zhuǎn)的調(diào)度效果。這篇文章會從超級大循環(huán)的代碼缺陷講起解釋定時(shí)器模擬任務(wù)的基本概念再給出一個(gè)可以在 STM32 上直接運(yùn)行的輕量任務(wù)調(diào)度器實(shí)現(xiàn)。代碼不依賴 RTOS卻可以復(fù)現(xiàn) FreeRTOS 里最重要的周期性任務(wù)調(diào)度思路適合想理解嵌入式調(diào)度原理、準(zhǔn)備嵌入式面試、或者想把裸機(jī)項(xiàng)目改造成更規(guī)范架構(gòu)的開發(fā)者。1. 定時(shí)器模擬任務(wù)概念從超級大循環(huán)到事件驅(qū)動架構(gòu)1.1 超級大循環(huán)能用但會逐漸失控的程序結(jié)構(gòu)裸機(jī)項(xiàng)目最常見的代碼結(jié)構(gòu)是超級大循環(huán)也叫前后臺系統(tǒng)中的后臺部分。前臺是中斷后臺就是 main 函數(shù)里的一個(gè)死循環(huán)。典型的寫法是把按鍵掃描、傳感器讀取、屏幕刷新、協(xié)議解析全部放在同一個(gè) while(1) 中int main(void) { while (1) { key_scan(); sensor_read(); display_update(); protocol_process(); } }這種結(jié)構(gòu)在功能很少時(shí)非常直觀代碼從上往下執(zhí)行邏輯清楚。但問題會隨著功能增加而暴露出來。假設(shè)sensor_read()里使用阻塞延時(shí)等待傳感器轉(zhuǎn)換完成比如讀取一個(gè)需要 10ms 才能穩(wěn)定的 ADC 采樣結(jié)果那么這 10ms 內(nèi)key_scan()和display_update()都在等待。用戶按下的按鍵不會立即響應(yīng)屏幕刷新也會卡頓。更嚴(yán)重的是如果某個(gè)通信函數(shù)使用超時(shí)循環(huán)等待應(yīng)答而這個(gè)超時(shí)時(shí)間寫得比較長整個(gè)系統(tǒng)的反應(yīng)速度會被拉得很差。超級大循環(huán)的缺點(diǎn)可以歸結(jié)為三點(diǎn)實(shí)時(shí)性差。一個(gè)任務(wù)的阻塞會拖累所有后續(xù)任務(wù)。擴(kuò)展性差。新增一個(gè)功能就要插入循環(huán)某處還要小心會不會影響現(xiàn)有任務(wù)的執(zhí)行周期。時(shí)序不可控。每個(gè)功能的執(zhí)行頻率完全取決于循環(huán)整體運(yùn)行時(shí)間無法保證固定周期。所以當(dāng)項(xiàng)目里出現(xiàn)“某個(gè)任務(wù)稍微延遲幾毫秒系統(tǒng)表現(xiàn)就異常”的情況時(shí)需要的就是一種能把“任務(wù)”和“時(shí)間”解耦的架構(gòu)。1.2 定時(shí)器如何把大循環(huán)改造成多任務(wù)結(jié)構(gòu)要解決阻塞問題最直接的辦法是引入定時(shí)器。定時(shí)器產(chǎn)生固定頻率的中斷比如每 1ms 中斷一次。每次中斷時(shí)一個(gè)全局計(jì)數(shù)變量加一。主循環(huán)里不再按固定順序盲目執(zhí)行所有函數(shù)而是根據(jù)當(dāng)前計(jì)數(shù)判斷該執(zhí)行哪個(gè)任務(wù)。這種做法的本質(zhì)是把“時(shí)間”從“任務(wù)代碼”中抽出來用一個(gè)獨(dú)立時(shí)基驅(qū)動所有任務(wù)。每個(gè)任務(wù)不再自己用 delay 制造延時(shí)而是通過調(diào)度器判斷“現(xiàn)在是否到了該運(yùn)行的時(shí)刻”。這樣即使某個(gè)任務(wù)內(nèi)部有短暫阻塞其他任務(wù)也只會延遲最多一個(gè)任務(wù)周期的運(yùn)行時(shí)間而不是被整個(gè)阻塞住。從架構(gòu)角度看這種改動就實(shí)現(xiàn)了事件驅(qū)動定時(shí)器中斷產(chǎn)生周期事件也就是 tick。主循環(huán)根據(jù) tick 判斷事件類型并調(diào)用對應(yīng)處理函數(shù)。各任務(wù)從主動延時(shí)等待變成被動輪詢執(zhí)行。事件驅(qū)動架構(gòu)的最大收益是任務(wù)之間的耦合被大幅降低。按鍵掃描可以作為 10ms 周期任務(wù)運(yùn)行LED 閃爍可以作為 500ms 周期任務(wù)運(yùn)行傳感器數(shù)據(jù)解析可以作為 100ms 周期任務(wù)運(yùn)行它們互不修改對方的代碼。1.3 定時(shí)器模擬任務(wù)與 RTOS 任務(wù)調(diào)度的關(guān)系定時(shí)器模擬任務(wù)這個(gè)概念最容易被誤解成“用定時(shí)器做延時(shí)”。實(shí)際上它模擬的是 RTOS 最基本的調(diào)度機(jī)制按照時(shí)間片決定哪個(gè)任務(wù)運(yùn)行。FreeRTOS 這類系統(tǒng)也有一個(gè)滴答定時(shí)器也就是 SysTick用來產(chǎn)生系統(tǒng)時(shí)基。每次 tick 中斷時(shí)內(nèi)核檢查是否有更高優(yōu)先級的任務(wù)進(jìn)入就緒態(tài)然后保存當(dāng)前任務(wù)上下文切換到下一個(gè)任務(wù)。裸機(jī)里的定時(shí)器模擬任務(wù)少了上下文切換保存恢復(fù)這一層任務(wù)之間是通過函數(shù)調(diào)用完成的但仍然包含了三個(gè)核心抽象系統(tǒng)時(shí)基周期中斷維護(hù)的 tick 計(jì)數(shù)。任務(wù)控制塊記錄每個(gè)任務(wù)的函數(shù)指針、周期和狀態(tài)。調(diào)度邏輯根據(jù)時(shí)間差決定當(dāng)前該運(yùn)行哪個(gè)任務(wù)。下面用一張表對比三種常見方案便于理解定位項(xiàng)目超級大循環(huán)定時(shí)器模擬任務(wù)FreeRTOS時(shí)基來源無統(tǒng)一時(shí)基依賴延時(shí)函數(shù)定時(shí)器中斷滴答定時(shí)器任務(wù)切換方式順序執(zhí)行周期輪詢調(diào)度高優(yōu)先級搶占或時(shí)間片輪轉(zhuǎn)任務(wù)阻塞影響全系統(tǒng)卡住只影響當(dāng)前周期當(dāng)前任務(wù)阻塞其他任務(wù)繼續(xù)上下文保存無無寄存器現(xiàn)場保存與恢復(fù)適用場景功能少、邏輯簡單裸機(jī)中等復(fù)雜度項(xiàng)目多任務(wù)、強(qiáng)實(shí)時(shí)、復(fù)雜交互從這張表可以看出定時(shí)器模擬任務(wù)并不是一個(gè)最終方案而是一個(gè)理解 RTOS 調(diào)度機(jī)制的中間臺階。把裸機(jī)調(diào)度器寫明白之后再去看 FreeRTOS 的任務(wù)切換流程會容易得多。2. 實(shí)驗(yàn)環(huán)境與定時(shí)器選型先準(zhǔn)備好硬件和時(shí)基2.1 硬件平臺與軟件工具這套調(diào)度器實(shí)現(xiàn)依賴一個(gè)周期中斷以及一個(gè)能夠輸出 printf 串口信息的調(diào)試環(huán)境。這里以最常見的 STM32F103C8T6 為例因?yàn)樗?SysTick 定時(shí)器是 Cortex-M 內(nèi)核自帶的配置簡單不占用外部外設(shè)。項(xiàng)目推薦選擇說明主控芯片STM32F103C8T6基于 Cortex-M3支持 SysTick定時(shí)器SysTick內(nèi)核定時(shí)器不必依賴外部 TIM 資源開發(fā)環(huán)境STM32CubeIDE 或 Keil MDK兩者都可以在線調(diào)試驅(qū)動庫HAL 庫或標(biāo)準(zhǔn)庫不影響調(diào)度器核心邏輯輔助工具串口助手、邏輯分析儀用于觀察任務(wù)執(zhí)行周期如果手頭沒有 STM32也可以用其他帶 SysTick 的 Cortex-M 芯片或者用 51 單片機(jī)的外部定時(shí)器。核心思想是一樣的只是寄存器操作不同。2.2 選擇 SysTick 還是通用定時(shí)器SysTick 是 ARM Cortex-M 內(nèi)核自帶的一個(gè) 24 位遞減計(jì)數(shù)器它不占用 TIM2、TIM3 這類通用定時(shí)器資源。很多項(xiàng)目會把通用定時(shí)器留給 PWM 輸出、輸入捕獲、編碼器計(jì)數(shù)等硬件功能因此用 SysTick 做系統(tǒng)時(shí)基是更合理的選擇。使用 HAL 庫時(shí)要注意HAL_Init()默認(rèn)會配置 SysTick 工作為 1ms 時(shí)基并提供HAL_Delay()延時(shí)函數(shù)。如果自己也要用 SysTick 做調(diào)度時(shí)基存在兩種做法直接復(fù)用 HAL 的 1ms 時(shí)基在SysTick_Handler里同時(shí)調(diào)用HAL_IncTick()和自己維護(hù)的g_tick_ms。完全脫離 HAL 的 SysTick 管理改用 TIM2 或者普通定時(shí)器做調(diào)度時(shí)基。第一種做法代碼更少適合快速跑通。第二種做法與 HAL 解耦適合以后遷移到其他芯片。下面示例以第一種做法為主因?yàn)樗鼙M快驗(yàn)證調(diào)度器邏輯。2.3 時(shí)基頻率和重載值的計(jì)算方法定時(shí)器模擬任務(wù)需要先確定一個(gè)基準(zhǔn) tick 周期。常見的選擇是 1ms因?yàn)榇蠖鄶?shù)裸機(jī)任務(wù)的周期都是 5ms、10ms、100ms、500ms 這類整數(shù)倍。如果任務(wù)周期要求到微秒級1ms 時(shí)基就不夠用但那屬于更高精度的實(shí)時(shí)控制范疇調(diào)度器設(shè)計(jì)的思路需要另外調(diào)整。SysTick 的配置關(guān)鍵在于重載值計(jì)算。SysTick 是一個(gè)向下計(jì)數(shù)的定時(shí)器從重載值遞減到 0然后產(chǎn)生中斷并自動重新加載。重載值公式為重載值 SysTick 時(shí)鐘頻率 / 期望中斷頻率 - 1以 STM32F103C8T6 在 HCLK 72MHz 為例SysTick 輸入時(shí)鐘如果按 HCLK 計(jì)算 重載值 72,000,000 / 1000 - 1 71,999得到 1ms 中斷一次的結(jié)果。使用 HAL 庫時(shí)HAL_InitTick(PRIORITY)已經(jīng)按類似方式配置好可以不再手動配置。但理解這個(gè)計(jì)算過程仍然重要因?yàn)閾Q到不同主頻的芯片時(shí)錯(cuò)誤的重載值會導(dǎo)致 tick 周期變成幾毫秒甚至幾十毫秒而調(diào)度器表面的周期參數(shù)并不會告訴你真相只能通過串口或示波器觀察。3. 手寫一個(gè)輕量任務(wù)調(diào)度器從定義任務(wù)表開始3.1 任務(wù)控制塊描述一個(gè)任務(wù)需要哪些信息要讓定時(shí)器模擬多個(gè)任務(wù)第一步是定義任務(wù)控制塊。一個(gè)任務(wù)需要記錄四個(gè)信息任務(wù)函數(shù)指針、執(zhí)行周期、上次運(yùn)行時(shí)間、是否啟用。#define TASK_MAX_NUM 8 typedef struct { void (*p_task_func)(void); uint32_t period_ms; uint32_t last_run_ms; uint8_t enabled; } task_ctrl_t; static task_ctrl_t g_task_table[TASK_MAX_NUM]; static volatile uint32_t g_tick_ms 0;這里p_task_func是任務(wù)函數(shù)入口period_ms是任務(wù)的周期last_run_ms記錄上一次執(zhí)行時(shí)的 tick 值enabled控制任務(wù)是否參與調(diào)度。任務(wù)表用靜態(tài)數(shù)組保存初始化為全空。g_tick_ms必須加volatile因?yàn)樗鼤谥袛嗬锉恍薷闹餮h(huán)里被讀取。如果不加volatile編譯器可能把變量優(yōu)化到寄存器中導(dǎo)致判斷條件看不到中斷里的更新。初始化函數(shù)也在這里補(bǔ)上void scheduler_init(void) { for (uint8_t i 0; i TASK_MAX_NUM; i) { g_task_table[i].p_task_func NULL; g_task_table[i].period_ms 0; g_task_table[i].last_run_ms 0; g_task_table[i].enabled 0; } g_tick_ms 0; }初始化時(shí)把函數(shù)指針清空用p_task_func NULL表示該槽位可以注冊新任務(wù)。這里不用單獨(dú)的“空閑”標(biāo)志是為了簡化結(jié)構(gòu)體。3.2 系統(tǒng)時(shí)基在定時(shí)器中斷里維護(hù)全局 tickSysTick 中斷是調(diào)度器的唯一時(shí)間來源。中斷處理函數(shù)里只做一件事累加g_tick_ms。不要在中斷里直接調(diào)用任務(wù)函數(shù)這是一個(gè)非常重要的邊界。void SysTick_Handler(void) { HAL_IncTick(); // HAL 庫自身的 tick維持 HAL_Delay 工作 g_tick_ms; }如果工程不使用 HAL 庫可以把第一行去掉只保留g_tick_ms。這么做的原則是中斷處理函數(shù)必須短小精悍盡量只做標(biāo)志記錄、計(jì)數(shù)累加這類微秒級操作。把任務(wù)函數(shù)放進(jìn)中斷里會讓中斷占用時(shí)間變長還可能因?yàn)楣蚕碜兞吭L問造成不可預(yù)知的問題。3.3 調(diào)度主循環(huán)用差值進(jìn)行周期判定調(diào)度器的主循環(huán)是整個(gè)任務(wù)調(diào)度的核心。它不斷掃描任務(wù)表判斷每個(gè)任務(wù)是否到達(dá)執(zhí)行時(shí)刻到達(dá)則調(diào)用任務(wù)函數(shù)。void scheduler_run(void) { while (1) { for (uint8_t i 0; i TASK_MAX_NUM; i) { if (g_task_table[i].enabled 0) { continue; } if (g_task_table[i].p_task_func NULL) { continue; } if ((uint32_t)(g_tick_ms - g_task_table[i].last_run_ms) g_task_table[i].period_ms) { g_task_table[i].last_run_ms g_tick_ms; g_task_table[i].p_task_func(); } } } }這里的核心是(uint32_t)(g_tick_ms - g_task_table[i].last_run_ms) g_task_table[i].period_ms。使用差值而不是絕對值比較可以避免g_tick_ms從 0xFFFFFFFF 回繞到 0 時(shí)判斷出錯(cuò)。假設(shè)g_tick_ms翻轉(zhuǎn)只要兩個(gè)值都是uint32_t差值計(jì)算仍然能得到正確的時(shí)間間隔。主循環(huán)看起來還是超級大循環(huán)但運(yùn)行邏輯已經(jīng)不一樣。它不是在順序執(zhí)行所有功能而是讓每個(gè)任務(wù)按照自己的周期被調(diào)度。任務(wù)函數(shù)內(nèi)部的while(1)循環(huán)應(yīng)當(dāng)拆解成單次執(zhí)行邏輯跑完就返回等待下一次調(diào)度。3.4 任務(wù)注冊與主程序整合新增任務(wù)的接口如下uint8_t scheduler_add_task(void (*p_func)(void), uint32_t period_ms) { for (uint8_t i 0; i TASK_MAX_NUM; i) { if (g_task_table[i].p_task_func NULL) { g_task_table[i].p_task_func p_func; g_task_table[i].period_ms period_ms; g_task_table[i].last_run_ms g_tick_ms; g_task_table[i].enabled 1; return 1; } } return 0; }注冊成功后返回 1任務(wù)表已滿時(shí)返回 0。這樣在上層可以打印注冊失敗信息避免函數(shù)指針為 NULL 的任務(wù)被注冊后引發(fā)問題。主程序整合示例如下int main(void) { HAL_Init(); SystemClock_Config(); MX_USART1_UART_Init(); scheduler_init(); scheduler_add_task(task_led_toggle, 500); scheduler_add_task(task_key_scan, 10); scheduler_run(); }task_led_toggle是一個(gè) 500ms 周期的 LED 翻轉(zhuǎn)任務(wù)task_key_scan是一個(gè) 10ms 周期的按鍵掃描任務(wù)。兩個(gè)任務(wù)互不阻塞各自按周期運(yùn)行。如果之后要增加一個(gè) 100ms 的傳感器讀取任務(wù)只需要再寫一個(gè)任務(wù)函數(shù)并調(diào)用一次scheduler_add_task。4. 深入關(guān)鍵實(shí)現(xiàn)細(xì)節(jié)中斷、阻塞、臨界區(qū)與狀態(tài)機(jī)4.1 中斷里只做標(biāo)記任務(wù)交給主循環(huán)裸機(jī)調(diào)度器最容易踩的坑是寫代碼時(shí)覺得“在中斷里執(zhí)行任務(wù)更實(shí)時(shí)”于是在定時(shí)器中斷里直接調(diào)用任務(wù)函數(shù)。初看好像沒問題但系統(tǒng)復(fù)雜度一上去問題就暴露出來。一方面中斷里執(zhí)行耗時(shí)任務(wù)會阻塞其他中斷響應(yīng)尤其是串口、外部中斷這類實(shí)時(shí)性要求較高的中斷。另一方面中斷環(huán)境下的執(zhí)行時(shí)機(jī)不可控如果兩個(gè)中斷同時(shí)打過來嵌套優(yōu)先級不能精確控制時(shí)程序的執(zhí)行順序會變得不確定。推薦做法是中斷里修改標(biāo)志位或計(jì)數(shù)。主循環(huán)里檢查標(biāo)志位并執(zhí)行任務(wù)。緊急任務(wù)使用專門的高優(yōu)先級外部中斷而不是把所有事情都放在定時(shí)器中斷里。這樣寫出來的程序中斷響應(yīng)時(shí)間和任務(wù)執(zhí)行時(shí)間可以分開評估。定時(shí)器中斷占用時(shí)間可以保持在幾微秒以內(nèi)任務(wù)執(zhí)行時(shí)間則由主循環(huán)統(tǒng)籌。4.2 周期判斷為什么用差值而不要比較絕對值新手寫調(diào)度器時(shí)最容易寫成下面的形式if (g_tick_ms task_table[i].last_run_ms task_table[i].period_ms)這種寫法在g_tick_ms很小的時(shí)候沒有問題但last_run_ms period_ms一旦超過 0xFFFFFFFF就會發(fā)生無符號整數(shù)溢出結(jié)果變成一個(gè)很小的數(shù)導(dǎo)致條件永遠(yuǎn)不成立任務(wù)停止調(diào)度。解決方法是使用差值的寫法if ((uint32_t)(g_tick_ms - task_table[i].last_run_ms) task_table[i].period_ms)g_tick_ms - last_run_ms本身就是兩個(gè)uint32_t的差值符合 C 語言的無符號整數(shù)回繞規(guī)則。只要兩個(gè)數(shù)之間的真實(shí)間隔不超過 2 的 32 次方毫秒即大約 49.7 天這個(gè)判斷都是正確的。對于大多數(shù)嵌入式設(shè)備正常運(yùn)行時(shí)間不會超過這個(gè)值但寫成差值比較更穩(wěn)妥也更接近 RTOS 內(nèi)部的時(shí)間判斷思路。4.3 任務(wù)函數(shù)必須避免阻塞必要時(shí)用狀態(tài)機(jī)改寫調(diào)度器只解決了“何時(shí)啟動任務(wù)”的問題并沒有解決“任務(wù)運(yùn)行多久”的問題。如果任務(wù)函數(shù)內(nèi)部使用HAL_Delay(100)或一個(gè)超時(shí)循環(huán)等待那么這次運(yùn)行會占用 100ms其他所有任務(wù)都要等待這么長時(shí)間。這就是部分項(xiàng)目把超級大循環(huán)改造成定時(shí)器調(diào)度之后實(shí)際效果依然不好的原因任務(wù)本身的阻塞沒有消除只是從代碼結(jié)構(gòu)上看變成了多任務(wù)。解決阻塞問題最有效的方法是狀態(tài)機(jī)。一個(gè)任務(wù)看似復(fù)雜其實(shí)通常可以拆分成幾步每步只需幾毫秒甚至幾微秒。任務(wù)函數(shù)每次被調(diào)度時(shí)推進(jìn)一個(gè)狀態(tài)而不是從頭到尾執(zhí)行完整流程。以按鍵防抖為例阻塞寫法是void key_scan(void) { if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) 0) { HAL_Delay(20); if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) 0) { // 按鍵確認(rèn) } } }這里HAL_Delay(20)在key_scan內(nèi)部阻塞 20ms影響所有其他任務(wù)。狀態(tài)機(jī)寫法如下typedef enum { KEY_IDLE, KEY_CHECK, KEY_CONFIRM } key_fsm_t; static key_fsm_t g_key_fsm KEY_IDLE; static uint32_t g_key_start_ms 0; void task_key_scan_fsm(void) { switch (g_key_fsm) { case KEY_IDLE: if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) 0) { g_key_start_ms g_tick_ms; g_key_fsm KEY_CHECK; } break; case KEY_CHECK: if (HAL_GPIO_ReadPin(KEY_GPIO_Port, KEY_Pin) ! 0) { g_key_fsm KEY_IDLE; } else if ((uint32_t)(g_tick_ms - g_key_start_ms) 20) { g_key_fsm KEY_CONFIRM; } break; case KEY_CONFIRM: // 執(zhí)行按鍵業(yè)務(wù)邏輯 g_key_fsm KEY_IDLE; break; default: g_key_fsm KEY_IDLE; break; } }這個(gè)任務(wù)每個(gè)周期只執(zhí)行一次 switch 判斷不阻塞也不等待。防抖時(shí)間由g_key_start_ms和當(dāng)前g_tick_ms的差值來判斷。實(shí)踐里凡是遇到任務(wù)內(nèi)部出現(xiàn)while(條件)、HAL_Delay、超時(shí)等待都值得改成狀態(tài)機(jī)或其他非阻塞寫法。4.4 共享數(shù)據(jù)的臨界區(qū)保護(hù)調(diào)度器里的任務(wù)表通常只在啟動階段注冊運(yùn)行過程中很少修改。但如果業(yè)務(wù)代碼需要在運(yùn)行期間動態(tài)啟停任務(wù)修改enabled字段時(shí)就要小心。g_task_table會被主循環(huán)里的scheduler_run()讀取如果某個(gè)低優(yōu)先級中斷或回調(diào)里也修改任務(wù)表可能產(chǎn)生競爭條件。簡單的保護(hù)方式是在修改任務(wù)表時(shí)關(guān)閉中斷修改完再打開__disable_irq(); g_task_table[0].enabled 0; __enable_irq();__disable_irq()和__enable_irq()是 CMSIS 提供的全局中斷開關(guān)函數(shù)適用于裸機(jī)工程。關(guān)閉中斷的時(shí)間必須極短只保護(hù)關(guān)鍵賦值語句不能在保護(hù)區(qū)內(nèi)調(diào)用耗時(shí)函數(shù)。更細(xì)的臨界區(qū)保護(hù)還可以使用PRIMASK的操作或BASEPRI的優(yōu)先級屏蔽方式裸機(jī)工程里先用全局開關(guān)最直觀。需要注意的是如果工程同時(shí)使用斷言、打印函數(shù)不要在關(guān)中斷狀態(tài)下調(diào)用 printf因?yàn)?UART 發(fā)送等待會拉長關(guān)中斷時(shí)間。5. 運(yùn)行驗(yàn)證與常見問題排查5.1 用串口打印或 GPIO 波形驗(yàn)證調(diào)度是否正確調(diào)度器寫完不能只看程序有沒有報(bào)錯(cuò)還要確認(rèn)每個(gè)任務(wù)的執(zhí)行周期真實(shí)符合預(yù)期。最直接的辦法是在任務(wù)函數(shù)里打印 tick 時(shí)間戳。void task_led_toggle(void) { printf(led toggle at %lu ms\r\n, (unsigned long)g_tick_ms); }串口輸出如果穩(wěn)定出現(xiàn) 500ms 的間隔說明調(diào)度周期正確。如果間隔一會兒 500ms一會兒 800ms說明任務(wù)內(nèi)部有阻塞或者有高優(yōu)先級中斷長時(shí)間打斷主循環(huán)。另一種辦法是讓任務(wù)函數(shù)翻轉(zhuǎn)一個(gè) GPIOvoid task_led_toggle(void) { HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); }用邏輯分析儀或示波器測量該引腳電平變化周期。如果兩個(gè)上升沿之間是 1000ms說明 500ms 周期任務(wù)正確。這個(gè)方法比串口更準(zhǔn)確因?yàn)樗灰蕾嚧诎l(fā)送耗時(shí)也不會被 printf 阻塞影響。5.2 常見工程問題與排查對照表問題現(xiàn)象可能原因檢查方式解決方案任務(wù)周期明顯偏大任務(wù)函數(shù)內(nèi)部有阻塞延時(shí)在任務(wù)前后打印 tick 差值用狀態(tài)機(jī)內(nèi)部計(jì)時(shí)替代阻塞某個(gè)任務(wù)一直不執(zhí)行enabled未置 1 或函數(shù)指針為空檢查注冊返回值確認(rèn)scheduler_add_task返回 1加入新任務(wù)后老任務(wù)亂套任務(wù)表槽位沖突或數(shù)組越界檢查TASK_MAX_NUM和注冊函數(shù)增大任務(wù)表容量檢查是否越界寫調(diào)度器優(yōu)化后不運(yùn)行g(shù)_tick_ms沒加 volatile查看匯編或關(guān)閉優(yōu)化對比給全局共享變量加 volatile使用 HAL_Delay 后程序卡死HAL_Delay 依賴 SysTick而 SysTick 被高優(yōu)先級中斷搶占或關(guān)閉檢查中斷優(yōu)先級配置和全局中斷開關(guān)不要在關(guān)中斷中調(diào)用 HAL_Delay串口打印亂碼波特率不匹配或時(shí)鐘配置錯(cuò)誤檢查 UART 初始化、時(shí)鐘樹重新配置系統(tǒng)時(shí)鐘和串口參數(shù)5.3 一套可復(fù)用的排查順序遇到任務(wù)調(diào)度不符合預(yù)期時(shí)按以下順序排查可以快速縮小范圍確認(rèn)定時(shí)器中斷有沒有觸發(fā)。在SysTick_Handler里打斷點(diǎn)或者翻轉(zhuǎn)一個(gè)調(diào)試 GPIO。確認(rèn)g_tick_ms在持續(xù)增長。串口打印一次該值隔一秒再看。確認(rèn)任務(wù)注冊是否成功。檢查scheduler_add_task返回值排除任務(wù)表已滿。確認(rèn)任務(wù)表的enabled是否為 1函數(shù)指針是否為 NULL。確認(rèn)周期判斷條件是否使用了差值寫法而不是絕對值相加寫法。確認(rèn)任務(wù)函數(shù)是否能正常返回。任務(wù)函數(shù)如果陷入死循環(huán)調(diào)度主循環(huán)自然無法繼續(xù)。最后檢查中斷優(yōu)先級。如果 SysTick 優(yōu)先級被設(shè)得很高而某外設(shè)中斷持有一個(gè)長時(shí)間的臨界區(qū)就可能導(dǎo)致系統(tǒng)時(shí)基被延遲。這套順序適合大部分裸機(jī)調(diào)度器問題。核心思路是先從“時(shí)間有沒有走”開始再檢查“任務(wù)有沒有被掃描到”最后再看“任務(wù)執(zhí)行完沒有”。6. 從裸機(jī)調(diào)度器到 FreeRTOS架構(gòu)演進(jìn)的下一步6.1 定時(shí)器模擬任務(wù)與 RTOS 的本質(zhì)區(qū)別定時(shí)器模擬任務(wù)已經(jīng)具備任務(wù)、時(shí)基、周期調(diào)度的雛形但它和 FreeRTOS 仍然有本質(zhì)區(qū)別。裸機(jī)調(diào)度器沒有任務(wù)上下文切換任務(wù)之間通過函數(shù)調(diào)用完成當(dāng)前任務(wù)運(yùn)行完成后才能輪到下一個(gè)任務(wù)。FreeRTOS 則在 tick 中斷里保存當(dāng)前任務(wù)的寄存器現(xiàn)場再從就緒任務(wù)表里找到最高優(yōu)先級任務(wù)恢復(fù)它的現(xiàn)場并跳轉(zhuǎn)執(zhí)行。FreeRTOS 的任務(wù)切換完整流程大致是滴答定時(shí)器觸發(fā)中斷進(jìn)入xPortSysTickHandler保存當(dāng)前任務(wù)棧指針和寄存器然后調(diào)用vTaskSwitchContext查找下一個(gè)就緒任務(wù)最后恢復(fù)新任務(wù)上下文并退出中斷。這套機(jī)制使得一個(gè)任務(wù)即使被阻塞操作系統(tǒng)也能立馬切換到其他任務(wù)而不是像裸機(jī)調(diào)度器那樣必須等任務(wù)函數(shù)返回。理解這個(gè)區(qū)別很重要。定時(shí)器模擬任務(wù)更接近“協(xié)作式調(diào)度”每個(gè)任務(wù)必須主動讓出 CPU 控制權(quán)。RTOS 是“搶占式調(diào)度”高優(yōu)先級任務(wù)可以打斷低優(yōu)先級任務(wù)。6.2 何時(shí)應(yīng)該遷移到 RTOS定時(shí)器模擬任務(wù)適合任務(wù)數(shù)量穩(wěn)定、執(zhí)行時(shí)間相對固定、不需要復(fù)雜同步機(jī)制的裸機(jī)項(xiàng)目。當(dāng)項(xiàng)目出現(xiàn)下面這些跡象時(shí)就可以認(rèn)真考慮引入 FreeRTOS多個(gè)任務(wù)需要同時(shí)等待不同的事件例如等待串口發(fā)送完成等待按鍵釋放等待傳感器就緒。任務(wù)之間需要傳遞數(shù)據(jù)用全局變量已經(jīng)很難維護(hù)。某個(gè)任務(wù)執(zhí)行時(shí)間不均最壞情況下會影響其他任務(wù)周期。需要互斥量、信號量、消息隊(duì)列這類同步原語而不是自己手工實(shí)現(xiàn)臨界區(qū)。遷移 RTOS 并不意味把原來的裸機(jī)代碼推倒重寫。任務(wù)函數(shù)思想可以保留只是把void task_led_toggle(void)改成帶無限循環(huán)的任務(wù)函數(shù)并使用vTaskDelay或任務(wù)通知替代周期判斷。6.3 遷移時(shí)可以保留的設(shè)計(jì)與需要新增的機(jī)制定時(shí)器模擬任務(wù)里的以下幾點(diǎn)遷移到 RTOS 后依然有效任務(wù)劃分粒度。按鍵掃描、顯示刷新、協(xié)議解析拆分成獨(dú)立任務(wù)這個(gè)劃分思路直接可用。狀態(tài)機(jī)編程方法。狀態(tài)機(jī)在裸機(jī)和 RTOS 里都是消除阻塞的通用手段。周期任務(wù)思想。RTOS 中可以用軟件定時(shí)器或vTaskDelayUntil實(shí)現(xiàn)類似效果。需要新增的機(jī)制主要是同步和通信。裸機(jī)共享變量可以繼續(xù)用但更好的是加入隊(duì)列或信號量讓任務(wù)之間通過消息交互。例如按鍵任務(wù)檢測到按下后不再直接設(shè)置某個(gè)全局標(biāo)志而是向隊(duì)列發(fā)送一個(gè)按鍵事件顯示任務(wù)接收后更新界面。這樣數(shù)據(jù)流更清晰也方便以后擴(kuò)展多個(gè)任務(wù)同時(shí)消費(fèi)事件。6.4 生產(chǎn)環(huán)境中的額外保障無論使用裸機(jī)調(diào)度器還是 RTOS進(jìn)入生產(chǎn)環(huán)境前都要額外關(guān)注幾點(diǎn)。第一點(diǎn)是看門狗。調(diào)度主循環(huán)崩潰時(shí)定時(shí)器中斷可能還在跑tick 繼續(xù)增長程序看起來像活著。建議獨(dú)立監(jiān)控一個(gè)低頻任務(wù)看它是否能按周期翻轉(zhuǎn)“喂狗標(biāo)志”不能則復(fù)位系統(tǒng)。第二點(diǎn)是日志開關(guān)。調(diào)試階段的printf指令在生產(chǎn)環(huán)境要考慮是否保留保留時(shí)建議用宏控制#define LOG_ENABLE 1 #if LOG_ENABLE #define LOG_INFO(fmt, ...) printf(fmt, ##__VA_ARGS__) #else #define LOG_INFO(fmt, ...) #endif第三點(diǎn)是系統(tǒng)時(shí)基穩(wěn)定性。SysTick 是內(nèi)核定時(shí)器但如果某段代碼長時(shí)間關(guān)中斷SysTick 中斷會被延遲時(shí)基就不準(zhǔn)。任何臨界區(qū)都要控制執(zhí)行時(shí)間。第四點(diǎn)是任務(wù)表越界保護(hù)。公開接口內(nèi)部要做參數(shù)檢查和數(shù)組索引檢查避免函數(shù)指針數(shù)組越界寫導(dǎo)致程序跑飛。定時(shí)器模擬任務(wù)是嵌入式軟件設(shè)計(jì)架構(gòu)里一個(gè)承上啟下的概念。它沒有 RTOS 那樣復(fù)雜的調(diào)度算法卻能讓人真正理解“任務(wù)”“時(shí)基”“周期調(diào)度”是怎么一回事。建議先在一個(gè)最小開發(fā)板上把調(diào)度器跑通觀察不同任務(wù)周期的輸出再把阻塞任務(wù)改造成狀態(tài)機(jī)最后對比 RTOS 的調(diào)度機(jī)制。這一套走下來再回頭看 FreeRTOS 源碼里的任務(wù)切換流程會順暢得多。