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利用率，我们可以：

1. 性能瓶颈定位：找出哪个任务或中断服务程序（ISR）是CPU时间的“大户”，进行针对性优化。
2. 系统容量评估：在添加新功能前，评估当前系统的负载余量，判断现有硬件是否还能承受。
3. 电源管理优化：在低功耗应用中，如果发现CPU长期处于低利用率状态，可以考虑让CPU进入睡眠模式（Idle Task Hook），动态调整主频，以节省功耗。
4. 调试与验证：验证任务优先级设置、时间片分配是否合理，系统调度行为是否符合预期。

网上关于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 Functions）：

• portCONFIGURE_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）都是不错的选择。

选型考量：

1. 位数：32位定时器（如TIM2, TIM5）计数范围更大，不易溢出，是首选。如果只有16位定时器，则需要更频繁地处理溢出中断，增加系统复杂度。
2. 时钟源：使用内部时钟（APB总线），确保其频率稳定且已知。
3. 中断：为了处理定时器溢出，我们需要开启更新中断（Update Interrupt）。但切记，这个中断的优先级必须设置为最低（或者在FreeRTOS中，设置为configLIBRARY_LOWEST_INTERRUPT_PRIORITY允许的范围），绝对不能高于FreeRTOS可管理的中断优先级上限（configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY）。否则，在中断中调用FreeRTOS的API（如任务切换）会导致不可预知的问题。
4. 计数方向：设置为向上计数（Upcounter）。
5. 预分频器（PSC）与自动重载值（ARR）：这是关键计算。目标是让定时器每个计数值（Tick）对应一个我们想要的时间单位，比如1微秒(us)或0.5微秒。

计算示例：假设我们使用TIM2（32位），其时钟源APB1 Timer Clocks为84MHz（在F407中，当APB1预分频系数不为1时，定时器时钟会翻倍）。我们希望每个计数对应1us。

• 所需定时器频率 = 1 / 1us = 1MHz。
• 预分频系数（PSC） = 定时器输入时钟 / 所需频率 - 1 = 84MHz / 1MHz - 1 = 83。
• 自动重载值（ARR）设置为最大值0xFFFFFFFF（32位全1），让其自由计数到溢出。

这样，TIM2就会以1us的精度从0计数到约4294秒（约71.5分钟）后溢出。这个溢出周期对于我们的统计来说通常足够长，我们可以在溢出中断里简单地记录溢出次数，与当前计数值组合成一个64位的时间戳。

在CubeMX中的配置步骤：

1. 在Pinout & Configuration标签页，找到Timers，选择一个可用的32位定时器，比如TIM2。
2. 将Clock Source设为Internal Clock。
3. 在Parameter Settings中：
   • Prescaler (PSC - 16 bits value)： 填入计算好的值，例如83。
   • Counter Mode:Up
   • Counter Period (AutoReload Register - 32 bits value):4294967295(即0xFFFFFFFF)
   • auto-reload preload:Enable
4. 在NVIC Settings中，勾选TIM2 global interrupt。
5. 关键一步：设置NVIC中此中断的优先级。假设你的FreeRTOS配置中configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY为5（数字越小优先级越高），那么TIM2的中断优先级必须大于5，例如设为6或7。在CubeMX的System Core > NVIC中，找到TIM2中断，将其优先级（Preemption Priority）设为一个较低的值（如6）。

3.2 FreeRTOS配置与工程生成

接下来配置FreeRTOS本身。

1. 在CubeMX的Middleware and Software Packs中，选择FREERTOS。在Mode下拉框中选择Interface为CMSIS_V2（更现代，功能更全）。
2. 转到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中定义。我们可以在生成代码后手动添加。
3. 其他配置（如TICK_RATE_HZ， 任务栈大小等）根据你的项目需求设置。
4. 生成代码（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; }

关键点解析：

1. 中断优先级：我们之前已经在CubeMX中将TIM2中断优先级设得较低，确保了它不会打断FreeRTOS的核心调度中断（如PendSV， SysTick）。
2. 64位时间戳：timer2OverflowCount（高32位）和TIM2->CNT（低32位）组合成了一个64位的微秒计数器。其最大可表示的时间长达约584,942年，完全够用。
3. 无锁读取：getRuntimeCounterValue函数中的do...while循环是一种经典的“无锁”（Lock-free）同步机制，用于解决“读-改”竞争条件（Read-Modify-Write Race Condition）。它确保了即使在我们读取lowWord的瞬间定时器发生了溢出，我们也能通过重读来获得一个一致的时间快照。这个函数本身很短小，且没有使用任何阻塞机制，因此可以安全地在中断或任务中调用。
4. 单位：由于我们配置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 精度校准与误差来源

你可能会发现，即使所有任务都处于阻塞状态（例如都在调用osDelay），IDLE任务的百分比也不是100%，可能只有99.9%或99.8%。这是正常的，误差主要来自：

1. 统计开销：FreeRTOS在每次任务切换时，需要记录时间戳，这个操作本身会消耗几十到上百个CPU周期。这部分时间被计入了“统计开销”，没有归到任何一个具体任务。它体现在总时间与各任务时间之和的微小差异上。
2. 中断服务程序（ISR）时间：vTaskGetRunTimeStats统计的是任务的运行时间，不包括中断服务程序的执行时间。如果系统中断非常频繁（如高速ADC采样、通信中断），这部分CPU时间不会被统计到任何任务中，也会导致“丢失”一部分时间，使得各任务百分比之和小于100%。
3. 定时器误差：如果PSC配置计算有误，导致每个计数不是精确的1us，那么计算出的绝对时间会有误差，但百分比相对误差较小。

校准建议：为了获得更直观的“CPU利用率”，我们可以将“100% - IDLE任务百分比”近似视为任务层的CPU利用率。而总的CPU利用率还需要加上中断的占比。要测量中断时间，需要更复杂的工具（如系统分析器）或在中断入口/出口打点，这超出了本基础教程的范围。

5.3 常见问题与排查指南

问题1：vTaskGetRunTimeStats输出的百分比总和远大于100%或出现乱码。

• 原因：最可能的原因是portGET_RUN_TIME_COUNTER_VALUE()返回的时间单位不对，或者64位到32位的转换出了问题。FreeRTOS内核假设这个返回值是unsigned long（32位），并且单位与configTICK_RATE_HZ无关，它只是用来计算差值的“计数”。如果我们的定时器跑得太快（比如配置成了每计数0.1us），两次任务切换间的计数值差值可能巨大，导致内核计算溢出。
• 排查：检查getRuntimeCounterValue函数，确保其返回值的“增长速度”合理。可以在一个任务中循环打印这个值，观察它每秒钟增加多少。对于一个1us计时的定时器，1秒应增加大约1,000,000。如果增长过快，调整PSC降低定时器频率。

问题2：统计信息长时间不变，或者IDLE任务时间不增长。

• 原因：高精度定时器没有成功启动或中断未使能。
• 排查：
  1. 用调试器检查TIM2的CNT寄存器是否在递增。
  2. 检查configureTimerForRuntimeStats函数是否被正确调用（在启动调度器前）。
  3. 检查CubeMX中TIM2的NVIC中断是否使能，优先级是否设置正确（不能太高）。
  4. 在TIM2_IRQHandler中设置断点，看溢出中断是否能进入。

问题3：使能运行时间统计后，系统运行变慢甚至出现异常。

• 原因：任务切换频率很高时（例如多个任务时间片很短），每次切换都记录时间戳的开销变得不可忽视。如果portGET_RUN_TIME_COUNTER_VALUE()函数实现得效率不高（例如包含了复杂的计算或临界区保护），会显著增加上下文切换时间。
• 优化：确保getRuntimeCounterValue函数尽可能高效。我们上面实现的版本已经做了无锁优化，通常开销很小。如果确实对性能有极致要求，可以考虑使用STM32的DWT（Data Watchpoint and Trace）单元中的CYCCNT循环计数器来获取时钟周期数，它不需要中断，读取速度极快。但DWT通常需要使能，且其时钟频率与CPU核心频率一致，需要注意溢出周期更短的问题。

问题4：在低功耗模式下统计失效。

• 原因：当CPU进入睡眠或停机模式时，很多外设时钟（包括你用的TIM2）可能会被关闭，导致定时器停止计数。
• 解决：如果需要在低功耗下保持统计，要么选择在低功耗模式下仍然运行的时钟源（如LSI驱动的LPTIM低功耗定时器），要么在进入和退出低功耗模式时，暂停和恢复统计功能（通过停止/启动定时器，并记录暂停时长，在总时间中扣除）。

实现一个准确的CPU利用率统计功能，是深入理解和优化FreeRTOS系统的重要一步。它不再是“感觉”系统卡不卡，而是有了量化的数据支撑。当你下次发现系统响应迟缓时，第一件事就应该是打开这个统计功能，看看究竟是哪个“家伙”在偷偷占用你的CPU时间。