直接在 Proteus 里跑 FreeRTOS這個需求在我后臺被問了一整年。很多人手里沒有開發(fā)板或者板子吃灰了但是想接觸多任務(wù)調(diào)度、隊列、信號量這些 RTOS 玩法又不想一上來就啃源碼。我自己的結(jié)論是用 Proteus 8.9 配合 STM32CubeMX 生成的 HAL 庫工程直接跑 FreeRTOS不僅可行而且很適合做驗證尤其是課程設(shè)計、畢業(yè)設(shè)計前想“先跑通再畫板”的場景。這篇文章就把我自己踩過的坑、驗證過的流程、常用的配置參數(shù)全部梳理一遍跟著做基本能復(fù)現(xiàn)一個帶串口日志和任務(wù)調(diào)度的 FreeRTOS 仿真項目。1. 仿真方案整體拆解Proteus 跑的不是 RTOS而是固件1.1 明確仿真的本質(zhì)CPU 級執(zhí)行 hex很多人第一次聽到“Proteus 仿真 FreeRTOS”會覺得不理解以為要裝什么插件或者要往 Proteus 里塞 RTOS 源碼。實際上不需要。Proteus 對 STM32 的仿真本質(zhì)上是做了一個 Cortex-M3 內(nèi)核的指令級模擬你給它的是編譯生成的 hex 文件它就在虛擬 CPU 上逐條執(zhí)行里面的指令。FreeRTOS 作為軟件庫在編譯階段已經(jīng)鏈接進了你的工程最終全部邏輯都變成了 hex 里的機器碼。Proteus 不需要知道什么是任務(wù)控制塊也不需要理解調(diào)度器它只要把每一條指令、每一次中斷響應(yīng)模擬對你程序里的調(diào)度邏輯就會自然跑起來。這就帶來一個好處只要你的代碼能在 Keil 里正常編譯并產(chǎn)生 hex不管代碼用了 HAL 庫、標準庫還是寄存器操作Proteus 都一視同仁。而 CubeMX 默認生成的就是 HAL 庫工程所以我們直接基于 HAL 庫來做沒有任何額外負擔。1.2 這個仿真能驗證什么不能驗證什么我在實際使用中覺得這套方案最適合驗證的是 RTOS 的邏輯層內(nèi)容包括多任務(wù)的創(chuàng)建、啟動、刪除搶占式調(diào)度下高優(yōu)先級任務(wù)對低優(yōu)先級任務(wù)的影響時間片輪轉(zhuǎn)調(diào)度的宏觀表現(xiàn)隊列、二值信號量、互斥量、事件組這些 IPC 機制軟件定時器的回調(diào)邏輯任務(wù)棧大小是否合理但有幾個方面必須說清楚Proteus 畢竟不是真實芯片它的仿真速度遠慢于真實硬件而且它對外設(shè)的建模是偏功能級別的。FreeRTOS 的實時性能、中斷響應(yīng)延遲、任務(wù)切換耗時這些硬指標在仿真里沒有任何參考意義。還有Proteus 里面所有引腳時序都是虛擬出來的不能用來驗證 GPIO 翻轉(zhuǎn)速度、PWM 脈寬精度、ADC 采樣率這類依賴硬件特性的東西。所以我的建議是用 Proteus 學(xué)調(diào)度邏輯、驗證多任務(wù)功能、跑通協(xié)議通信非常合適但想測 RTOS 的實時性能、做產(chǎn)品級的可靠性驗證還是得回到真實板子上。1.3 我推薦的工程結(jié)構(gòu)做 STM32 的 FreeRTOS 仿真軟件棧我建議是這樣組合STM32CubeMX負責芯片初始化、時鐘配置、外設(shè)配置以及 FreeRTOS 的集成Keil MDK負責編譯和加載 hexProteus 8.9負責運行仿真、提供虛擬終端和虛擬示波器這些調(diào)試工具這三件事各管一塊互不干擾。CubeMX 生成工程時會把 FreeRTOS 的源碼直接放進 Middlewares 目錄Keil 會根據(jù)配置自動編譯這些源碼最終生成的 hex 再丟給 Proteus。整個過程不需要手動移植任何 RTOS 文件所以哪怕你對 FreeRTOS 源碼的目錄結(jié)構(gòu)還不熟也能先把工程跑起來。2. 環(huán)境準備CubeMX、Proteus、Keil 三方配合的關(guān)鍵細節(jié)2.1 版本選擇與第一個大坑時鐘源不匹配我用的組合是 Proteus 8.9 SP2、STM32CubeMX 6.5 以上、Keil MDK 5.37 左右配合 STM32Cube FW_F1 1.8.x 的固件包。這套組合我驗證過多次穩(wěn)定性沒問題。最容易被忽略的是時鐘源配置。CubeMX 新建工程時如果 RCC 選了 HSE 外部晶振作為時鐘源那么 Proteus 電路里必須加上一個 8MHz 的晶振并接好兩個 20pF 左右的負載電容。否則仿真運行之后程序容易卡死或者串口波特率完全不對。反過來如果你不想在 Proteus 里畫晶振那 CubeMX 里 RCC 就要改成 HSI 內(nèi)部時鐘并在 Clock Configuration 里把 PLL 源切到 HSI確保系統(tǒng)時鐘源和 Proteus 中的模型一致。這個“時鐘一致性”是整個仿真方案的大前提因為 HAL_Init 和 FreeRTOS 的 SysTick 配置都會用到 SystemCoreClock如果實際仿真環(huán)境和代碼里算出來的時鐘頻率不一致后面所有依賴時間的東西全部會亂套。我自己的習(xí)慣是在 CubeMX 里用 HSE 8MHzProteus 里老老實實放一個晶振。理由很簡單這是最貼近真實開發(fā)板的接法后面如果你想移植到真實硬件不需要再改代碼。2.2 CubeMX 里 FreeRTOS 的關(guān)鍵配置參數(shù)在 CubeMX 的中間件選項中啟用 FreeRTOS 后有幾個配置項會直接決定仿真能否跑起來接口選擇建議選 CMSIS_V2因為它對應(yīng)的是新版 FreeRTOS 內(nèi)核任務(wù)創(chuàng)建、隊列操作的 API 封裝更現(xiàn)代。Kernel 設(shè)置里的USE_PREEMPTION保持啟用這正是搶占式調(diào)度的開關(guān)。TICK_RATE_HZ填 1000即 1ms 一個 tick這是最常見的配置串口日志里的時間戳也是以這個為基準。MINIMAL_STACK_SIZE默認值經(jīng)常是 128單位是字word不是字節(jié)。Cortex-M3 上一個字是 4 字節(jié)所以 128 字是 512 字節(jié)這個空間只夠跑簡單的任務(wù)。如果任務(wù)里調(diào)用了 printf 或者有較大的局部變量務(wù)必加大到 256 甚至 512。TOTAL_HEAP_SIZE默認值如果是 4096就直接改到 8192 以上。Cortex-M3 的 SRAM 有 20KBF103C8堆太小時創(chuàng)建任務(wù)都可能失敗。還有一個必須手工確認的地方SYS 這個外設(shè)里的 Timebase Source。啟用 FreeRTOS 后必須把 HAL 庫的時基從 SysTick 切換到其他定時器比如 TIM6 或者 TIM7。原因很簡單FreeRTOS 的 tick 依賴 SysTick如果 HAL 庫還占用 SysTick兩套系統(tǒng)會打架輕則延時混亂重則直接在 vTaskDelay 里死循環(huán)。CubeMX 其實會自動處理這個切換但你在生成代碼后依然要去檢查一下確認生成的工程里包含了 stm32f1xx_hal_timebase_tim.c 這個文件而且 SYS 的 Timebase Source 確實是 TIM6 或 TIM7。2.3 Proteus 電路搭建和固件加載Proteus 這邊的電路非常簡單核心元件就是一個 STM32F103C8 芯片模型。搜索“STM32F103C8”就能找到。需要連接的信號包括8MHz 晶振從 OSC_IN 和 OSC_OUT 接入兩個引腳分別對地接 20pF 電容NRST 復(fù)位腳接一個 10k 上拉電阻到 VDD這是為了保證復(fù)位邏輯明確VDD 和 VDDA 接 3.3VVSS 和 VSSA 接地LED1 接 PA1 引腳LED2 接 PA2 引腳LED 另一端串聯(lián)一個 330 歐姆或 1k 歐姆電阻到地虛擬終端Virtual Terminal的 RXD 引腳接 STM32 的 PA9USART1_TX虛擬終端的 GND 要和仿真地共地雙擊 STM32 芯片打開屬性窗口在 Program File 一欄選到你 Keil 生成的 hex 文件。另外需要關(guān)注一下 CKS 屬性如果里面可以直接選時鐘源確保它和你的 CubeMX 配置一致選 HSE 或者外部時鐘。虛擬終端這個東西非常重要調(diào)試 FreeRTOS 任務(wù)狀態(tài)時它就是你的“串口助手”。我一般會設(shè)置波特率 1152008 位數(shù)據(jù)無校驗1 位停止位和 CubeMX 里 USART1 的配置保持一致。2.4 Keil 端的兩個必須設(shè)置在 Keil 里打開 CubeMX 生成的工程后有兩處設(shè)置我不止一次忘記改導(dǎo)致仿真失敗這里直接寫出來Options for Target - Output - 勾選 Create HEX File。不勾選的話Keil 只生成 axf 文件Proteus 加載不了。Options for Target - Target - 勾選 Use MicroLIB。printf 重定向串口輸出時MicroLIB 的 printf 實現(xiàn)體積小很多棧占用也少。如果不用 MicroLIBprintf 可能會把任務(wù)棧瞬間吃光。這兩個設(shè)置不復(fù)雜但缺一個就白搭。3. 代碼實現(xiàn)多任務(wù)調(diào)度加隊列通信的核心邏輯3.1 先理解 FreeRTOS 任務(wù)的基本屬性在寫代碼之前我先把 FreeRTOS 任務(wù)最重要的幾個屬性用大白話講一遍。每個任務(wù)本質(zhì)上就是一個無限循環(huán)的 C 函數(shù)函數(shù)的簽名必須是void task(void *argument)。這個函數(shù)不能返回一旦執(zhí)行完任務(wù)就掛了。任務(wù)的?？臻g大小用usStackDepth參數(shù)指定單位是 word。優(yōu)先級數(shù)字越大優(yōu)先級越高這和很多操作系統(tǒng)正好反過來。任務(wù)創(chuàng)建之后會進入就緒態(tài)由調(diào)度器根據(jù)優(yōu)先級決定誰運行。如果兩個任務(wù)優(yōu)先級相同RTOS 會在每個 tick 之后做時間片輪轉(zhuǎn)讓兩個任務(wù)交替運行。高優(yōu)先級任務(wù)只要沒有被阻塞就會一直占據(jù) CPU低優(yōu)先級任務(wù)永遠沒機會執(zhí)行。這就是搶占式調(diào)度的核心。理解這一點很多仿真里“只有一個任務(wù)在跑”的問題就很容易排查了。3.2 創(chuàng)建任務(wù)和啟動調(diào)度器的方式在 CubeMX 生成的工程里FreeRTOS 的啟動代碼框架已經(jīng)搭好了。main 函數(shù)會先做所有外設(shè)的 HAL 初始化然后調(diào)用 MX_FREERTOS_Init。這個函數(shù)內(nèi)部會做三件事調(diào)用 osKernelInitialize 初始化內(nèi)核創(chuàng)建默認任務(wù)調(diào)用 osKernelStart 啟動調(diào)度器。我通常會在 MX_FREERTOS_Init 的這個位置額外加入自己寫的 App_TaskCreate 函數(shù)把自定義的幾個任務(wù)都創(chuàng)建出來。示例如下/* freertos.c 中 MX_FREERTOS_Init 內(nèi)部片段 */ void MX_FREERTOS_Init(void) { osKernelInitialize(); /* 自定義任務(wù)創(chuàng)建 */ App_TaskCreate(); /* 默認任務(wù) */ defaultTaskHandle osThreadNew(StartDefaultTask, NULL, defaultTask_attributes); osKernelStart(); }App_TaskCreate 內(nèi)部直接用 FreeRTOS 原生 API 創(chuàng)建任務(wù)void App_TaskCreate(void) { xTaskCreate(Task_LED1, LED1, 128, NULL, 1, NULL); xTaskCreate(Task_LED2, LED2, 128, NULL, 1, NULL); xTaskCreate(Task_EventProducer, Producer, 128, NULL, 2, NULL); }需要特別提醒的是任務(wù)名“LED1”“LED2”會用于調(diào)試和任務(wù)列表打印不能重復(fù)也不能超過 configMAX_TASK_NAME_LEN 定義的長度默認是 16 個字符。優(yōu)先級 1 和 2 的區(qū)別在后面會直接體現(xiàn)在仿真現(xiàn)象上。3.3 任務(wù)函數(shù)與 vTaskDelay 的使用第一個任務(wù)負責讓 LED1 每隔 500ms 翻轉(zhuǎn)一次。這里有一個關(guān)鍵點任務(wù)里的延時必須用 vTaskDelay不要用 HAL_Delay。原因很簡單vTaskDelay 會讓當前任務(wù)進入阻塞態(tài)把 CPU 讓給其他任務(wù)這是多任務(wù)調(diào)度的基本語義。而 HAL_Delay 本質(zhì)上是忙等待會一直占用 CPU哪怕內(nèi)部有時基中斷也不會觸發(fā)任務(wù)切換。只要你在一處用了 HAL_Delay低優(yōu)先級任務(wù)基本就會被餓死。void Task_LED1(void *argument) { for (;;) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1); vTaskDelay(pdMS_TO_TICKS(500)); } }pdMS_TO_TICKS 宏會把毫秒轉(zhuǎn)換成 tick 數(shù)前提是 configTICK_RATE_HZ 是 1000這樣 500ms 正好是 500 個 tick。第二個任務(wù)我設(shè)計成 LED2 等待隊列消息。為了讓演示效果更直觀還加了一個 Producer 任務(wù)優(yōu)先級設(shè)為 2每 3 秒往隊列里發(fā)一條消息。LED2 收到消息后翻轉(zhuǎn)一下同時通過串口打印一條日志。這樣能清楚看到優(yōu)先級更高的 Producer 任務(wù)是否可以按周期搶占運行以及隊列是否能把數(shù)據(jù)正確傳遞到 LED2 任務(wù)。QueueHandle_t xEventQueue; void Task_EventProducer(void *argument) { uint8_t msg 1; for (;;) { vTaskDelay(pdMS_TO_TICKS(3000)); xQueueSend(xEventQueue, msg, 0); } } void Task_LED2(void *argument) { uint8_t rxMsg; for (;;) { if (xQueueReceive(xEventQueue, rxMsg, portMAX_DELAY) pdTRUE) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_2); printf([Queue] get msg%d\r\n, rxMsg); } } }在 main 初始化或者 App 初始化里要先創(chuàng)建隊列xEventQueue xQueueCreate(4, sizeof(uint8_t));xQueueCreate 的第一個參數(shù)是隊列深度第二個參數(shù)是單個消息的字節(jié)數(shù)。這里隊里最多緩存 4 條消息每條消息一個字節(jié)。3.4 printf 重定向到串口任務(wù)里的 printf 需要重定向到 USART1 才能出現(xiàn)在虛擬終端上。CubeMX 生成的串口句柄默認叫 huart1所以重定向代碼如下#include stdio.h int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }重定向之后printf 輸出的內(nèi)容會直接通過串口發(fā)送。Proteus 的虛擬終端收到的就是這些字符。要注意的是如果多個任務(wù)同時使用 printf可能會造成字符交叉這是正?，F(xiàn)象。實際項目中通常會加一個互斥量保護串口但在仿真驗證階段我很少這么干畢竟問題本來就不起決定作用。3.5 怎么直觀觀察任務(wù)調(diào)度我在仿真里最常用的觀察手段有三個。第一是看兩個 LED 的閃爍節(jié)奏頻率不同就說明多個任務(wù)在交替執(zhí)行。第二是看虛擬終端的打印日志配合每次打印前加一個 HAL_GetTick 或者任務(wù)計數(shù)能非常清晰地看到時間線。第三是用 FreeRTOS 自帶的任務(wù)狀態(tài)查詢函數(shù)在某個任務(wù)里定期打印所有任務(wù)的狀態(tài)。要打印任務(wù)狀態(tài)需要在 FreeRTOSConfig.h 中打開兩個宏#define configUSE_TRACE_FACILITY 1 #define configUSE_STATS_FORMATTING_FUNCTIONS 1然后調(diào)用 vTaskList把任務(wù)信息格式化到字符串里void Task_StatusDump(void *argument) { char buffer[512]; for (;;) { vTaskDelay(pdMS_TO_TICKS(5000)); vTaskList(buffer); printf(%s\r\n, buffer); } }輸出表格里會有任務(wù)名、狀態(tài)、優(yōu)先級、棧剩余量等信息。狀態(tài)一列會列出 Ready、Blocked、Suspended 等看到這些值基本就能理解調(diào)度器在某一時刻是怎么選擇任務(wù)的。3.6 為什么在任務(wù)里不要使用 HAL_Delay我在這里單獨展開說這個點是因為它太容易踩了。CubeMX 默認生成的大量底層外設(shè)代碼都會調(diào)用 HAL_Delay比如 I2C、SPI 在一些錯誤處理時會用。如果在 FreeRTOS 多任務(wù)環(huán)境中一個任務(wù)調(diào)用了 HAL_Delay它是基于 TIM6 時基的忙等待其他任務(wù)無法趁機運行整個系統(tǒng)看起來就像死機了一樣但 LED 自己的翻轉(zhuǎn)其實還在進行只是大量 CPU 時間被白白浪費了。真正正確的做法是應(yīng)用代碼中所有需要延時的場合都用 vTaskDelay 或者 vTaskDelayUntil。vTaskDelayUntil 更適合做固定周期的循環(huán)因為它在計算延時目標時不受任務(wù)自身執(zhí)行時間影響。比如 LED1 的這個任務(wù)用 vTaskDelayUntil 可以做到非常穩(wěn)定的 500ms 周期翻轉(zhuǎn)TickType_t xLastWakeTime xTaskGetTickCount(); for (;;) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1); vTaskDelayUntil(xLastWakeTime, pdMS_TO_TICKS(500)); }4. 仿真運行中的高頻問題與排查技巧4.1 程序卡死在 HardFault_Handler這個問題排在所有 FreeRTOS 仿真問題的第一名。典型的現(xiàn)象是點擊運行后虛擬終端沒有任何輸出LED 不閃代碼停止在 HardFault_Handler 的 while 死循環(huán)里。常見原因有四個。第一任務(wù)棧溢出尤其使用 printf 時容易觸發(fā)第二SysTick 的中斷優(yōu)先級設(shè)置不正確FreeRTOS 對 kernel 中斷優(yōu)先級有嚴格要求第三某個任務(wù)訪問了非法地址比如數(shù)組越界或者野指針第四隊列或者信號量句柄在創(chuàng)建前就被使用。排查方法我建議按照順序來先檢查任務(wù)棧大小把涉及 printf 的任務(wù)棧開到 256 甚至 512再確認 FreeRTOSConfig.h 中 configASSERT 是否打開打開后如果有優(yōu)先級或互斥調(diào)用問題程序會卡在 configASSERT 指向的具體位置比 HardFault 容易定位得多。最后把默認任務(wù)里的邏輯精簡只保留最簡單的點燈代碼確認是任務(wù)代碼問題還是框架問題。4.2 兩個任務(wù)里只有一個在跑這個現(xiàn)象非常典型而且原因很清楚。如果你啟動了多個任務(wù)但只有一個 LED 在閃另一個完全不動先檢查你的任務(wù)里是不是用了 HAL_Delay。如果用了換成 vTaskDelay。如果沒有檢查兩個任務(wù)的優(yōu)先級。高優(yōu)先級任務(wù)如果沒有阻塞點比如一個任務(wù)里是空空的 for 循環(huán)沒有任何延時它就永遠不會讓出 CPU低優(yōu)先級任務(wù)就一直處于 Ready 狀態(tài)但得不到執(zhí)行。還有一種情況是任務(wù)創(chuàng)建失敗了xTaskCreate 返回的不是 pdPASS。這通常是因為堆內(nèi)存不足。把 TOTAL_HEAP_SIZE 調(diào)大然后重新生成代碼再編譯基本上能解決。在仿真的早期階段我習(xí)慣把每個任務(wù)的?？臻g都開得大一點寧多勿少跑通之后再慢慢縮。4.3 串口沒輸出或者亂碼串口如果完全沒輸出先檢查虛擬終端的接線。VTERM 的 RXD 必須連接 STM32 的 TX也就是 PA9。接反了肯定沒輸出。然后檢查波特率虛擬終端右下角設(shè)置的波特率必須和 CubeMX 里 USART1 配置一樣。如果是亂碼或者輸出了一堆不可見字符十有八九是時鐘配置和 Proteus 仿真環(huán)境不一致。CubeMX 里用的是 HSE 8MHzProteus 電路里卻沒放晶振或者換成了別的頻率這樣 USART 波特率計算必然出錯。另外還有一個隱蔽坑就是用了 HSI 做系統(tǒng)時鐘但串口參數(shù)里 Configure 時誤以為時鐘是 72MHz實際上 HSI 模式很難跑到 72MHz建議工程里統(tǒng)一用 HSE 加 72MHz PLL別在仿真階段折騰 HSI。4.4 仿真速度慢得像蝸牛Proteus 上的 STM32 仿真本來就比真實芯片慢不少FreeRTOS 的調(diào)度又引入了額外的上下文切換開銷所以仿真速度慢很正常。如果感覺慢到?jīng)]法看可以優(yōu)化一點。第一關(guān)掉 Proteus 的動畫效果把 Animation Options 里的實時幀率調(diào)到最低減少圖形渲染的工作量第二減少串口打印內(nèi)容打印越是頻繁仿真越慢第三LED 翻轉(zhuǎn)和定時器周期不要太短盡量用 500ms 甚至 1000ms 級別的延時否則每個仿真步進都在大量中斷慢得更明顯。我實測下來虛擬終端每秒鐘打印 2 到 3 行日志整套仿真在普通電腦上還是能流暢觀察的再多就有點卡了。4.5 Keil 編譯報錯 q0147e 無法創(chuàng)建目錄這個問題可能不少新人會遇到報錯信息類似這樣.\obj\freertos.hex: error: q0147e: failed to create directory .\obj\freertos實際上 Keil 試圖在工程目錄下創(chuàng)建 obj 文件夾但目錄不存在或者用戶的寫權(quán)限不足或者該路徑下的 obj 是一個已經(jīng)存在的同名文件而非文件夾都會觸發(fā)這個錯誤。解決辦法很簡單在 Options for Target - Output - Select Folder for Objects 里手動把輸出目錄改成一個已經(jīng)存在且可寫的路徑比如工程目錄下的 Output 文件夾然后重新編譯。這種報錯經(jīng)常出現(xiàn)在你改了工程名、移動了工程文件夾之后路徑一旦變化舊配置就會失效。4.6 修改 CubeMX 參數(shù)后 Proteus 里還是老行為這是很多新手容易犯的失誤。CubeMX 生成新代碼后Keil 并不會自動重新編譯 hexProteus 里加載的仍然是舊 hex。我一般會養(yǎng)成一個習(xí)慣每次修改 CubeMX 配置后在 Keil 里 Clean 一下再重新 Build同時確認工程輸出路徑下 hex 文件的修改時間是最新的。另一個相關(guān)的問題是Keil 雖然編譯成功但生成的 hex 路徑和 Proteus 里配置的路徑不一致。比如 CubeMX 生成工程時默認輸出到 Debug 或者 Release 目錄而你后來手動改了 Output 目錄Proteus 還指向舊路徑那仿真跑的就是一個非常老的固件。最好的辦法是每次仿真前手動確認 Proteus 里 Program File 的路徑別只看文件存在就投放。5. 如何用這套仿真更深入理解 RTOS 行為5.1 用任務(wù)掛起和恢復(fù)模擬事件觸發(fā)仿真的價值不只是驗證代碼能跑還在于可以主動構(gòu)造各種事件來觀察調(diào)度器行為。FreeRTOS 里最常用的控制接口是 vTaskSuspend 和 vTaskResume。我做過一個例子默認情況下 LED2 任務(wù)處于掛起狀態(tài)并不執(zhí)行串口收到一個指定字符后調(diào)用 vTaskResume 喚醒 LED2然后 LED2 才開始閃爍。這個實驗?zāi)苤庇^地展示任務(wù)狀態(tài)遷移比干看書上的狀態(tài)圖有用得多。如果你讓串口輸入由虛擬終端的鍵盤發(fā)送甚至可以實現(xiàn)“鍵盤按鍵控制任務(wù)”的交互效果。在課程設(shè)計答辯時這種可視化演示很容易講清楚。5.2 利用軟件定時器做周期任務(wù)除了任務(wù)FreeRTOS 還有軟件定時器機制。軟件定時器的回調(diào)是在定時器守護任務(wù)的上下文里執(zhí)行的不能調(diào)用阻塞型 API。我建議起碼跑通一個簡單例子用 xTimerCreate 創(chuàng)建一個 2 秒周期的定時器回調(diào)里翻轉(zhuǎn)一個 LED。void Timer_Callback(TimerHandle_t xTimer) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1); } TimerHandle_t xTimer xTimerCreate( Timer, pdMS_TO_TICKS(2000), pdTRUE, NULL, Timer_Callback); xTimerStart(xTimer, 0);跑通之后你會發(fā)現(xiàn)軟件定時器的回調(diào)周期和任務(wù)的優(yōu)先級完全沒有關(guān)系它由獨立的內(nèi)核機制驅(qū)動。理解這個區(qū)別對后面做實際項目很有幫助。5.3 用 vTaskGetRunTimeStats 看 CPU 占用如果你把configGENERATE_RUN_TIME_STATS打開并提供一個高頻計時時鐘就可以用 vTaskGetRunTimeStats 獲取每個任務(wù)占用 CPU 的時間百分比。在 Proteus 里這個計時源不太好搞但可以用 SysTick 計數(shù)近似替代。跑出來的數(shù)據(jù)雖然不像真實板卡那么精確但能讓你直觀感受到兩個任務(wù)之間的 CPU 分配情況加深對優(yōu)先級和時間片輪轉(zhuǎn)的理解。5.4 進階方向加入 LCD 和外部傳感器Proteus 8.9 自帶了 LCD 模型和一些常見的 I2C/SPI 傳感器模型如果把 FreeRTOS 的顯示任務(wù)和傳感器采集任務(wù)分開可以做出一個具備完整業(yè)務(wù)邏輯的仿真項目。比如用 I2C 接口掛一個溫濕度傳感器采集任務(wù)每隔 2 秒讀一次數(shù)據(jù)通過隊列發(fā)送給顯示任務(wù)LCD 顯示實驗結(jié)果。這個過程里你能真正體會到 RTOS 多任務(wù)通信在實際應(yīng)用中的價值。我自己在實際操作中的體會是Proteus 里的 FreeRTOS 仿真最適合當做一個“教學(xué)沙盤”它把抽象的調(diào)度過程變成了肉眼可見的 LED 閃爍和串口日志。當你親眼看到兩個 LED 以不同頻率各自閃爍再回到代碼里分析優(yōu)先級和 tick 配置理解和記憶都會扎實很多。如果將來到了真實開發(fā)板你只需要調(diào)整時鐘和引腳配置剩下 RTOS 這部分經(jīng)驗依然是通用的。