035、FreeRTOS与实时性性能测试（最坏执行时间分析）
一、从一次深夜报警说起
上个月在工厂现场调试一台基于STM32的物料分拣设备，凌晨三点突然收到报警：传送带卡料，电机堵转。查看日志发现，任务响应时间在某个时刻从平时的2ms飙升至200ms——直接导致PID控制环失控。当时第一反应是“中断被关了？”或是“栈溢出了？”，但最终定位到问题却更隐蔽：一个不起眼的日志打印函数，在队列满的时候调用了vTaskDelay()，而它的最坏执行时间（WCET）在极端情况下远超设计预期。
这件事让我重新审视了FreeRTOS项目的实时性测试方法。实时系统不怕“平均性能好”，就怕“最坏情况没算准”。
二、WCET到底是什么？为什么FreeRTOS项目必须测它？
最坏执行时间（Worst-Case Execution Time, WCET）不是“跑一千次取最大值”那么简单。它指的是在指定硬件平台上，一段代码在所有可能输入、所有可能硬件状态、所有可能中断干扰下的最长执行时间。对于FreeRTOS这类实时内核，任务切换时间、中断延迟、队列操作、信号量获取等关键路径的WCET，直接决定了系统能否满足deadline。
很多工程师习惯用逻辑分析仪抓一下波形，看到“大部分情况下任务切换在10us内”就放心了。这其实埋了大雷——你可能没触发到那个让Cache全线失效的DMA传输，也没遇到所有高优先级任务同时就绪的“完美风暴”。
