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