1. 项目缘起为什么要在STM32上折腾CPU利用率做嵌入式开发尤其是用上了FreeRTOS这种实时操作系统之后我们经常会陷入一种“薛定谔的忙”的状态。任务调度器在后台勤勤恳恳地工作各个任务你方唱罢我登场表面上看程序跑得挺欢但作为开发者我们心里其实没底我的CPU到底忙不忙有没有哪个任务偷偷占用了大量时间导致其他高优先级任务响应不及时系统还有多少空闲的算力可以压榨或者是不是已经濒临过载的边缘这些问题在裸机编程时代我们可能靠一个简单的while(1)主循环和几个标志位就能大概感知。但到了多任务并发的RTOS世界调度器接管了CPU的控制权任务的执行变成了一个黑盒。你只知道任务A、B、C都“运行”了但不知道它们各自花了多少时间更不知道CPU在“无所事事”的空闲状态下待了多久。这时候一个准确的CPU利用率指标就像给系统装上了“仪表盘”它能直观地告诉你系统的负载情况是性能优化、资源分配和系统稳定性评估的黄金标准。在STM32这类资源受限的MCU上计算CPU利用率尤其有价值。STM32性能有强有弱从M0内核的几十MHz到M7内核的几百MHz不等但共同点是内存和算力都相对桌面系统紧张。一个设计不当的任务可能会悄无声息地吃掉大量CPU时间导致系统整体响应变慢甚至出现任务饿死Starvation的情况。通过监控CPU利用率我们可以性能瓶颈定位找出哪个任务或中断服务程序ISR是CPU时间的“大户”进行针对性优化。系统容量评估在添加新功能前评估当前系统的负载余量判断现有硬件是否还能承受。电源管理优化在低功耗应用中如果发现CPU长期处于低利用率状态可以考虑让CPU进入睡眠模式Idle Task Hook动态调整主频以节省功耗。调试与验证验证任务优先级设置、时间片分配是否合理系统调度行为是否符合预期。网上关于FreeRTOS CPU利用率的资料不少但很多要么讲得过于理论只提vTaskGetRunTimeStats()这个API要么给的代码片段不完整忽略了在STM32上实现的关键细节比如时基源的选择、溢出处理、数据同步等。更有甚者直接用了不可靠的方法导致计算结果偏差巨大。这篇教程我就结合自己多次在STM32F1、F4、H7系列上的实战经验从原理到代码从配置到踩坑手把手带你实现一个稳定、准确的CPU利用率统计模块。2. 核心原理FreeRTOS如何“窥探”CPU的忙碌与空闲在深入代码之前我们必须搞清楚FreeRTOS计算CPU利用率的底层逻辑。它的核心思想其实非常直观CPU利用率 总时间 - 空闲任务运行时间/ 总时间 * 100%。这里的关键在于“空闲任务”Idle Task。FreeRTOS在启动调度器vTaskStartScheduler()时会自动创建一个优先级最低通常为tskIDLE_PRIORITY的空闲任务。当且仅当所有其他就绪态的任务都执行完毕没有工作需要处理时调度器才会把CPU交给空闲任务。因此空闲任务的运行时间本质上就是CPU“打酱油”的时间。只要我们能够精确地测量出一段时间内空闲任务运行了多久就能反推出CPU忙碌了多久。那么如何测量这个时间呢FreeRTOS提供了两种主要的机制2.1 运行时间统计Run Time Statistics接口这是最常用、最官方的方法。它依赖于一个比FreeRTOS系统时钟Tick精度高得多的时基源。FreeRTOS内核本身只维护一个系统节拍计数器xTickCount其精度由configTICK_RATE_HZ决定通常为1000Hz即1ms。这个精度对于任务调度足够了但对于统计任务在几个微秒内的执行时间就太粗糙了。因此我们需要提供一个外部的、高精度的计时器比如STM32的通用定时器TIM精度达到微秒级并实现以下两个钩子函数Hook FunctionsportCONFIGURE_TIMER_FOR_RUN_TIME_STATS() 用于初始化这个高精度计时器。portGET_RUN_TIME_COUNTER_VALUE() 用于读取这个计时器当前的计数值。FreeRTOS会在每个任务切换的上下文context switch时记录下当前高精度计时器的值。通过对比一个任务被切换出去和再次被切换进来时的时间戳差值就能计算出该任务本次执行的时长。累积起来就得到了每个任务的总运行时间。空闲任务作为普通任务之一其运行时间也被同样记录。启用此功能需要在FreeRTOSConfig.h中配置#define configGENERATE_RUN_TIME_STATS 1 #define configUSE_STATS_FORMATTING_FUNCTIONS 1 #define portCONFIGURE_TIMER_FOR_RUN_TIME_STATS() configureTimerForRuntimeStats() #define portGET_RUN_TIME_COUNTER_VALUE() getRuntimeCounterValue()这里的configureTimerForRuntimeStats和getRuntimeCounterValue需要我们自己根据使用的硬件定时器来实现。2.2 空闲任务钩子函数Idle Task Hook这是一种更轻量级、但精度稍逊的方法。FreeRTOS允许我们设置一个空闲任务钩子函数Idle Hook。每当空闲任务即将运行即CPU进入空闲状态前和结束运行即有更高优先级任务就绪后这个钩子函数都会被调用。我们可以在钩子函数中同样利用一个高精度定时器来打点记录时间。通过计算钩子函数被调用的时间间隔可以近似得到空闲任务每次运行的片段时长累加后得到总空闲时间。这种方法不需要启用完整的运行时间统计配置更简单但获取的是“空闲时间”而非每个任务的详细时间且钩子函数本身的执行时间也会被计入空闲时间需要小心处理。启用此功能需要在FreeRTOSConfig.h中配置#define configUSE_IDLE_HOOK 1然后实现void vApplicationIdleHook( void )函数。对于追求准确性和希望得到每个任务详细运行占比的开发者强烈推荐使用第一种“运行时间统计”方法。本教程也将以此为主要实现路径。3. 实战准备在STM32CubeMX中为FreeRTOS运行时间统计铺路理论清晰了我们开始动手。我以STM32F407VG和STM32CubeMX Keil MDK开发环境为例。其他系列如F1 F7 H7和开发环境如IAR GCC原理相通只需调整对应的定时器和代码。3.1 硬件定时器选型与配置首先我们需要一个高精度、连续计数、不会受FreeRTOS任务调度影响的定时器作为时基源。STM32的通用定时器TIM2, TIM3, TIM4, TIM5...或基本定时器TIM6, TIM7都是不错的选择。选型考量位数32位定时器如TIM2, TIM5计数范围更大不易溢出是首选。如果只有16位定时器则需要更频繁地处理溢出中断增加系统复杂度。时钟源使用内部时钟APB总线确保其频率稳定且已知。中断为了处理定时器溢出我们需要开启更新中断Update Interrupt。但切记这个中断的优先级必须设置为最低或者在FreeRTOS中设置为configLIBRARY_LOWEST_INTERRUPT_PRIORITY允许的范围绝对不能高于FreeRTOS可管理的中断优先级上限configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY。否则在中断中调用FreeRTOS的API如任务切换会导致不可预知的问题。计数方向设置为向上计数Upcounter。预分频器PSC与自动重载值ARR这是关键计算。目标是让定时器每个计数值Tick对应一个我们想要的时间单位比如1微秒(us)或0.5微秒。计算示例假设我们使用TIM232位其时钟源APB1 Timer Clocks为84MHz在F407中当APB1预分频系数不为1时定时器时钟会翻倍。我们希望每个计数对应1us。所需定时器频率 1 / 1us 1MHz。预分频系数PSC 定时器输入时钟 / 所需频率 - 1 84MHz / 1MHz - 1 83。自动重载值ARR设置为最大值0xFFFFFFFF32位全1让其自由计数到溢出。这样TIM2就会以1us的精度从0计数到约4294秒约71.5分钟后溢出。这个溢出周期对于我们的统计来说通常足够长我们可以在溢出中断里简单地记录溢出次数与当前计数值组合成一个64位的时间戳。在CubeMX中的配置步骤在Pinout Configuration标签页找到Timers选择一个可用的32位定时器比如TIM2。将Clock Source设为Internal Clock。在Parameter Settings中Prescaler (PSC - 16 bits value) 填入计算好的值例如83。Counter Mode:UpCounter Period (AutoReload Register - 32 bits value):4294967295(即0xFFFFFFFF)auto-reload preload:Enable在NVIC Settings中勾选TIM2 global interrupt。关键一步设置NVIC中此中断的优先级。假设你的FreeRTOS配置中configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY为5数字越小优先级越高那么TIM2的中断优先级必须大于5例如设为6或7。在CubeMX的System Core NVIC中找到TIM2中断将其优先级Preemption Priority设为一个较低的值如6。3.2 FreeRTOS配置与工程生成接下来配置FreeRTOS本身。在CubeMX的Middleware and Software Packs中选择FREERTOS。在Mode下拉框中选择Interface为CMSIS_V2更现代功能更全。转到Config Parameters选项卡我们需要修改几个关键配置USE_STATS_FORMATTING_FUNCTIONS: 设置为Enabled。这个选项允许我们使用vTaskGetRunTimeStats()这个格式化输出函数。GENERATE_RUN_TIME_STATS: 设置为Enabled。这是启用运行时间统计的总开关。USE_TRACE_FACILITY: 建议也设置为Enabled。它为任务状态信息提供了额外的数据结构支持对运行时间统计有益。找到portCONFIGURE_TIMER_FOR_RUN_TIME_STATS和portGET_RUN_TIME_COUNTER_VALUE。CubeMX可能不会直接显示这两个宏的输入框因为它们通常需要手动在FreeRTOSConfig.h中定义。我们可以在生成代码后手动添加。其他配置如TICK_RATE_HZ 任务栈大小等根据你的项目需求设置。生成代码GENERATE CODE。4. 代码实现构建稳健的64位微秒级时基生成了基础工程后我们开始编写核心的时基获取代码。这部分代码需要我们自己添加主要包含三个文件定时器初始化函数、溢出处理、以及64位时间戳获取函数。4.1 定时器初始化与溢出计数我们在tim.c和tim.h中完善TIM2的初始化并添加溢出处理机制。首先在tim.h中声明必要的变量和函数/* USER CODE BEGIN Includes */ #include stdint.h /* USER CODE END Includes */ /* USER CODE BEGIN Private defines */ extern volatile uint32_t timer2OverflowCount; // TIM2溢出次数计数器 /* USER CODE END Private defines */ /* USER CODE BEGIN Prototypes */ void TIM2_IRQHandler_Callback(void); // 溢出中断回调声明 /* USER CODE END Prototypes */然后在tim.c文件中/* USER CODE BEGIN 0 */ #include cmsis_os.h // 如果需要使用FreeRTOS的临界区保护 volatile uint32_t timer2OverflowCount 0; // 定义在文件顶部 // TIM2全局中断服务函数 void TIM2_IRQHandler(void) { /* USER CODE BEGIN TIM2_IRQn 0 */ if (__HAL_TIM_GET_FLAG(htim2, TIM_FLAG_UPDATE) ! RESET) { if (__HAL_TIM_GET_IT_SOURCE(htim2, TIM_IT_UPDATE) ! RESET) { __HAL_TIM_CLEAR_IT(htim2, TIM_IT_UPDATE); // 溢出计数器加1 timer2OverflowCount; // 注意这里绝对不要调用任何FreeRTOS的API如队列、信号量、任务通知 // 因为这个中断的优先级可能高于configMAX_SYSCALL_INTERRUPT_PRIORITY。 } } /* USER CODE END TIM2_IRQn 0 */ HAL_TIM_IRQHandler(htim2); /* USER CODE BEGIN TIM2_IRQn 1 */ /* USER CODE END TIM2_IRQn 1 */ } // 初始化TIM2用于运行时间统计 void configureTimerForRuntimeStats(void) { HAL_TIM_Base_Start(htim2); // 启动定时器 HAL_TIM_Base_Start_IT(htim2); // 启动定时器中断用于溢出计数 timer2OverflowCount 0; // 清零溢出计数 __HAL_TIM_SET_COUNTER(htim2, 0); // 清零计数器 } // 获取当前的64位运行时间计数器值单位微秒 uint64_t getRuntimeCounterValue(void) { uint32_t highWord, lowWord; uint64_t totalTicks; // 为了防止在读取计数器CNT和溢出计数timer2OverflowCount的瞬间发生溢出 // 我们需要采取保护措施。这里采用“读-校验-重读”的方法。 do { highWord timer2OverflowCount; lowWord __HAL_TIM_GET_COUNTER(htim2); // 读取TIM2当前计数值 // 再次读取溢出计数如果与第一次读取不同说明在读低字时发生了溢出需要重试。 } while (highWord ! timer2OverflowCount); // 组合成64位值高32位是溢出次数低32位是当前计数值。 // 因为我们的定时器每计一次是1us所以这个值就是以微秒为单位的时间。 totalTicks ((uint64_t)highWord 32) | (uint64_t)lowWord; return totalTicks; }关键点解析中断优先级我们之前已经在CubeMX中将TIM2中断优先级设得较低确保了它不会打断FreeRTOS的核心调度中断如PendSV SysTick。64位时间戳timer2OverflowCount高32位和TIM2-CNT低32位组合成了一个64位的微秒计数器。其最大可表示的时间长达约584,942年完全够用。无锁读取getRuntimeCounterValue函数中的do...while循环是一种经典的“无锁”Lock-free同步机制用于解决“读-改”竞争条件Read-Modify-Write Race Condition。它确保了即使在我们读取lowWord的瞬间定时器发生了溢出我们也能通过重读来获得一个一致的时间快照。这个函数本身很短小且没有使用任何阻塞机制因此可以安全地在中断或任务中调用。单位由于我们配置PSC让每个计数等于1us所以getRuntimeCounterValue返回值的单位就是微秒。FreeRTOS内部会用这个值来计算任务运行时间。4.2 链接FreeRTOS配置宏现在我们需要告诉FreeRTOS使用我们刚刚实现的这两个函数。打开FreeRTOSConfig.h文件在文件末尾#endif /* FREERTOS_CONFIG_H */之前添加我们的宏定义。/* USER CODE BEGIN Defines */ // 运行时间统计定时器配置 extern void configureTimerForRuntimeStats(void); extern uint64_t getRuntimeCounterValue(void); #define portCONFIGURE_TIMER_FOR_RUN_TIME_STATS() configureTimerForRuntimeStats() #define portGET_RUN_TIME_COUNTER_VALUE() getRuntimeCounterValue() /* USER CODE END Defines */注意portGET_RUN_TIME_COUNTER_VALUE宏期望返回一个unsigned long类型的值。我们的getRuntimeCounterValue返回的是uint64_t。在32位平台上将一个64位数赋值给32位变量会丢失高32位数据这是一个巨大的坑。FreeRTOS内核内部是用unsigned long来存储这个时间差值的。因此我们的定时器绝对不能配置成在两次任务切换之间就发生溢出即高32位发生变化。这也是为什么我们优先选用32位定时器并将ARR设为最大值以及为什么在getRuntimeCounterValue中要返回64位值但内核只使用低32位的原因。只要低32位不溢出计算就是正确的。如果系统运行时间极长需要考虑在vTaskGetRunTimeStats被调用前定时器低32位已经循环了多次这会影响绝对时间的准确性但对于计算百分比利用率影响不大因为分子分母用的是相同时间基底的差值。4.3 初始化与数据获取在main.c的StartDefaultTask或你创建的第一个任务中在启动调度器之前调用定时器初始化函数。void StartDefaultTask(void *argument) { /* USER CODE BEGIN StartDefaultTask */ // 初始化运行时间统计用的高精度定时器 portCONFIGURE_TIMER_FOR_RUN_TIME_STATS(); /* USER CODE END StartDefaultTask */ // ... 其他初始化代码如创建其他任务 ... osKernelStart(); // 启动内核开始调度 for(;;) { osDelay(1000); // 假设默认任务每1秒打印一次统计信息 printRuntimeStats(); } }然后实现printRuntimeStats函数。这个函数调用FreeRTOS的API来获取并格式化统计信息。#include stdio.h // 如果使用printf void printRuntimeStats(void) { // 缓冲区需要足够大以容纳格式化后的字符串 char pcWriteBuffer[512]; // 获取任务运行时间统计信息 vTaskGetRunTimeStats(pcWriteBuffer); // 输出到串口假设已初始化 printf(\r\n\r\n); printf(Task Runtime Statistics\r\n); printf(\r\n); printf(%s, pcWriteBuffer); printf(\r\n\r\n); }vTaskGetRunTimeStats函数会遍历所有任务计算每个任务的运行时间占总统计时间的百分比并将结果格式化写入提供的缓冲区。总统计时间是从portCONFIGURE_TIMER_FOR_RUN_TIME_STATS()调用后开始累计的。5. 结果解读、校准与常见问题排查烧录程序打开串口助手你应该能看到类似下面的输出 Task Runtime Statistics Task Name Run Time (us) Percentage IDLE 12345678 95.5% Task1 500000 3.8% Task2 100000 0.7% 5.1 如何解读数据IDLE 空闲任务。它的运行时间占比越高说明CPU越“闲”。上例中95.5%的闲置率说明系统负载极低。Task1, Task2 你创建的应用任务。它们的运行时间之和加上IDLE时间应接近100%。百分比反映了该任务对CPU资源的占用情况。Run Time (us) 是该任务自统计开始以来累计占用的CPU时间微秒。这个值是绝对值会一直增长。一个健康的系统空闲任务应该保持一个合理的、非零的百分比。如果空闲任务百分比长期为0%或者你创建的任务百分比异常高说明系统可能过载需要检查是否有任务陷入死循环、优先级设置是否导致高优先级任务独占CPU、或者中断过于频繁。5.2 精度校准与误差来源你可能会发现即使所有任务都处于阻塞状态例如都在调用osDelayIDLE任务的百分比也不是100%可能只有99.9%或99.8%。这是正常的误差主要来自统计开销FreeRTOS在每次任务切换时需要记录时间戳这个操作本身会消耗几十到上百个CPU周期。这部分时间被计入了“统计开销”没有归到任何一个具体任务。它体现在总时间与各任务时间之和的微小差异上。中断服务程序ISR时间vTaskGetRunTimeStats统计的是任务的运行时间不包括中断服务程序的执行时间。如果系统中断非常频繁如高速ADC采样、通信中断这部分CPU时间不会被统计到任何任务中也会导致“丢失”一部分时间使得各任务百分比之和小于100%。定时器误差如果PSC配置计算有误导致每个计数不是精确的1us那么计算出的绝对时间会有误差但百分比相对误差较小。校准建议为了获得更直观的“CPU利用率”我们可以将“100% - IDLE任务百分比”近似视为任务层的CPU利用率。而总的CPU利用率还需要加上中断的占比。要测量中断时间需要更复杂的工具如系统分析器或在中断入口/出口打点这超出了本基础教程的范围。5.3 常见问题与排查指南问题1vTaskGetRunTimeStats输出的百分比总和远大于100%或出现乱码。原因最可能的原因是portGET_RUN_TIME_COUNTER_VALUE()返回的时间单位不对或者64位到32位的转换出了问题。FreeRTOS内核假设这个返回值是unsigned long32位并且单位与configTICK_RATE_HZ无关它只是用来计算差值的“计数”。如果我们的定时器跑得太快比如配置成了每计数0.1us两次任务切换间的计数值差值可能巨大导致内核计算溢出。排查检查getRuntimeCounterValue函数确保其返回值的“增长速度”合理。可以在一个任务中循环打印这个值观察它每秒钟增加多少。对于一个1us计时的定时器1秒应增加大约1,000,000。如果增长过快调整PSC降低定时器频率。问题2统计信息长时间不变或者IDLE任务时间不增长。原因高精度定时器没有成功启动或中断未使能。排查用调试器检查TIM2的CNT寄存器是否在递增。检查configureTimerForRuntimeStats函数是否被正确调用在启动调度器前。检查CubeMX中TIM2的NVIC中断是否使能优先级是否设置正确不能太高。在TIM2_IRQHandler中设置断点看溢出中断是否能进入。问题3使能运行时间统计后系统运行变慢甚至出现异常。原因任务切换频率很高时例如多个任务时间片很短每次切换都记录时间戳的开销变得不可忽视。如果portGET_RUN_TIME_COUNTER_VALUE()函数实现得效率不高例如包含了复杂的计算或临界区保护会显著增加上下文切换时间。优化确保getRuntimeCounterValue函数尽可能高效。我们上面实现的版本已经做了无锁优化通常开销很小。如果确实对性能有极致要求可以考虑使用STM32的DWTData Watchpoint and Trace单元中的CYCCNT循环计数器来获取时钟周期数它不需要中断读取速度极快。但DWT通常需要使能且其时钟频率与CPU核心频率一致需要注意溢出周期更短的问题。问题4在低功耗模式下统计失效。原因当CPU进入睡眠或停机模式时很多外设时钟包括你用的TIM2可能会被关闭导致定时器停止计数。解决如果需要在低功耗下保持统计要么选择在低功耗模式下仍然运行的时钟源如LSI驱动的LPTIM低功耗定时器要么在进入和退出低功耗模式时暂停和恢复统计功能通过停止/启动定时器并记录暂停时长在总时间中扣除。实现一个准确的CPU利用率统计功能是深入理解和优化FreeRTOS系统的重要一步。它不再是“感觉”系统卡不卡而是有了量化的数据支撑。当你下次发现系统响应迟缓时第一件事就应该是打开这个统计功能看看究竟是哪个“家伙”在偷偷占用你的CPU时间。