RTOS基础回顾：任务、调度器、优先级、栈、互斥量及其在嵌入式AI中的作用
在进入TFLite Micro与RTOS协同工作的具体异常分析之前，我们必须先夯实RTOS的核心概念。嵌入式AI推理任务（如TFLite Micro的Interpreter::Invoke()）本质上是一个计算密集型任务，它运行在RTOS管理的线程上下文中。任务栈溢出、优先级反转、调度器抢占时机不当、互斥量死锁——这些RTOS层面的问题，往往比模型本身的数值错误更隐蔽、更致命。本章将系统梳理任务、调度器、优先级、栈与互斥量五大核心概念，并重点剖析它们在嵌入式AI推理场景中的特殊作用与风险。
2.1 任务与调度器：AI推理的“执行单元”与“交通警察”
核心原理：在RTOS环境中，任务（Task）是竞争CPU资源的基本单位。每个任务拥有独立的栈空间、程序计数器（PC）和寄存器上下文。调度器（Scheduler）则负责决定哪个任务在何时获得CPU控制权。嵌入式AI推理任务通常被封装为一个独立任务，例如 ai_inference_task，其函数体内部循环调用 tflite::MicroInterpreter::Invoke() 完成一次前向推理。
调度器的工作机制直接影响推理的实时性。大多数RTOS（如FreeRTOS、Zephyr）采用基于优先级的抢占式调度：高优先级任务就绪时，立即抢占低优先级任务的CPU使用权。这意味着，如果AI推理任务优先级设置不当，它可能被其他高优先级任务（如通信中断处理）频繁打断，导致推理时间片被切碎，单次推理延迟增大。
- 列出系统中所有功能模块（传感器采集、AI推理、通信、显示、控制输出）。
- 评估每个模块的实时性要求：硬实时（必须毫秒级响应）与软实时（允许几十毫秒延迟）。
- 为每个模块创建独立任务，并分配优先级：硬实时任务优先级高（数值小），软实时任务优先级低（数值大）。
- 确认AI推理任务属于软实时还是硬实时。若用于工业安全控制，则需高优先级；若用于数据记录或非实时分析，则可设为低优先级。
案例拆解：某智能家居中控项目，使用ESP32-S3运行TFLite Micro进行关键词唤醒（KWS）。系统包含WiFi通信任务（优先级5）、AI推理任务（优先级3）、UI刷新任务（优先级2）。初始设计将AI推理设为优先级3，但实际测试发现，当WiFi信号弱导致重传时，通信任务占用大量CPU时间，AI推理任务被抢占，唤醒响应延迟从平均80ms恶化到300ms。分析后调整：将AI推理任务提升至优先级4（高于WiFi通信），同时将WiFi通信任务中的重传逻辑改为状态机+非阻塞模式，最终唤醒延迟稳定在90ms以内。
2.2 任务栈：AI推理的“内存战场”
核心原理：任务栈是每个任务私有的内存区域，用于存储函数调用时的局部变量、函数参数、返回地址以及中断上下文。TFLite Micro的推理过程涉及多层函数调用：Invoke() → Prepare() → Eval() → 算子内核函数（如 ConvPerChannel()）。每一层调用都会在栈上分配空间。如果栈大小配置不足，会发生栈溢出，覆盖相邻内存区域，导致系统行为不可预测（如HardFault、数据损坏）。
嵌入式AI推理的栈消耗具有峰值特性：在模型加载、张量分配或特定算子（如深度可分离卷积）执行时，栈使用量达到峰值。因此，不能仅凭平均栈使用量来配置栈大小，必须考虑最坏情况。
| 栈使用阶段 | 典型消耗因素 | 估算建议 |
|---|---|---|
| 任务入口函数 | 任务参数、循环控制变量 | 约200-500字节 |
| Interpreter::Invoke() | 内部状态机、临时指针 | 约1-2KB |
| 算子内核执行 | 卷积/全连接层的局部缓冲区 | 约2-8KB（取决于算子实现） |
| 中断嵌套 | 中断服务程序上下文 | 额外预留1-2KB |
判断方法/操作流程：在FreeRTOS中，可通过 uxTaskGetStackHighWaterMark() 获取任务栈的历史最小剩余空间。建议在开发阶段周期性调用该函数，记录最小剩余值，并以此为依据调整栈大小。安全系数建议为1.5倍：最终栈大小 = (峰值使用量) × 1.5。
案例拆解：某车载疲劳检测项目，使用STM32H743（Cortex-M7）运行人脸关键点检测模型。初始任务栈配置为4096字节，运行中偶发HardFault。通过 uxTaskGetStackHighWaterMark() 检测发现，栈最小剩余空间仅为120字节，说明栈几乎被耗尽。进一步分析发现，模型中的 Softmax 算子内部使用了较大的临时数组。将栈大小调整为8192字节后，HardFault消失，最小剩余空间达到2100字节，系统稳定运行。
2.3 优先级与互斥量：推理资源的“保护锁”
核心原理：优先级决定了任务获得CPU的先后顺序，而互斥量（Mutex）用于保护多个任务共享的临界资源。在嵌入式AI系统中，常见的共享资源包括：模型参数区（通常只读，无需互斥）、推理输出缓冲区（多个任务可能同时读取）、传感器数据队列（生产者-消费者模型）。
当AI推理任务需要访问共享缓冲区时，必须使用互斥量进行加锁。但互斥量的使用会引入优先级反转问题：低优先级任务持有互斥量，高优先级任务等待该互斥量，导致高优先级任务被低优先级任务阻塞。若中间还有中等优先级任务抢占低优先级任务，高优先级任务的等待时间将不可预测。
xSemaphoreCreateMutex() 即可自动启用优先级继承。
判断方法/操作流程：在AI推理任务中，应遵循以下互斥量使用规范：
- 明确识别所有跨任务共享的全局变量或缓冲区。
- 为每个共享资源创建独立的互斥量，避免使用“大锁”保护所有资源。
- 在访问共享资源前获取互斥量，访问后立即释放，临界区代码尽量短。
- 禁止在中断服务程序（ISR）中获取互斥量，应使用信号量或消息队列通知任务处理。
案例拆解：某工业视觉检测系统，包含图像采集任务（优先级6）、AI推理任务（优先级4）、结果上报任务（优先级3）。图像采集任务将图像数据放入共享缓冲区，AI推理任务读取该缓冲区进行推理。初始实现中，图像采集任务和AI推理任务都使用同一个互斥量保护缓冲区。测试发现，当图像采集任务正在写入大尺寸图像（耗时较长）时，AI推理任务等待互斥量，而此时结果上报任务（优先级3）正常运行，但AI推理任务（优先级4）被阻塞，导致检测周期从50ms延长到120ms。分析后，将图像缓冲区改为双缓冲机制（采集任务写入Buffer A，推理任务读取Buffer B），并分别用两个互斥量保护，同时启用优先级继承。优化后，检测周期稳定在55ms。
2.4 总结复盘：RTOS与嵌入式AI协同的关键要点
RTOS为嵌入式AI提供了多任务并发执行的能力，但也引入了任务调度、内存管理、资源共享的复杂性。通过本章回顾，我们应牢记以下核心原则：
- 任务划分：AI推理任务应独立成任务，并根据实时性需求分配优先级，避免与通信、UI等任务混在一起。
- 栈配置：栈大小必须基于实测峰值使用量配置，并预留安全余量，尤其注意启用硬件加速后的额外消耗。
- 互斥量使用：保护共享资源时，务必使用支持优先级继承的互斥量，并保持临界区短小精悍。
- 调度策略：理解抢占式调度的行为，避免高优先级任务被低优先级任务间接阻塞。