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