FreeRTOS移植到STM32這活兒說難不難說簡單也真不算簡單。網(wǎng)上教程一抓一大把但多數(shù)不是講得太抽象就是直接甩個工程讓你自己琢磨最關(guān)鍵的“為什么這么做”反而沒人講。我前前后后給F1、F4系列的芯片都做過移植也在Proteus里踩過不少坑這篇就把從零開始到多任務(wù)跑起來的完整過程包括所有配置細節(jié)和仿真里那些容易讓人抓狂的坑一次性說清楚。咱們這篇實戰(zhàn)基于STM32F103C8T6這顆經(jīng)典芯片開發(fā)環(huán)境用Keil MDK仿真用Proteus 8。目標(biāo)很簡單把FreeRTOS內(nèi)核跑起來創(chuàng)建兩個任務(wù)輪流點燈驗證任務(wù)調(diào)度正常再把整個工程搬到Proteus里做一次純軟件的聯(lián)調(diào)。整個過程不求花哨但每一步都可復(fù)現(xiàn)適合第一次接觸RTOS的兄弟照著做。1. 項目整體設(shè)計與思路拆解1.1 為什么選STM32F103C8T6和FreeRTOSSTM32F103C8T6是Cortex-M3內(nèi)核主頻72MHzFlash 64KBSRAM 20KB。這顆芯片在國產(chǎn)開發(fā)板上出貨量極大資料多、價格便宜、上手成本低。關(guān)鍵它是Cortex-M3內(nèi)核FreeRTOS對Cortex-M3的支持在官方代碼里已經(jīng)非常成熟移植主要改兩個文件就行用來做學(xué)習(xí)載體非常合適。FreeRTOS選擇它而不是其他RTOS理由也很實在開源免費、商業(yè)友好、文檔完善、社區(qū)活躍。像國內(nèi)很多公司做產(chǎn)品小資源單片機上跑FreeRTOS是標(biāo)配學(xué)完直接能用到項目里性價比極高。跟RT-Thread比FreeRTOS更輕量資源占用更小跟UCOS比FreeRTOS免授權(quán)費沒有商用風(fēng)險。1.2 移植的本質(zhì)FreeRTOS到底在移植什么很多新手一聽“移植”兩個字就發(fā)怵覺得是不是要把整個系統(tǒng)重寫一遍。其實完全不是。FreeRTOS的內(nèi)核代碼是跨平臺通用的跟硬件相關(guān)的部分被抽象到了極少數(shù)的接口里移植的本質(zhì)就是“把FreeRTOS和硬件之間的接口接通”。具體來說就三件事提供系統(tǒng)時鐘節(jié)拍Tick讓內(nèi)核有“心跳”來調(diào)度任務(wù)提供上下文切換的觸發(fā)機制PendSV異常提供啟動第一個任務(wù)時所需的匯編代碼入口這三件事在Cortex-M3上FreeRTOS官方已經(jīng)寫好了我們需要做的就是把它加到工程里、配置好中斷優(yōu)先級然后把系統(tǒng)節(jié)拍從STM32的SysTick中斷里“喂”給內(nèi)核。這個思路如果理解了后面不管是換F4還是換G0系列心里都有底。1.3 方案選型標(biāo)準庫還是HAL庫現(xiàn)在STM32開發(fā)主要分標(biāo)準外設(shè)庫StdPeriph和HAL庫兩派。我這次用標(biāo)準庫原因很實際F103的標(biāo)準庫資料最全網(wǎng)上幾乎所有FreeRTOS移植教程都基于標(biāo)準庫遇到問題搜解決方案命中率最高。另外標(biāo)準庫代碼直白寄存器操作看得清清楚楚對理解底層原理有好處——移植的時候你能清楚地看到SysTick中斷是怎么進來的GPIO是怎么翻轉(zhuǎn)的。HAL庫當(dāng)然也能配FreeRTOS而且ST官方有現(xiàn)成的CubeMX生成工具鼠標(biāo)點幾下就能生成帶FreeRTOS的工程。但對于“想搞懂原理”的人來說CubeMX把一切都封裝好了反而學(xué)不到什么東西。建議路徑是先用標(biāo)準庫手動移植一遍理解了整個機制之后再去用CubeMX提升開發(fā)效率兩條腿走路。2. 工程搭建與內(nèi)核源碼準備2.1 FreeRTOS源碼拿到了怎么處理去官網(wǎng)下載FreeRTOS源碼包解壓后你會看到三個目錄但真正用到的只有其中一個FreeRTOS/Source內(nèi)核源碼這是核心FreeRTOS/Demo各平臺示例工程參考用的FreeRTOS-Plus一些擴展組件暫時不用管Source目錄下面還有幾個子目錄需要加到KEIL工程里的東西如下FreeRTOS/Source/ ├── tasks.c // 任務(wù)創(chuàng)建、調(diào)度、阻塞等核心邏輯 ├── queue.c // 隊列和信號量的實現(xiàn) ├── list.c // 內(nèi)核鏈表操作 ├── timers.c // 軟件定時器 ├── event_groups.c // 事件標(biāo)志組 ├── croutine.c // 協(xié)程一般用不到 └── portable/ ├── MemMang/ │ ├── heap_1.c │ ├── heap_2.c │ ├── heap_3.c │ ├── heap_4.c │ └── heap_5.c └── RVDS/ └── ARM_CM3/ ├── port.c // 移植層核心代碼 └── portmacro.h // 數(shù)據(jù)類型定義、宏定義這里強調(diào)兩點。第一portable目錄下對應(yīng)不同編譯器和內(nèi)核的組合我們用的是Keil RVDS工具鏈加Cortex-M3核所以選RVDS/ARM_CM3目錄。第二heap_x.c這五個文件都是內(nèi)存管理方案加起來只需要選一個加進工程我選的是heap_4.c理由后面細說。2.2 在Keil里創(chuàng)建工程并正確分組工程創(chuàng)建不算難但目錄結(jié)構(gòu)最好一次到位不然后面文件多了容易亂。我的習(xí)慣是這么分的USERmain.c、stm32f10x_it.c中斷服務(wù)函數(shù)CORE啟動文件startup_stm32f10x_md.s、core_cm3.cSYSTEMdelay.c、sys.c、usart.c正點原子風(fēng)格的底層文件HARDWAREled.c、key.c等外設(shè)驅(qū)動FREERTOS把Source下的c文件全部加進來FREERTOS/includeFreeRTOS.h等頭文件FREERTOS/portableport.c和heap_4.cKeil里點Manage Project Items新建Group把文件添加進去就行。頭文件路徑在Options for Target - C/C - Include Paths里添加至少需要這幾個路徑USER CORE SYSTEM/delay SYSTEM/sys SYSTEM/usart HARDWARE FreeRTOS/Source/include FreeRTOS/portable/RVDS/ARM_CM3一個容易忽略的坑FreeRTOS/Source/include目錄必須加很多新手只加了portable下的路徑結(jié)果編譯報一堆“FreeRTOS.h not found”的錯誤。2.3 heap_4.c為什么是首選內(nèi)存管理方案FreeRTOS提供了五個內(nèi)存管理文件區(qū)別在于分配策略和適用場景。heap_1只能分配不能釋放最簡單適合永不刪除任務(wù)的場景heap_2支持釋放但不會合并相鄰空閑塊容易產(chǎn)生碎片heap_3包裝了標(biāo)準庫的malloc/free簡單但速度慢還依賴編譯器heap_4支持釋放且會合并相鄰空閑塊碎片控制最好heap_5在heap_4基礎(chǔ)上支持多段不連續(xù)內(nèi)存我選heap_4是因為它在絕大多數(shù)FreeRTOS項目中都是默認推薦方案尤其是你創(chuàng)建任務(wù)后可能會刪除任務(wù)或者用到信號量、隊列這類動態(tài)分配內(nèi)存的組件時heap_4的合并機制能更有效地利用有限的RAM。F103C8T6只有20KB RAM本來就緊張選個對內(nèi)存友好的方案很有必要。3. FreeRTOSConfig.h配置詳解每個宏都要心里有數(shù)3.1 基礎(chǔ)配置系統(tǒng)節(jié)拍與任務(wù)參數(shù)FreeRTOSConfig.h是FreeRTOS的“配置文件”內(nèi)核編譯時主要靠它來決定功能開關(guān)和行為參數(shù)。這個文件內(nèi)部沒有現(xiàn)成的需要根據(jù)模板自己創(chuàng)建。核心的配置項我逐個過一遍#define configUSE_PREEMPTION 1 #define configUSE_IDLE_HOOK 0 #define configUSE_TICK_HOOK 0 #define configCPU_CLOCK_HZ ( ( unsigned long ) 72000000 ) #define configTICK_RATE_HZ ( ( TickType_t ) 1000 ) #define configMAX_PRIORITIES ( 5 ) #define configMINIMAL_STACK_SIZE ( ( unsigned short ) 128 ) #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 8 * 1024 ) ) #define configMAX_TASK_NAME_LEN ( 16 )先說configCPU_CLOCK_HZ這個是CPU主頻STM32F103C8T6經(jīng)過內(nèi)部PLL倍頻到72MHz這里就填72000000。configTICK_RATE_HZ是系統(tǒng)節(jié)拍頻率1000表示1ms一個Tick。這里需要提醒不是頻率越高越好每個Tick都會觸發(fā)一次SysTick中斷頻繁中斷會消耗CPU占用率尤其在低主頻芯片上會更明顯。1000Hz是折中后最常見的配置。configTOTAL_HEAP_SIZE是內(nèi)核可用的總堆大小我給了8KB。F103C8T6有20KB SRAM刨去全局變量和?？臻g留給內(nèi)核的8KB是合理的。如果你任務(wù)多或棧配得大可以適當(dāng)調(diào)大這個值但千萬別超過實際剩余RAM否則運行時會直接HardFault。3.2 功能開關(guān)按需裁剪組件#define configUSE_TRACE_FACILITY 1 #define configUSE_16_BIT_TICKS 0 #define configUSE_MUTEXES 1 #define configUSE_COUNTING_SEMAPHORES 1 #define configUSE_RECURSIVE_MUTEXES 1 #define configUSE_TIMERS 1 #define configTIMER_TASK_PRIORITY 2 #define configTIMER_QUEUE_LENGTH 5 #define configTIMER_TASK_STACK_DEPTH 128 #define configQUEUE_REGISTRY_SIZE 8這些開關(guān)決定了FreeRTOS的“豪華程度”。如果用不到互斥鎖、計數(shù)信號量、軟件定時器就全關(guān)掉能省一點Flash和RAM。但既然標(biāo)題是“搭建多任務(wù)系統(tǒng)”后續(xù)大概率會用到任務(wù)間通信所以直接全開省得后面想用又得回來改配置重新編譯。向量表偏移里還有一組宏#define configENABLE_FPU 0 #define configENABLE_MPU 0F103沒有MPU也沒有FPUCortex-M3不帶硬件浮點所以都是0。如果你用的是M4芯片這兩個要重點看FPU那一項必須打開否則浮點運算在任務(wù)切換時會丟數(shù)據(jù)——這是M4移植最經(jīng)典的坑F1反而沒這個煩惱。3.3 中斷優(yōu)先級配置最容易出錯的區(qū)域中斷優(yōu)先級這段是整個配置里最關(guān)鍵的沒有之一。#define configPRIO_BITS 4 #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15 #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5 #define configKERNEL_INTERRUPT_PRIORITY \ ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY (8 - configPRIO_BITS) ) #define configMAX_SYSCALL_INTERRUPT_PRIORITY \ ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY (8 - configPRIO_BITS) )這段我得仔細講新手在這里翻車的概率極高。Cortex-M3的中斷優(yōu)先級寄存器用的是高4位STM32F103配置為4位搶占優(yōu)先級數(shù)值越大優(yōu)先級越低。FreeRTOS要求所有調(diào)用FreeRTOS API的中斷其優(yōu)先級數(shù)值必須大于等于configMAX_SYSCALL_INTERRUPT_PRIORITY。也就是說中斷優(yōu)先級數(shù)值為5到15的中斷才能安全調(diào)用FreeRTOS函數(shù)0到4是“禁止調(diào)用”的高優(yōu)先級中斷。這里的移位計算是有講究的。Cortex-M內(nèi)核優(yōu)先級寄存器是8位寬度但STM32只用了高4位所以要把4位數(shù)值左移4位放在高字節(jié)位置。例如15左移4位等于0xF0寫進NVIC寄存器后實際生效的就是高4位的數(shù)值15。如果你直接寫15不左移實際寫入的值就完全錯了中斷優(yōu)先級就亂了。另外務(wù)必注意用NVIC配置中斷時搶占優(yōu)先級的值必須在5到15之間。如果你把一個中斷的優(yōu)先級配成0到4那這個中斷里就不能調(diào)用任何FreeRTOS的API否則會破壞內(nèi)核臨界區(qū)保護導(dǎo)致系統(tǒng)崩潰。4. 系統(tǒng)節(jié)拍與底層端口實現(xiàn)4.1 SysTick_Handler中斷里到底該寫什么FreeRTOS在Cortex-M3上的系統(tǒng)節(jié)拍來自SysTick定時器。你需要做的是在STM32的SysTick中斷服務(wù)函數(shù)里調(diào)用FreeRTOS的節(jié)拍處理函數(shù)。在stm32f10x_it.c文件里找到SysTick_Handler改成這樣void SysTick_Handler(void) { if (xTaskGetSchedulerState() ! taskSCHEDULER_NOT_STARTED) { xPortSysTickHandler(); } }為什么要加這個判斷因為在啟動調(diào)度器之前SysTick可能已經(jīng)被初始化了但內(nèi)核還沒跑起來這時候如果直接調(diào)用xPortSysTickHandler內(nèi)核會因為沒有任務(wù)上下文而異常。加了調(diào)度器狀態(tài)判斷就保證了只有內(nèi)核啟動后才往里“喂”心跳。有一種簡化寫法是直接調(diào)用xPortSysTickHandler()不去判斷調(diào)度器狀態(tài)。這在某些情況下也能跑因為官方移植層本身有保護但加上判斷更穩(wěn)妥尤其當(dāng)你用調(diào)試器單步跟蹤在啟動調(diào)度器之前就觸發(fā)了SysTick中斷不帶判斷很容易卡死。4.2 PendSV與SVC中斷任務(wù)切換的幕后英雄Cortex-M3上有兩個異常是FreeRTOS移植的關(guān)鍵SVC用于啟動第一個任務(wù)PendSV用于發(fā)起任務(wù)切換。這兩個中斷的服務(wù)函數(shù)不能自己寫必須用官方移植層提供的實現(xiàn)。在port.c文件里官方已經(jīng)用匯編寫好了這兩個中斷處理函數(shù)void SVC_Handler(void) __attribute__ ((naked)); void PendSV_Handler(void) __attribute__ ((naked));關(guān)鍵是啟動文件里的中斷向量表名稱必須對應(yīng)上。如果啟動文件里寫的是PendSV_Handler而port.c里提供的函數(shù)名也是PendSV_Handler那就直接匹配。但正點原子、野火這些開發(fā)板的標(biāo)準例程里啟動文件可能已經(jīng)定義了PendSV_Handler的弱實現(xiàn)這時候FreeRTOS的port.c只要同名覆蓋就行。如果編譯后鏈接報重復(fù)定義的錯誤說明有兩個PendSV_Handler。檢查一下啟動文件里是否已經(jīng)有這個中斷函數(shù)的實現(xiàn)代碼有的話刪掉啟動文件里的那個實現(xiàn)保留port.c里的。還有一個常見情況是你的工程里自己寫了PendSV_Handler比如裸機開發(fā)時做任務(wù)切換用一定要刪掉讓位給FreeRTOS的實現(xiàn)。4.3 服務(wù)函數(shù)名的三個不同版本上面說到了SVC_Handler和PendSV_Handler是基于標(biāo)準庫的寫法。如果你用的是HAL庫中斷服務(wù)函數(shù)的名稱會不太一樣啟動文件里的向量表也會不同。標(biāo)準庫SysTick_Handler、SVC_Handler、PendSV_HandlerHAL庫F1SysTick_Handler、SVC_Handler、PendSV_HandlerF1的HAL和標(biāo)準庫名字恰好一樣HAL庫F4/H7SysTick_Handler、SVC_Handler、PendSV_Handler一樣但實現(xiàn)細節(jié)有差異大多數(shù)情況下這三個中斷服務(wù)函數(shù)的名字是統(tǒng)一的真正需要注意的是port.c文件里硬編碼的向量表序號定義以及是否用到了CMSIS的接口。在F1上用標(biāo)準庫按上面說的一步步做就不會有問題。如果換到F4除了中斷優(yōu)先級位數(shù)可能不同F(xiàn)4是4位F1也是4位還要檢查port.c選擇的是ARM_CM4F目錄下的版本而不是ARM_CM3。5. 多任務(wù)系統(tǒng)實現(xiàn)兩個任務(wù)點亮一顆LED5.1 任務(wù)函數(shù)的標(biāo)準寫法任務(wù)函數(shù)的本質(zhì)是“永遠不會返回的函數(shù)”。我們需要用無限循環(huán)把所有邏輯包起來否則任務(wù)函數(shù)一旦執(zhí)行到末尾就會觸發(fā)內(nèi)核的斷言機制。void LED1_Task(void *argument) { while(1) { GPIO_SetBits(GPIOB, GPIO_Pin_0); vTaskDelay(200); GPIO_ResetBits(GPIOB, GPIO_Pin_0); vTaskDelay(200); } } void LED2_Task(void *argument) { while(1) { GPIO_SetBits(GPIOB, GPIO_Pin_1); vTaskDelay(500); GPIO_ResetBits(GPIOB, GPIO_Pin_1); vTaskDelay(500); } }這個例子里任務(wù)1每200毫秒翻轉(zhuǎn)一次PB0上的LED任務(wù)2每500毫秒翻轉(zhuǎn)一次PB1上的LED。兩者節(jié)奏不同、優(yōu)先級不同正好可以觀察調(diào)度的效果。注意一個新手常犯的錯誤裸機開發(fā)時用delay_ms實現(xiàn)延時到了RTOS里還是用delay_ms。結(jié)果任務(wù)一延時整個系統(tǒng)都卡住了其他任務(wù)全都不執(zhí)行。原因很簡單裸機的延時函數(shù)是空轉(zhuǎn)跑循環(huán)占著CPU不放RTOS的vTaskDelay是“讓出CPU”當(dāng)前任務(wù)進入阻塞態(tài)其他任務(wù)才能運行。這是RTOS和裸機思維最大的區(qū)別一定要改過來。5.2 main函數(shù)里創(chuàng)建任務(wù)并啟動調(diào)度器int main(void) { NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); delay_init(); LED_Init(); xTaskCreate(LED1_Task, LED1, 128, NULL, 2, NULL); xTaskCreate(LED2_Task, LED2, 128, NULL, 1, NULL); vTaskStartScheduler(); while(1); }兩個重點。第一NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4)必須在創(chuàng)建任務(wù)之前調(diào)用甚至要在main函數(shù)最前面。FreeRTOS在Cortex-M3上要求使用4位搶占優(yōu)先級即Group_4模式所有優(yōu)先級都作為搶占優(yōu)先級。如果配置成Group_2或Group_3下面FreeRTOSConfig.h里的優(yōu)先級宏就可能不匹配系統(tǒng)運行起來行為會非常詭異。第二vTaskStartScheduler()這個函數(shù)正常情況下是不會返回的。它會創(chuàng)建空閑任務(wù)、初始化SysTick、啟動第一個任務(wù)把系統(tǒng)交給調(diào)度器。如果這個函數(shù)返回了說明內(nèi)核初始化失敗——最常見的原因是內(nèi)存不夠比如configTOTAL_HEAP_SIZE太小空閑任務(wù)創(chuàng)建失敗。調(diào)試時可以在vTaskStartScheduler()之后加個打印或點亮一個錯誤LED方便快速發(fā)現(xiàn)問題。5.3 棧大小怎么定128個字還是256個字xTaskCreate的第三個參數(shù)是棧大小單位是“字”Word在32位處理器上一個字等于4字節(jié)。也就是說128個字等于512字節(jié)256個字等于1KB。這個大小怎么估算一個任務(wù)里如果定義了局部變量、調(diào)用了printf之類的庫函數(shù)、做了一點浮點運算棧消耗就會明顯增加。任務(wù)嵌套的函數(shù)調(diào)用層級越深臨時變量越多需要的棧就越大。我的經(jīng)驗值是簡單的點燈任務(wù)128個字夠了如果任務(wù)里要打印日志、做復(fù)雜計算直接給256或512。棧給小了不會編譯報錯而是運行到一定時候突然HardFault或者任務(wù)棧溢出非常難查。運氣好的是FreeRTOS提供了棧溢出檢測機制。在FreeRTOSConfig.h里加上#define configCHECK_FOR_STACK_OVERFLOW 2同時實現(xiàn)vApplicationStackOverflowHook函數(shù)void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { while(1); }把斷點設(shè)在while(1)那一行一旦棧溢出就會觸發(fā)這個鉤子函數(shù)調(diào)試效率高很多。我發(fā)現(xiàn)configCHECK_FOR_STACK_OVERFLOW設(shè)置為1只在任務(wù)切換時做檢查設(shè)置為2會在每個中斷里做檢查更靈敏但會消耗一點性能。學(xué)習(xí)階段直接用2就行發(fā)布產(chǎn)品時再關(guān)掉。6. Proteus仿真配置從原理圖到聯(lián)調(diào)6.1 在Proteus里搭一個能跑FreeRTOS的最小系統(tǒng)Proteus 8以后的版本元件庫比較全STM32F103C8T6可以直接搜到。搭建最小系統(tǒng)要放這幾樣?xùn)|西STM32F103C8T6芯片兩個LED燈串電阻后分別接PB0、PB1兩個電阻典型330歐到1K歐仿真用的電源和地雙擊芯片打開屬性對話框這里有個關(guān)鍵配置Processor Clock Frequency。F103外部晶振如果是8MHz這里填8MHz。原因是FreeRTOS的configCPU_CLOCK_HZ寫的72MHz是CPU主頻但Proteus里面不需要接外部晶振電路它用內(nèi)部模型做仿真。如果遇到任務(wù)節(jié)奏不對、LED閃爍頻率和預(yù)期不符第一件事就是檢查這個時鐘頻率設(shè)置。STM32F103C8T6在Proteus里通?？梢詮腜rogram File選項直接加載HEX文件。編譯后生成的HEX在Keil工程目錄的Objects文件夾下點擊芯片屬性里的Program File選中這個HEX文件就可以開始仿真了。6.2 Proteus仿真STM32容易踩的三個坑Proteus仿真STM32是個好東西但坑也不少我列出最常遇到的三個。第一個坑LED不亮程序看起來是正常的但仿真就是沒反應(yīng)。排查思路是檢查芯片有沒有上電、有沒有加載HEX文件、GPIO模式是否配置正確。STM32的GPIO默認是浮空輸入模式如果你在初始化里沒把它設(shè)置為推挽輸出LED當(dāng)然不亮。Proteus對GPIO電平是嚴格按照寄存器配置來模擬的比真實的板子更“較真”裸機那套“不管GPIO模式先拉電平”的做法在這里行不通。第二個坑仿真速度太慢或太快。Proteus仿真不是實時的它用軟件模擬CPU指令執(zhí)行速度取決于你電腦的性能和對芯片的仿真精度。有時候FreeRTOS任務(wù)切換在Proteus里看起來“一頓一頓”的不一定是代碼問題而單純是仿真器速度限制。把System內(nèi)部仿真頻率調(diào)低一點或者關(guān)閉一些動畫效果比如把LED的動畫屬性關(guān)掉能明顯加快仿真速度。第三個坑也是最坑的一個Proteus對FreeRTOS的SysTick中斷模擬不完整。我實測發(fā)現(xiàn)在某些版本的Proteus中SysTick定時器的中斷觸發(fā)邏輯與真實硬件存在細微差別表現(xiàn)為系統(tǒng)節(jié)拍頻率不對或者任務(wù)調(diào)度偶爾錯亂。這不是代碼的問題而是仿真模型的限制。我的經(jīng)驗是Proteus非常適合驗證裸機邏輯和簡單的GPIO時序但涉及RTOS多任務(wù)調(diào)度這種高度依賴精確中斷時序的場景仿真結(jié)果只能作參考最終還是要燒到真實芯片上驗證。你要是遇到“Proteus里始終跑不起來但實物板子一切正?！钡那闆r別懷疑人生先懷疑仿真模型。6.3 可視化驗證串口打印任務(wù)運行狀態(tài)點燈能證明任務(wù)在跑但要看任務(wù)調(diào)度細節(jié)串口打印更直觀。在Proteus里放一個Virtual Terminal虛擬終端連接到USART1的TX引腳然后在任務(wù)里打印當(dāng)前任務(wù)名和系統(tǒng)Tick值void LED1_Task(void *argument) { while(1) { printf(LED1 Task, Tick %d\r\n, xTaskGetTickCount()); GPIO_SetBits(GPIOB, GPIO_Pin_0); vTaskDelay(200); GPIO_ResetBits(GPIOB, GPIO_Pin_0); vTaskDelay(200); } }xTaskGetTickCount()返回的是系統(tǒng)啟動以來的Tick數(shù)通過打印這個值你可以清楚地看到兩個任務(wù)交替運行的時間線驗證優(yōu)先級和延時是否按預(yù)期工作。有一點要注意printf在嵌入式里通常需要重定向fputc也就是實現(xiàn)這個函數(shù)int fputc(int ch, FILE *f) { while(USART_GetFlagStatus(USART1, USART_FLAG_TC) RESET); USART_SendData(USART1, (uint8_t)ch); return ch; }還有一點很值得提醒printf本身會消耗不少?？臻g如果你在任務(wù)里調(diào)用printf而任務(wù)棧只給了128個字大概率會觸發(fā)棧溢出。建議調(diào)printf的任務(wù)棧給到256或512個字不然打印幾次后系統(tǒng)就莫名其妙崩了。6.4 仿真時任務(wù)調(diào)度的觀察技巧進了Proteus仿真后除了看LED閃爍還可以利用斷點來觀察任務(wù)切換。在Keil的Debug模式下給兩個任務(wù)的循環(huán)體各打一個斷點全速運行時你就能看到主線程在兩個斷點之間來回跳轉(zhuǎn)結(jié)合Call Stack窗口可以查看當(dāng)前任務(wù)名。這種方式能直觀地看到系統(tǒng)在兩個任務(wù)之間切換比單純看LED閃爍更深入。但Proteus有一個限制需要知道它不支持硬件調(diào)試器比如ST-Link連接跟Keil聯(lián)調(diào)的方式是通過仿真本身運行。也就是說你沒法用ST-Link的硬件斷點去單步跟蹤Proteus里的FreeRTOS調(diào)度過程。這也是Proteus不適合做RTOS深度調(diào)試的原因之一。真要分析任務(wù)切換詳細過程買一塊最小系統(tǒng)板ST-Link體驗完全不同強烈建議有條件的話實板調(diào)試。7. 常見錯誤與排查技巧實錄7.1 編譯錯誤undefined symbol和重復(fù)定義編譯期最常見的一類錯誤是“Undefined Symbol”通常是以下原因頭文件路徑?jīng)]加全最常見的是少了FreeRTOS/Source/includeheap_x.c沒加進工程內(nèi)核需要內(nèi)存分配函數(shù)port.c沒有添加進去匯編接口全找不到另一類是“Duplicate Symbol”重復(fù)定義錯誤。優(yōu)先檢查啟動文件里是否已經(jīng)有一個PendSV_Handler或SysTick_Handler的實現(xiàn)。如果你在別的文件里也寫了SysTick_Handler就會和FreeRTOS的xPortSysTickHandler調(diào)用產(chǎn)生沖突。解決辦法是只保留一個把不要的實現(xiàn)注釋掉或刪除。還有一種錯誤很容易忽略你定義了vApplicationIdleHook之類的鉤子函數(shù)但FreeRTOSConfig.h里的configUSE_IDLE_HOOK是0。這時候鉤子函數(shù)根本不會被調(diào)用但如果你聲明錯了簽名編譯器可能報錯。要養(yǎng)成習(xí)慣定義鉤子函數(shù)前先確認對應(yīng)的configUSE_xxx_HOOK開關(guān)已經(jīng)打開。7.2 運行異?？ㄋ涝贖ardFault_HandlerHardFault_Handler是嵌入式開發(fā)者最不想看到的函數(shù)。程序一跑就跳進去說明發(fā)生了非法內(nèi)存訪問或非法指令。結(jié)合FreeRTOS的上下文常見的根因有幾類。任務(wù)棧溢出是最常見的。配置過小任務(wù)內(nèi)調(diào)用函數(shù)層級深局部變量多就會踩過棧邊界。經(jīng)驗判斷方法是先把所有任務(wù)棧大小翻倍如果HardFault消失說明就是棧不夠再逐個縮小找到合適的值。中斷里調(diào)用FreeRTOS API也容易引發(fā)HardFault。在中斷服務(wù)函數(shù)里調(diào)用xQueueSendFromISR這類“FromISR”后綴的API這是正確的寫法。如果在中斷里直接調(diào)用xQueueSend這樣的普通版本就會觸發(fā)內(nèi)核斷言或HardFault。還有一個經(jīng)常被忽略的優(yōu)先級分組配置錯誤。裸機代碼里經(jīng)常把NVIC配置成Group_2也就是2位搶占2位子優(yōu)先級。但FreeRTOS要求Group_4全搶占模式如果你沒改中斷優(yōu)先級數(shù)值的含義就不對了同樣會導(dǎo)致HardFault。7.3 任務(wù)不調(diào)度的排查思路程序能跑LED也亮了但似乎只有高優(yōu)先級任務(wù)在執(zhí)行低優(yōu)先級任務(wù)完全沒反應(yīng)。這時候從幾個方向排查。優(yōu)先級是否合理。FreeRTOS是搶占式調(diào)度高優(yōu)先級的任務(wù)只要處于就緒態(tài)低優(yōu)先級任務(wù)就無法獲得CPU。如果你創(chuàng)建了一個任務(wù)while(1)里既沒有延時也沒有等待事件它就會一直霸占CPU。比如LED1任務(wù)優(yōu)先級2LED2任務(wù)優(yōu)先級1LED1的循環(huán)里沒有vTaskDelay那LED2永遠得不到執(zhí)行。解決方案是確保每個任務(wù)里都有阻塞操作vTaskDelay、等待隊列、等待信號量等。檢查空閑任務(wù)是否活著。FreeRTOS會創(chuàng)建一個空閑任務(wù)優(yōu)先級為0它負責(zé)回收被刪除任務(wù)的資源。如果你在做“刪除任務(wù)”操作且刪除后沒有讓出CPU空閑任務(wù)永遠得不到執(zhí)行被刪除任務(wù)的內(nèi)存就無法釋放長時間運行后內(nèi)存耗盡。這不是立刻表現(xiàn)出來的問題而是“運行一段時間后系統(tǒng)越來越慢”的隱藏問題。還要檢查是否啟用了搶占式調(diào)度。FreeRTOSConfig.h里configUSE_PREEMPTION如果配置為0系統(tǒng)就變成協(xié)作式調(diào)度任務(wù)只有主動讓出CPU才會切換。這種情況下高優(yōu)先級任務(wù)也不會搶占低優(yōu)先級任務(wù)表現(xiàn)就是“任務(wù)都正常但切換很慢”。學(xué)習(xí)階段最好保持搶占式配置為1。7.4 快速定位問題的三板斧遇到問題先別慌按順序來第一板斧檢查返回值。xTaskCreate會返回pdPASS1或錯誤碼。代碼里加上返回值判斷一旦創(chuàng)建失敗馬上點亮錯誤LED或打印信息問題范圍立刻縮小。第二板斧打開斷言。FreeRTOS內(nèi)部大量使用configASSERT()宏默認是空的但你可以在FreeRTOSConfig.h里讓它做點事#define configASSERT(x) if((x) 0) { taskDISABLE_INTERRUPTS(); while(1); }這樣一旦某個條件不滿足比如在錯誤的中斷優(yōu)先級里調(diào)用了API系統(tǒng)會disable中斷并死循環(huán)調(diào)試時通過查看程序卡死的位置能最快定位是哪個條件失敗。配合串口打印當(dāng)前Tick值排查效率提高一個量級。第三板斧用vTaskList和vTaskGetRunTimeStats看運行情況。這兩個API可以打印所有任務(wù)的狀態(tài)、優(yōu)先級、棧剩余空間和CPU占用率。前提是configUSE_TRACE_FACILITY和configUSE_STATS_FORMATTING_FUNCTIONS要打開。把結(jié)果用串口發(fā)出來系統(tǒng)內(nèi)部什么狀態(tài)一目了然。這個工具對排查“任務(wù)莫名其妙不跑”的問題極其好用。8. 移植完成后的擴展方向走到這一步FreeRTOS已經(jīng)在STM32上跑起來了多任務(wù)也正常切換了。但這個項目只能算“邁入門檻”真正的價值在于用起來。根據(jù)自己的進度可以考慮這幾個方向。第一個方向加信號量和隊列做真正的任務(wù)間通信。比如一個任務(wù)采集傳感器數(shù)據(jù)通過隊列發(fā)給另一個任務(wù)處理并顯示。這是RTOS項目最典型的架構(gòu)能解決裸機開發(fā)里“全局變量滿天飛”的老大難問題。第二個方向加互斥鎖保護共享資源。比如兩個任務(wù)都要往串口打印日志不加保護時會出現(xiàn)打印內(nèi)容互相穿插的亂碼這就是典型的臨界區(qū)競爭問題。用互斥鎖或關(guān)中斷的方式保護打印就整整齊齊的了。第三個方向用事件標(biāo)志組做任務(wù)同步。一個任務(wù)等待多個事件比如“按鍵被按下”和“定時器超時”兩個條件都滿足才執(zhí)行某操作事件標(biāo)志組就是為這種場景設(shè)計的。這些都值得自己動手試一遍。再往后要做真正的產(chǎn)品級系統(tǒng)還得學(xué)會裁剪內(nèi)核把用不到的功能關(guān)掉降低Flash占用、調(diào)整調(diào)度策略時間片輪轉(zhuǎn)和優(yōu)先級搶占的配合、管理低功耗模式Tickless Mode等等。FreeRTOS移植這件事本質(zhì)上不是背步驟而是建立一套對“操作系統(tǒng)如何管理任務(wù)”的心智模型。我見過不少同行移植很熟練但問他“為什么關(guān)中斷能保護臨界區(qū)”又說不清楚。這種人換個平臺照樣抓瞎。所以我的建議是跑通這個項目后多花點時間看tasks.c的源碼把它當(dāng)成一本活教材來讀收獲遠大于再抄十個例程。在實際操作中我最想提醒你的一點隨身準備一塊真實的開發(fā)板哪怕是最便宜的最小系統(tǒng)板也比Proteus靠譜得多。仿真能幫你入門、替你省下買一堆元件試錯的時間但真要理解FreeRTOS的精髓——比如精確的時序、中斷的實時響應(yīng)、內(nèi)存管理的微妙之處——還得靠真家伙說話。學(xué)完這套再去接觸LVGL、TCP/IP協(xié)議棧這些基于RTOS的組件你會發(fā)現(xiàn)自己上手速度快得多。