1. 為什么要把FreeRTOS搬到GD32上1.1 從裸機到RTOS的真實痛點很多做MCU開發(fā)的朋友一開始都是在GD32或者STM32這類Cortex-M內(nèi)核的單片機上跑裸機程序。裸機開發(fā)的好處是簡單直接一個while(1)大循環(huán)加上幾個中斷小項目跑得挺歡。但項目一旦復雜起來比如要同時處理串口協(xié)議解析、按鍵掃描、LCD刷新、傳感器采集、數(shù)據(jù)存儲這幾件事裸機就開始捉襟見肘了。你不得不用各種狀態(tài)機和延時來拼湊代碼越寫越亂一個地方改動了另一個地方就出問題。我印象特別深的一次做一個帶LCD顯示的工業(yè)控制器主循環(huán)里要刷屏、要讀編碼器、要跑Modbus從站、還要做PID運算。裸機方案下刷屏的時候編碼器脈沖就丟了PID周期也不穩(wěn)定。后來上了FreeRTOS把每個任務(wù)拆開給不同的優(yōu)先級問題一下就清晰了。這也是為什么越來越多的GD32項目開始引入FreeRTOS——它幫你把并發(fā)的復雜度從應(yīng)用層轉(zhuǎn)移到了內(nèi)核層你只需要關(guān)心任務(wù)之間的邏輯關(guān)系。GD32作為國產(chǎn)Cortex-M3/M4的主力芯片和STM32在寄存器層面高度相似但又有自己的外設(shè)差異。把FreeRTOS移植到GD32上本質(zhì)上就是讓FreeRTOS的調(diào)度器、任務(wù)切換、系統(tǒng)節(jié)拍這些核心機制能夠在GD32的硬件上正確跑起來。聽起來好像只是改幾個宏定義但實際操作中從時鐘配置到中斷優(yōu)先級從堆棧對齊到SysTick接管每一步都有坑。1.2 移植前你需要準備什么先說硬件和軟件環(huán)境。硬件方面一塊GD32F303或者GD32F103的開發(fā)板是最常見的起點這兩款芯片在社區(qū)里資料最多踩坑的人也最多遇到問題好查。調(diào)試器用J-Link或者GD-Link都行J-Link的兼容性更好一些尤其是在Keil下面用SWD模式調(diào)試的時候。軟件方面Keil MDK是大多數(shù)人的首選版本建議用Keil 5.36以上太老的版本對GD32的器件支持包兼容性不好。你需要安裝GigaDevice的器件支持包這個在Keil的Pack Installer里可以直接下載或者去官網(wǎng)下載離線包手動安裝。FreeRTOS的源碼直接從官網(wǎng)或者GitHub拉最新穩(wěn)定版就行我一般用FreeRTOSv202112.00這個版本穩(wěn)定且資料多。注意不要用Keil自帶的FreeRTOS中間件版本那個版本往往比較老而且和官方源碼在目錄結(jié)構(gòu)上有差異后期排查問題的時候容易混淆。另外你需要一個能正常編譯的GD32裸機工程模板。這個模板應(yīng)該包含啟動文件、系統(tǒng)時鐘配置、GPIO驅(qū)動這些基礎(chǔ)內(nèi)容。如果你還沒有建議先用GD32的官方固件庫建立一個標準工程確保LED能閃、串口能打印然后再往上加FreeRTOS。這個順序很重要不要一上來就把FreeRTOS塞進去出了問題你分不清是裸機工程本身有問題還是移植有問題。1.3 移植工作的整體思路移植FreeRTOS到GD32核心工作可以拆成三塊第一塊是文件結(jié)構(gòu)的組織把FreeRTOS的源碼文件正確地加入到Keil工程里第二塊是配置文件的編寫也就是FreeRTOSConfig.h這個文件決定了FreeRTOS在你這顆芯片上怎么跑第三塊是硬件相關(guān)的接口適配主要是SysTick中斷、PendSV中斷和SVC中斷這三個它們是FreeRTOS任務(wù)切換的硬件基礎(chǔ)。這三塊里面第一塊是體力活第二塊是腦力活第三塊是技術(shù)活。很多人移植失敗問題往往出在第二塊和第三塊。FreeRTOSConfig.h里的每一個宏定義都有它的作用配錯了輕則功能異常重則直接HardFault。而三個中斷的優(yōu)先級配置如果和GD32的中斷優(yōu)先級分組不匹配任務(wù)切換就會出問題。我個人的習慣是先把FreeRTOS的源碼文件按照功能分組放到工程目錄里然后在Keil里建對應(yīng)的Group這樣結(jié)構(gòu)清晰后期升級FreeRTOS版本的時候也方便替換。配置文件單獨放在一個User目錄下和GD32的固件庫配置放在一起便于統(tǒng)一管理。2. FreeRTOS源碼文件組織與Keil工程配置2.1 源碼目錄的合理劃分FreeRTOS的源碼包解壓出來之后文件很多但真正需要加入到工程里的其實就那么幾個。我的做法是在工程根目錄下建一個FreeRTOS文件夾里面再分三個子目錄Source、Portable和Config。Source目錄放FreeRTOS的核心源碼包括tasks.c、queue.c、list.c、timers.c、event_groups.c、stream_buffer.c、croutine.c這幾個文件。其中tasks.c和queue.c是必須的timers.c如果你要用軟件定時器就得加event_groups.c和stream_buffer.c看你的項目需求croutine.c是協(xié)程功能一般用不到可以不加。Portable目錄放和編譯器、芯片架構(gòu)相關(guān)的文件。對于Keil MDK加上Cortex-M3/M4的組合你需要的是Portable/RVDS/ARM_CM3或者ARM_CM4F這個目錄下的port.c和portmacro.h。注意ARM_CM4F是帶浮點單元的版本如果你用的是GD32F303這類帶FPU的芯片并且任務(wù)里要用浮點運算就選CM4F如果是GD32F103這類沒有FPU的就選CM3。選錯了編譯能過但運行的時候浮點上下文保存會出問題。Config目錄放FreeRTOSConfig.h這個文件不是源碼包里現(xiàn)成的需要你自己寫或者從Demo里改。我建議從FreeRTOS源碼包里Demo/CORTEX_STM32F103_Keil這個目錄下找一個接近的配置作為起點然后根據(jù)GD32的實際情況修改。內(nèi)存管理方面FreeRTOS提供了heap_1到heap_5五種方案。heap_1最簡單只能分配不能釋放heap_2支持釋放但不合并相鄰空閑塊heap_4支持釋放和合并是最常用的heap_5支持多塊不連續(xù)內(nèi)存區(qū)域。對于GD32項目我一般直接用heap_4兼顧了功能和 simplicity。對應(yīng)的文件是Portable/MemMang/heap_4.c。2.2 Keil工程里的分組與路徑設(shè)置在Keil里我通常會建三個GroupFreeRTOS_Core、FreeRTOS_Port和FreeRTOS_Config。FreeRTOS_Core里放tasks.c、queue.c、list.c、timers.c這些核心文件FreeRTOS_Port里放port.c和heap_4.cFreeRTOS_Config里放FreeRTOSConfig.h。這里有一個容易忽略的點頭文件的包含路徑。你需要在Keil的Options for Target - C/C - Include Paths里把FreeRTOS/Source/include、FreeRTOS/Portable/RVDS/ARM_CM3或CM4F、FreeRTOS/Config這三個路徑都加進去。少了任何一個編譯的時候都會報找不到頭文件的錯誤。還有一個細節(jié)FreeRTOS的源碼文件里會包含一些FreeRTOS.h、task.h這樣的頭文件這些頭文件又依賴于FreeRTOSConfig.h。所以FreeRTOSConfig.h所在的路徑必須在包含路徑里而且這個文件的名字不能改必須是FreeRTOSConfig.h因為源碼里是硬編碼引用的。實操心得在Keil里添加文件的時候建議用“Add Existing Files to Group”的方式把文件從工程目錄里添加進來而不是直接復制到Keil的默認目錄。這樣工程目錄結(jié)構(gòu)清晰換電腦或者分享給同事的時候直接把整個工程文件夾打包就行不會出現(xiàn)路徑丟失的問題。2.3 編譯選項的調(diào)整GD32和STM32一樣都是Cortex-M內(nèi)核所以編譯選項上基本一致。在Keil的Target選項中需要確認幾點一是芯片型號選對比如GD32F303ZE二是ROM和RAM的起始地址和大小要和芯片手冊一致三是如果用了FPU要在C/C選項卡里把Floating Point Hardware設(shè)為Single Precision。另外FreeRTOS的port.c里有一些內(nèi)嵌匯編Keil的編譯器對這些匯編的語法支持是沒問題的但如果你開了很高的優(yōu)化等級有時候會出現(xiàn)一些奇怪的問題。我一般調(diào)試階段用-O0發(fā)布的時候用-O2-O3不太建議FreeRTOS的某些臨界區(qū)代碼在-O3下可能會被優(yōu)化出問題。還有一個重要的編譯選項是__MICROLIB。如果你在Target里勾了Use MicroLIB那么printf重定向會簡單很多但MicroLIB和FreeRTOS本身沒有沖突。不過要注意MicroLIB不支持某些標準庫功能如果你的項目里用了這些功能就不要勾。3. FreeRTOSConfig.h配置文件的逐項拆解3.1 基礎(chǔ)調(diào)度相關(guān)配置FreeRTOSConfig.h是整個移植過程中最需要仔細對待的文件。我把它里面的配置項分成幾類第一類是基礎(chǔ)調(diào)度相關(guān)的。configUSE_PREEMPTION這個宏決定是搶占式調(diào)度還是協(xié)作式調(diào)度。搶占式調(diào)度下高優(yōu)先級任務(wù)就緒時會立刻搶占低優(yōu)先級任務(wù)協(xié)作式調(diào)度下任務(wù)必須主動讓出CPU才會切換。絕大多數(shù)項目都用搶占式設(shè)為1。configUSE_TIME_SLICING是時間片輪轉(zhuǎn)當多個任務(wù)優(yōu)先級相同時每個任務(wù)輪流執(zhí)行一個tick。這個一般也設(shè)為1除非你有特殊需求。configCPU_CLOCK_HZ這個宏要填GD32的系統(tǒng)時鐘頻率。比如GD32F303跑到120MHz這里就填120000000。這個值必須和實際的系統(tǒng)時鐘一致否則FreeRTOS的延時和超時都會不準。configTICK_RATE_HZ是系統(tǒng)節(jié)拍頻率一般設(shè)為1000也就是1ms一個tick。這個值決定了FreeRTOS的時間精度。設(shè)得太高中斷開銷大設(shè)得太低延時精度差。1000Hz是個比較平衡的選擇。configMAX_PRIORITIES是最大任務(wù)優(yōu)先級數(shù)FreeRTOS里優(yōu)先級數(shù)值越大優(yōu)先級越高。這個值根據(jù)你的項目需要來設(shè)一般設(shè)個8到16就夠了。設(shè)得太大浪費RAM因為每個優(yōu)先級都要維護一個就緒列表。configMINIMAL_STACK_SIZE是空閑任務(wù)的堆棧大小單位是字word不是字節(jié)。在Cortex-M3上一個字是4字節(jié)。這個值一般設(shè)128也就是512字節(jié)。如果你的空閑任務(wù)里掛了鉤子函數(shù)可能要適當加大。3.2 內(nèi)存管理與鉤子函數(shù)配置configTOTAL_HEAP_SIZE是FreeRTOS堆的總大小單位是字節(jié)。這個值取決于你創(chuàng)建多少個任務(wù)、隊列、信號量。每個任務(wù)需要一塊任務(wù)控制塊TCB和一塊堆?？臻g。TCB大概占100字節(jié)左右堆棧大小取決于任務(wù)里用了多少局部變量和函數(shù)調(diào)用深度。我一般會先給一個保守的值比如20KB然后運行起來之后調(diào)用xPortGetFreeHeapSize()看看還剩多少再調(diào)整。如果堆不夠創(chuàng)建任務(wù)的時候會返回失敗或者直接進HardFault。configUSE_IDLE_HOOK和configUSE_TICK_HOOK分別是空閑任務(wù)鉤子和節(jié)拍鉤子?？臻e鉤子適合放一些低優(yōu)先級的后臺處理比如喂狗節(jié)拍鉤子適合做系統(tǒng)級的定時統(tǒng)計。這兩個鉤子函數(shù)如果啟用了你必須自己實現(xiàn)vApplicationIdleHook()和vApplicationTickHook()否則鏈接會報錯。configUSE_MALLOC_FAILED_HOOK是內(nèi)存分配失敗鉤子建議啟用。當pvPortMalloc返回NULL的時候會調(diào)用vApplicationMallocFailedHook()你可以在這里打印信息或者點亮錯誤燈方便定位問題。configCHECK_FOR_STACK_OVERFLOW是堆棧溢出檢測這個強烈建議啟用。它有兩個檢測模式模式1在任務(wù)切換時檢查堆棧指針是否越界模式2在任務(wù)切換時檢查堆棧末尾的標記值是否被改寫。模式2更可靠但開銷稍大。啟用之后如果檢測到溢出會調(diào)用vApplicationStackOverflowHook()你可以在里面打印出問題的任務(wù)名。3.3 中斷優(yōu)先級與硬件相關(guān)配置configKERNEL_INTERRUPT_PRIORITY和configMAX_SYSCALL_INTERRUPT_PRIORITY這兩個宏是移植中最容易出錯的地方。Cortex-M3/M4的中斷優(yōu)先級寄存器是8位的但GD32一般只實現(xiàn)了高4位低4位是0。FreeRTOS的配置宏需要把優(yōu)先級值左移到高4位。比如configKERNEL_INTERRUPT_PRIORITY一般設(shè)為15最低優(yōu)先級左移4位就是0xF0。configMAX_SYSCALL_INTERRUPT_PRIORITY一般設(shè)為5左移4位就是0x50。這個configMAX_SYSCALL_INTERRUPT_PRIORITY的含義是優(yōu)先級數(shù)值高于這個值也就是優(yōu)先級更低的中斷可以安全地調(diào)用FreeRTOS的API函數(shù)優(yōu)先級數(shù)值低于這個值優(yōu)先級更高的中斷不能調(diào)用FreeRTOS的API因為它們不會被FreeRTOS的臨界區(qū)屏蔽。在GD32的中斷優(yōu)先級分組里一般用NVIC_PriorityGroup_4也就是所有位都用于搶占優(yōu)先級沒有子優(yōu)先級。這樣配置最簡單也最不容易出錯。configLIBRARY_LOWEST_INTERRUPT_PRIORITY和configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY這兩個宏是庫函數(shù)層面的值分別對應(yīng)上面的兩個宏但不需要左移。它們主要用于NVIC_SetPriority()這樣的庫函數(shù)調(diào)用。注意GD32的中斷優(yōu)先級數(shù)值越小優(yōu)先級越高這和FreeRTOS的任務(wù)優(yōu)先級正好相反。任務(wù)優(yōu)先級是數(shù)值越大越高。這個差異在配置中斷的時候一定要搞清楚否則會出現(xiàn)中斷嵌套混亂的問題。4. 硬件接口適配SysTick、PendSV與SVC4.1 SysTick中斷的接管FreeRTOS需要一個周期性的系統(tǒng)節(jié)拍來驅(qū)動任務(wù)調(diào)度和延時。在Cortex-M上這個節(jié)拍通常由SysTick定時器產(chǎn)生。SysTick是內(nèi)核外設(shè)GD32和STM32的SysTick寄存器完全兼容。在裸機工程里SysTick一般被用來做延時函數(shù)比如delay_ms()。移植FreeRTOS的時候你需要把SysTick的配置從裸機代碼里移除交給FreeRTOS來管理。具體來說FreeRTOS的port.c里已經(jīng)實現(xiàn)了xPortSysTickHandler()你只需要在啟動文件或者中斷向量表里把SysTick_Handler指向這個函數(shù)就行。在Keil的啟動文件startup_gd32f30x.s里SysTick_Handler是一個弱符號你可以自己在C文件里重新定義。我一般會在FreeRTOSConfig.h里加上這樣一行#define xPortSysTickHandler SysTick_Handler然后在port.c里xPortSysTickHandler就是實際的中斷服務(wù)函數(shù)。這樣啟動文件里的弱符號會被覆蓋SysTick中斷就會進入FreeRTOS的處理流程。SysTick的 reload 值由FreeRTOS根據(jù)configCPU_CLOCK_HZ和configTICK_RATE_HZ自動計算你不需要手動設(shè)置。計算方式是reload configCPU_CLOCK_HZ / configTICK_RATE_HZ - 1。比如120MHz的時鐘1000Hz的節(jié)拍reload就是119999。4.2 PendSV與SVC的優(yōu)先級設(shè)置PendSV和SVC是Cortex-M內(nèi)核的兩個異常FreeRTOS用它們來實現(xiàn)任務(wù)切換。PendSV是可掛起的異常FreeRTOS在需要切換任務(wù)的時候會把PendSV掛起等所有高優(yōu)先級中斷處理完之后再進入PendSV處理任務(wù)切換。SVC是系統(tǒng)服務(wù)調(diào)用FreeRTOS在啟動第一個任務(wù)的時候會用到。這兩個異常的優(yōu)先級設(shè)置非常關(guān)鍵。PendSV的優(yōu)先級必須設(shè)為最低也就是數(shù)值最大。SVC的優(yōu)先級一般也設(shè)為最低或者比PendSV稍高一點。在FreeRTOS的port.c里vPortSVCHandler和xPortPendSVHandler這兩個函數(shù)已經(jīng)實現(xiàn)了異常處理邏輯你只需要在啟動文件里把SVC_Handler和PendSV_Handler指向它們。在FreeRTOSConfig.h里configKERNEL_INTERRUPT_PRIORITY這個宏就是用來設(shè)置PendSV和SysTick的優(yōu)先級的。前面說了它一般設(shè)為15左移4位也就是0xF0。這個值會被寫入到NVIC的PendSV和SysTick優(yōu)先級寄存器里。實操心得如果你在GD32上用了其他中斷比如串口中斷、定時器中斷并且這些中斷里要調(diào)用FreeRTOS的API比如xQueueSendFromISR那么這些中斷的優(yōu)先級必須不高于configMAX_SYSCALL_INTERRUPT_PRIORITY。否則會出現(xiàn)中斷里調(diào)用API導致系統(tǒng)崩潰的問題。我一般把要用FreeRTOS API的中斷優(yōu)先級設(shè)為6或7留出足夠的余量。4.3 啟動第一個任務(wù)的流程FreeRTOS啟動調(diào)度器的函數(shù)是vTaskStartScheduler()。這個函數(shù)會創(chuàng)建空閑任務(wù)和定時器任務(wù)如果啟用了軟件定時器然后配置SysTick最后調(diào)用xPortStartScheduler()。xPortStartScheduler()里會設(shè)置PendSV和SysTick的優(yōu)先級然后觸發(fā)SVC異常。SVC異常的處理函數(shù)vPortSVCHandler()會從就緒列表里找到最高優(yōu)先級的任務(wù)恢復它的上下文然后跳轉(zhuǎn)到任務(wù)的入口函數(shù)。這個過程涉及到一堆匯編代碼你不需要完全看懂但要知道它的作用。在GD32上這個流程和STM32完全一樣因為都是Cortex-M內(nèi)核。唯一需要注意的是GD32的啟動文件里SVC_Handler和PendSV_Handler的名字可能和STM32略有不同你要根據(jù)實際的啟動文件來調(diào)整。啟動第一個任務(wù)之后FreeRTOS就進入了正常的調(diào)度循環(huán)。SysTick每隔1ms觸發(fā)一次檢查是否有任務(wù)需要喚醒或者切換。如果有更高優(yōu)先級的任務(wù)就緒PendSV會被掛起等SysTick處理完之后執(zhí)行任務(wù)切換。5. 常見問題排查與實戰(zhàn)避坑指南5.1 編譯鏈接階段的典型錯誤移植過程中編譯鏈接階段的錯誤是最容易解決的因為編譯器會直接告訴你哪里有問題。最常見的幾個錯誤我整理了一下錯誤信息原因解決方法undefined symbol xPortSysTickHandler沒有把SysTick_Handler映射到FreeRTOS的處理函數(shù)在FreeRTOSConfig.h里加#define xPortSysTickHandler SysTick_Handlerundefined symbol vApplicationIdleHook啟用了空閑鉤子但沒有實現(xiàn)實現(xiàn)vApplicationIdleHook()函數(shù)或者把configUSE_IDLE_HOOK設(shè)為0undefined symbol vApplicationStackOverflowHook啟用了堆棧溢出檢測但沒有實現(xiàn)鉤子實現(xiàn)鉤子函數(shù)或者關(guān)閉configCHECK_FOR_STACK_OVERFLOWcannot open source input file FreeRTOS.h頭文件包含路徑?jīng)]設(shè)對在Keil的Include Paths里加上FreeRTOS/Source/includeL6406E: No space in execution regions堆或者棧太大超出了RAM減小configTOTAL_HEAP_SIZE或者任務(wù)堆棧大小還有一個比較隱蔽的錯誤是重復定義。比如你的裸機工程里已經(jīng)有一個SysTick_HandlerFreeRTOS的port.c里也有一個鏈接的時候就會報重復定義。解決辦法是把裸機工程里的SysTick_Handler刪掉或者改名。5.2 運行階段的HardFault排查HardFault是移植過程中最讓人頭疼的問題因為它的現(xiàn)象往往是程序跑飛了但不知道飛到哪里去了。我總結(jié)了一套排查HardFault的流程基本上能覆蓋大部分情況。第一步在HardFault_Handler里加一個死循環(huán)然后在這個死循環(huán)里打個斷點。程序跑飛之后會停在這里。然后你看Call Stack窗口看看是從哪個函數(shù)跳過來的。如果Call Stack是空的那就看LR寄存器的值找到跳轉(zhuǎn)前的地址。第二步檢查堆棧溢出。如果某個任務(wù)的堆棧太小任務(wù)切換的時候就會踩到別的內(nèi)存區(qū)域?qū)е翲ardFault。啟用configCHECK_FOR_STACK_OVERFLOW之后如果是因為堆棧溢出導致的會先進入vApplicationStackOverflowHook()你可以在里面打印任務(wù)名。第三步檢查中斷優(yōu)先級。如果在一個優(yōu)先級高于configMAX_SYSCALL_INTERRUPT_PRIORITY的中斷里調(diào)用了FreeRTOS的API會導致臨界區(qū)失效進而引發(fā)HardFault。這種情況的典型現(xiàn)象是程序在運行一段時間后隨機崩潰而且崩潰的位置不固定。第四步檢查堆是否夠用。如果configTOTAL_HEAP_SIZE設(shè)得太小創(chuàng)建任務(wù)或者隊列的時候會返回NULL如果你沒有檢查返回值就直接使用就會訪問空指針導致HardFault。我一般會在創(chuàng)建任務(wù)之后檢查一下返回值如果是NULL就打印錯誤信息。避坑技巧在GD32上如果用了FPU并且任務(wù)里做了浮點運算一定要確保port.c用的是ARM_CM4F版本而不是ARM_CM3版本。用錯了版本浮點寄存器的上下文不會被保存任務(wù)切換之后浮點運算結(jié)果就會錯亂嚴重的時候直接HardFault。5.3 任務(wù)調(diào)度異常的調(diào)試方法有時候程序沒有HardFault但任務(wù)調(diào)度不正常比如某個任務(wù)一直不執(zhí)行或者延時不準。這類問題一般和配置有關(guān)。如果某個任務(wù)一直不執(zhí)行先檢查它的優(yōu)先級是不是太低被其他高優(yōu)先級任務(wù)一直搶占。FreeRTOS是搶占式調(diào)度如果有一個高優(yōu)先級任務(wù)一直在跑不讓出CPU低優(yōu)先級任務(wù)就永遠得不到執(zhí)行。解決辦法是在高優(yōu)先級任務(wù)里加vTaskDelay()或者taskYIELD()讓出CPU。如果延時不準檢查configCPU_CLOCK_HZ和configTICK_RATE_HZ是否和實際一致。另外如果SysTick的中斷優(yōu)先級設(shè)得太低被其他中斷頻繁打斷也會導致節(jié)拍丟失延時變長。如果任務(wù)切換的時候串口打印亂碼可能是任務(wù)堆棧太小導致局部變量被覆蓋?？梢栽囍讶蝿?wù)堆棧加大一倍看看問題是否消失。還有一個常見問題是在中斷里調(diào)用了非FromISR版本的API。比如在串口中斷里調(diào)用了xQueueSend()而不是xQueueSendFromISR()這會導致中斷里的操作破壞了就緒列表的一致性進而引發(fā)調(diào)度異常。這個問題的現(xiàn)象是程序在中斷頻繁觸發(fā)的時候隨機崩潰。5.4 內(nèi)存優(yōu)化與堆棧大小的確定FreeRTOS的RAM占用主要來自三塊內(nèi)核對象TCB、就緒列表、隊列等、任務(wù)堆棧、FreeRTOS堆。在GD32F103這類RAM只有20KB的芯片上內(nèi)存優(yōu)化就很重要了。任務(wù)堆棧大小的確定我一般用兩種方法。一種是靜態(tài)估算看任務(wù)里最大的函數(shù)調(diào)用深度加上局部變量的大小再留50%的余量。另一種是動態(tài)測量先把堆棧設(shè)大一點然后調(diào)用uxTaskGetStackHighWaterMark()看看歷史最小剩余量再根據(jù)這個值來調(diào)整。比如一個任務(wù)堆棧設(shè)了512字2KB運行一段時間后HighWaterMark返回400說明歷史最多用了112字那么堆?？梢詼p到256字左右留一倍余量。configTOTAL_HEAP_SIZE的確定可以用xPortGetFreeHeapSize()來監(jiān)控。在系統(tǒng)穩(wěn)定運行之后看看還剩多少堆如果剩余很多可以適當減小如果剩余很少就要加大或者檢查是否有內(nèi)存泄漏。實操心得在GD32F103這種小RAM芯片上建議把configUSE_TIMERS設(shè)為0不用軟件定時器這樣可以省掉定時器任務(wù)的堆棧和隊列。軟件定時器的功能可以用硬件定時器加任務(wù)通知來替代更省資源。6. 移植完成后的驗證與功能擴展6.1 基礎(chǔ)功能驗證清單移植完成之后不要急著往上加應(yīng)用代碼先做一輪基礎(chǔ)功能驗證。我一般會寫一個簡單的測試程序創(chuàng)建三個任務(wù)一個任務(wù)每秒翻轉(zhuǎn)一次LED一個任務(wù)每500ms通過串口打印一條信息一個任務(wù)每2秒通過串口打印堆的使用情況。這三個任務(wù)跑起來之后觀察LED的閃爍頻率是否準確串口打印的時間間隔是否穩(wěn)定堆的使用情況是否有異常變化。如果這些都正常說明FreeRTOS的調(diào)度、延時、內(nèi)存管理都工作正常。然后測試任務(wù)間的通信。創(chuàng)建一個隊列一個任務(wù)往隊列里發(fā)數(shù)據(jù)另一個任務(wù)從隊列里收數(shù)據(jù)驗證隊列的發(fā)送和接收是否正常。再測試一下信號量一個任務(wù)釋放信號量另一個任務(wù)獲取信號量驗證同步機制是否正常。最后測試中斷和任務(wù)的交互。在串口中斷里用xQueueSendFromISR往隊列里發(fā)數(shù)據(jù)在任務(wù)里接收驗證中斷安全的API是否正常工作。6.2 從移植到實戰(zhàn)的進階路線基礎(chǔ)驗證通過之后就可以開始把FreeRTOS用到實際項目里了。我的建議是先從簡單的多任務(wù)架構(gòu)開始比如把原來的裸機大循環(huán)拆成幾個獨立的任務(wù)每個任務(wù)負責一個功能模塊任務(wù)之間用隊列或者信號量通信。然后逐步引入更高級的功能。比如用事件組來管理多個任務(wù)的同步用任務(wù)通知來替代二值信號量以提高效率用流緩沖區(qū)來處理串口的不定長數(shù)據(jù)。如果項目里有LCD顯示可以考慮移植LVGL。LVGL本身是單線程的但可以把它放在一個獨立的任務(wù)里通過消息隊列接收其他任務(wù)的顯示請求。這樣顯示刷新不會阻塞其他任務(wù)界面也會更流暢。如果項目里有網(wǎng)絡(luò)通信GD32加上LWIP協(xié)議?？梢园丫W(wǎng)絡(luò)處理放在一個高優(yōu)先級任務(wù)里協(xié)議解析放在另一個任務(wù)里通過隊列傳遞數(shù)據(jù)包。這樣網(wǎng)絡(luò)收發(fā)的實時性會好很多。6.3 性能調(diào)優(yōu)的幾個方向FreeRTOS在GD32上跑起來之后如果覺得性能不夠可以從幾個方向調(diào)優(yōu)。一是調(diào)整configTICK_RATE_HZ。如果項目對延時精度要求不高可以把節(jié)拍從1000Hz降到100Hz這樣SysTick中斷的開銷會小很多CPU有更多時間跑任務(wù)。二是優(yōu)化任務(wù)優(yōu)先級分配。把實時性要求高的任務(wù)設(shè)為高優(yōu)先級把后臺處理任務(wù)設(shè)為低優(yōu)先級。避免多個任務(wù)設(shè)成同一優(yōu)先級因為同優(yōu)先級任務(wù)會時間片輪轉(zhuǎn)增加切換開銷。三是減少臨界區(qū)的長度。FreeRTOS的API函數(shù)里有些會進入臨界區(qū)關(guān)中斷。如果臨界區(qū)太長會影響中斷響應(yīng)。所以在任務(wù)里調(diào)用API的時候盡量把能放在臨界區(qū)外面的操作放在外面。四是使用任務(wù)通知替代信號量。任務(wù)通知是FreeRTOS里最高效的任務(wù)間通信方式它不需要創(chuàng)建額外的內(nèi)核對象直接操作任務(wù)的TCB。在只需要一對一同步的場景下任務(wù)通知比信號量快很多。五是合理使用DMA。GD32的外設(shè)支持DMA比如串口收發(fā)、SPI傳輸、ADC采樣都可以用DMA。把數(shù)據(jù)搬運的工作交給DMACPU只需要處理DMA完成中斷這樣可以大大減輕任務(wù)的負擔。6.4 從GD32F103到GD32F303的移植差異如果你已經(jīng)在GD32F103上移植好了FreeRTOS想換到GD32F303大部分代碼是可以直接復用的但有幾個地方需要注意。首先是時鐘頻率不同。GD32F103最高72MHzGD32F303最高120MHz。configCPU_CLOCK_HZ要相應(yīng)修改否則延時和節(jié)拍都會不準。其次是FPU。GD32F303帶浮點單元如果你要用浮點運算需要把port.c從ARM_CM3換成ARM_CM4F并且在Keil里開啟FPU支持。GD32F103沒有FPU只能用軟件浮點。然后是中斷向量表。GD32F303的中斷源比GD32F103多啟動文件也不同。移植的時候要確認SVC_Handler、PendSV_Handler、SysTick_Handler這三個異常處理函數(shù)的映射是否正確。最后是RAM大小。GD32F303的RAM一般比GD32F103大configTOTAL_HEAP_SIZE可以適當加大任務(wù)堆棧也可以給得更充裕。我在實際項目里從GD32F103換到GD32F303的時候基本上只改了時鐘配置和FPU相關(guān)的幾個宏其他代碼一行沒動半天就完成了遷移。這也是FreeRTOS這種成熟RTOS的好處硬件相關(guān)的代碼被隔離在port層換芯片的時候只需要改port層和配置文件。最后再分享一個小技巧如果你在Keil里調(diào)試FreeRTOS的時候想看每個任務(wù)的運行狀態(tài)和堆棧使用情況可以安裝一個FreeRTOS的Keil插件或者用SEGGER的SystemView。SystemView可以圖形化地顯示任務(wù)的切換時序、中斷的觸發(fā)情況、隊列的收發(fā)記錄對于分析系統(tǒng)的實時性非常有幫助。我每次做性能優(yōu)化的時候都會先用SystemView跑一遍看看哪里是瓶頸然后再有針對性地調(diào)整。