1、课程导入：TinyML与RTOS结合的性能评估目标

TinyML（微型机器学习）与RTOS（实时操作系统）的结合，正在成为边缘智能设备落地的关键路径。当神经网络模型被部署到Cortex-M、RISC-V等微控制器上时，系统不仅要完成推理计算，还要同时响应传感器中断、通信协议栈、控制回路等实时任务。此时，性能评估不再是“跑个benchmark看帧率”那么简单，而是需要从CPU占用率、任务延迟、栈水位三个维度，建立一套可量化、可追踪、可预警的评估体系。本章作为整个课程的开篇，将明确TinyML+RTOS性能评估的目标边界，厘清三个核心指标的定义与相互关系，并建立后续章节通用的分析框架。

1.1 为什么TinyML系统需要RTOS性能评估

传统的嵌入式裸机开发中，主循环（Super Loop）轮询所有外设和算法，代码简单但实时性差。当引入TinyML后，神经网络推理往往需要数十到数百毫秒的连续计算时间，如果推理过程中无法响应紧急的中断事件（如电机堵转、电池过压、通信超时），轻则功能失效，重则引发安全事故。RTOS通过任务调度、优先级抢占、信号量同步等机制，将推理任务与其他实时任务隔离，但这也带来了新的问题：任务切换开销、优先级反转、栈空间分配不当等，反而可能让系统性能劣化。因此，性能评估不是“可选项”，而是TinyML+RTOS系统从原型走向产品化的必经之路。

1.2 三大核心指标的定义与工程意义

指标名称	定义	工程意义	典型测量方法
CPU占用率	单位时间内CPU执行任务（非空闲）的时间占比	反映系统负载余量，判断是否需要升级硬件或优化算法	空闲任务统计、周期测量、硬件性能计数器
任务延迟	从事件触发到任务完成处理的时间差，包含响应延迟+执行延迟	决定系统能否满足实时性要求（如控制周期、通信超时）	GPIO翻转测量、时间戳记录、逻辑分析仪
栈水位	任务栈已使用最大深度与栈总大小的比值	防止栈溢出导致的内存破坏，是系统稳定性的底线	栈填充模式（0xCC）、运行时水位检查、静态分析

三个指标并非孤立存在。CPU占用率过高会直接导致任务延迟增大；栈水位异常往往在系统运行数小时后才暴露，且故障现象随机。因此，评估必须采用“联合观测”策略，而非单独看某个数值。

1.3 性能评估的典型应用场景

以一个典型的智能家居语音唤醒设备为例：设备搭载Cortex-M4F内核（主频80MHz），运行FreeRTOS，部署了关键词识别模型（KWS）。系统包含以下任务：

• 音频采集任务（优先级高，周期2ms）：从PDM麦克风读取数据，放入环形缓冲区。
• 推理任务（优先级中，周期500ms）：从缓冲区取音频帧，执行MFCC特征提取+神经网络推理。
• 通信任务（优先级低，事件触发）：通过BLE上报唤醒结果。
• LED指示任务（优先级最低，周期100ms）：状态灯闪烁。

在这个场景中，性能评估需要回答以下问题：

1. 推理任务执行期间，音频采集任务能否在2ms内得到响应？如果CPU占用率超过85%，答案很可能是否定的。
2. 推理任务自身的延迟是否稳定？如果因为缓存未命中或中断频繁，延迟抖动超过50ms，用户体验会明显变差。
3. 通信任务栈是否足够？BLE协议栈可能使用递归调用，栈水位在极端情况下会突然升高。

1.4 性能评估的工程流程

一个完整的性能评估流程包含五个阶段，每个阶段都有明确的输入和输出：

阶段	关键活动	输出物
1. 需求分析	明确实时性要求（截止时间）、负载模型（任务周期、执行时间）、内存预算	性能需求规格书
2. 指标埋点	在RTOS内核中启用统计功能，添加时间戳记录、栈水位检查钩子	可观测的固件版本
3. 数据采集	运行典型工作负载，记录CPU占用率、任务延迟序列、栈水位快照	原始日志数据
4. 数据分析	计算均值、峰值、抖动、分布直方图，识别异常点	性能分析报告
5. 优化迭代	调整任务优先级、栈大小、算法优化，重新测量	优化后的固件+对比数据

值得注意的是，性能评估不是一次性的活动。在TinyML模型更新、RTOS版本升级、硬件改版后，都必须重新执行评估流程。特别是模型量化方式改变（如从int8改为float16），推理任务的CPU占用和栈使用会显著变化。

1.5 常见误区与风险提示

此外，还需要注意性能评估工具的侵入性。例如，使用JTAG调试器进行实时跟踪会干扰时序；使用串口打印日志会占用CPU和中断资源。建议采用“带外测量”方式：通过DMA将性能数据写入内存缓冲区，在空闲时批量导出，或者使用专用的性能分析引脚（GPIO翻转）配合逻辑分析仪。

1.6 案例拆解：从“能跑”到“可控”的评估实践

某工业振动监测设备，使用STM32H743（Cortex-M7，480MHz）运行Zephyr RTOS，部署了1D-CNN振动故障分类模型。设备需要同时采集三轴加速度计数据（采样率12.8kHz），每100ms执行一次推理，并通过CAN总线将结果发送给PLC。

初始现象：设备在实验室测试时功能正常，但部署到工厂现场后，偶尔出现CAN通信超时报警，且故障无规律，有时连续运行数小时才出现一次。

初步分析：工程师最初怀疑是CAN总线干扰，但检查硬件后发现总线电平正常。随后启用Zephyr的THREAD_STACK_INFO和TRACING功能，采集了24小时运行数据。

关键数据：

任务名          平均CPU%   最大延迟(ms)   栈水位(最小剩余字节)
sensor_task     42.3%     1.8           512
inference_task  38.7%     45.2          128
can_task        5.1%      12.7          96
idle_task       13.9%     -             -

分析判断：inference_task的最大延迟达到45.2ms，远超其100ms周期的30%预算。进一步查看时间戳发现，延迟尖峰出现在CAN总线繁忙时段——CAN任务虽然优先级低于推理任务，但CAN控制器中断频繁触发，导致推理任务被反复抢占。同时，inference_task的栈水位仅剩128字节，说明栈大小接近临界值。

优化措施：

1. 将inference_task的优先级从10提升到12（高于CAN任务），确保推理不被通信中断频繁打断。
2. 将inference_task的栈从2048字节增加到2560字节，预留20%余量。
3. 在CAN任务中使用消息队列替代直接调用，减少中断上下文中的处理时间。

结果对比：优化后，inference_task最大延迟降至18.6ms，栈水位剩余384字节，CAN通信超时报警完全消失。CPU总占用率从86.1%降至79.5%，因为减少了任务切换次数。

复盘经验：性能问题往往不是单一原因造成的。本案例中，延迟超标既有优先级配置问题，也有栈空间不足的隐患。如果只调整优先级而不增加栈空间，系统可能在极端输入下崩溃；如果只增加栈空间而不调整优先级，延迟问题依然存在。联合评估三个指标，才能定位真正的瓶颈。