2、TinyML基础回顾：嵌入式设备资源限制、实时操作系统(RTOS)概念、任务调度与时间片

TinyML 的日志采集与性能分析，本质上是在极端受限的嵌入式环境中进行的一种“系统观测”行为。要理解为什么日志采集本身会引入延迟、为什么任务运行时间的测量需要特殊设计，就必须先回到 TinyML 运行的物理与软件基础——嵌入式设备的资源边界、实时操作系统的调度机制，以及时间片如何决定任务的执行节奏。本章将系统梳理这三层基础，为后续章节中日志采集点位的设计、时间戳的获取、以及推理延迟的量化分析建立必要的认知框架。

2.1 嵌入式设备的资源限制：日志采集的“硬边界”

TinyML 设备通常基于 Cortex-M 系列微控制器，其资源规模与云端服务器或移动端 SoC 有数量级差异。以典型的 Arm Cortex-M4F 内核为例，主频通常在 80MHz 至 240MHz 之间，SRAM 容量为 64KB 至 512KB，Flash 为 256KB 至 2MB。这意味着日志系统不能像 Linux 那样随意分配内存缓冲区，也不能依赖文件系统进行持久化存储。更关键的是，这些设备没有内存管理单元（MMU），所有代码和数据必须直接映射到物理地址空间，任何内存越界都可能直接导致 HardFault。

资源限制对日志采集的影响是系统性的。首先，日志缓冲区的大小必须精打细算——一个 4KB 的环形缓冲区可能占用总 RAM 的 6% 以上，对于 64KB RAM 的设备来说，这已经是相当大的开销。其次，日志输出不能阻塞任务执行，因为串口打印一个 100 字节的日志在 115200 波特率下需要约 8.7ms，这期间如果任务被阻塞，实时性将无法保证。因此，TinyML 日志系统通常采用“内存缓冲 + 异步输出”的模式，即任务只负责将日志写入内存缓冲区，由专门的低优先级任务或 DMA 负责实际的外设输出。

另一个容易被忽视的限制是中断优先级与嵌套深度。Cortex-M 内核支持可编程中断优先级（通常 8~16 级），但日志采集如果放在中断上下文中执行，必须保证中断服务函数（ISR）足够短，且不能调用任何可能阻塞的操作（如获取互斥锁）。否则，中断延迟会急剧增加，导致实时任务错过截止时间。在实际项目中，我们通常将日志采集分为两个层次：ISR 中只记录时间戳和事件 ID（几个周期即可完成），完整的日志格式化与输出则推迟到任务上下文中处理。

2.2 实时操作系统（RTOS）核心概念：任务、调度器与同步

RTOS 为 TinyML 设备提供了多任务并发执行的能力，但其本质与通用操作系统不同：RTOS 的目标不是提高吞吐量，而是保证任务在确定的时间内完成。在 TinyML 场景中，典型的任务划分包括：传感器数据采集任务（周期 1-10ms）、推理任务（周期 20-100ms）、日志输出任务（低优先级，周期 50-200ms）、通信任务（如 BLE 或 Wi-Fi 协议栈）。每个任务都有独立的栈空间（通常 512B 到 4KB），任务间通过队列、信号量或事件组进行通信。

理解 RTOS 的任务状态机是进行日志分析的基础。任务在任意时刻处于以下四种状态之一：运行态（正在占用 CPU）、就绪态（可运行但等待调度）、阻塞态（等待某个事件或资源）、挂起态（被显式暂停）。日志系统需要能够区分任务在不同状态下的时间消耗——例如，一个推理任务如果频繁进入阻塞态等待传感器数据，那么它的“运行时间”可能很短，但“响应时间”很长，这需要通过时间戳记录任务从就绪到完成的全过程。

调度策略是 RTOS 的核心决策机制。大多数 TinyML 设备使用优先级抢占式调度（Preemptive Priority Scheduling），即高优先级任务可以打断低优先级任务的执行。在此基础上，同优先级任务之间采用时间片轮转（Round-Robin）策略，每个任务运行一个固定的时间片（通常为 1 到 10 个系统节拍）后让出 CPU。系统节拍（Tick）由 SysTick 定时器产生，典型值为 1ms 或 10ms。节拍频率越高，调度精度越高，但上下文切换的开销也越大——每次切换需要保存和恢复寄存器现场，大约消耗 50-200 个 CPU 周期。

2.3 任务调度与时间片：测量延迟的“标尺”

任务调度机制直接决定了推理延迟的测量方式。在裸机（Bare-metal）编程中，代码是顺序执行的，延迟测量相对简单——只需在函数入口和出口读取硬件定时器即可。但在 RTOS 环境下，推理任务可能被高优先级中断或任务抢占，因此“推理延迟”需要区分两种定义：CPU 占用时间（任务实际运行推理代码的时间）和端到端响应时间（从任务被唤醒到推理完成的时间）。后者包含了等待调度、被抢占、上下文切换等所有开销，是用户感知到的真实延迟。

时间片轮转机制对日志采集提出了特殊要求。假设系统节拍为 1ms，时间片为 5 个节拍（即 5ms），那么一个推理任务如果运行超过 5ms，就会被强制让出 CPU，让同优先级的其他任务运行。此时，如果日志系统只记录任务开始和结束的时间戳，就会得到一个“毛刺”——任务实际运行了 8ms，但中间被切出了 3ms。为了准确测量，日志系统需要在每次任务切换时记录切换事件，或者使用硬件 DWT（Data Watchpoint and Trace）单元中的 CYCCNT 寄存器来精确计数 CPU 周期。

在实际的 TinyML 延迟测量中，我们推荐使用双时间戳法：在任务入口记录一个时间戳 T0，在任务出口记录 T1，同时通过 RTOS 的钩子函数（如 FreeRTOS 的 vApplicationTaskSwitchHook）记录每次任务切换的时刻。这样，T1 - T0 是任务的“墙上时间”（Wall-clock time），而通过减去切换期间的时间，可以得到“纯 CPU 时间”。对于推理延迟的优化，我们通常关注纯 CPU 时间，因为它反映了模型计算本身的效率；而墙上时间则反映了系统整体的实时性表现。

// 使用 DWT->CYCCNT 获取 CPU 周期计数
volatile uint32_t *DWT_CYCCNT = (uint32_t *)0xE0001004;
volatile uint32_t *DWT_CONTROL = (uint32_t *)0xE0001000;
volatile uint32_t *SCB_DEMCR = (uint32_t *)0xE000EDFC;

// 初始化
*SCB_DEMCR |= 0x01000000;  // 使能 DWT
*DWT_CYCCNT = 0;
*DWT_CONTROL |= 1;          // 使能 CYCCNT

// 读取时间戳（单位：CPU周期）
uint32_t ts_start = *DWT_CYCCNT;
// ... 执行推理 ...
uint32_t ts_end = *DWT_CYCCNT;
uint32_t elapsed_cycles = ts_end - ts_start;
float elapsed_us = (float)elapsed_cycles / (SystemCoreClock / 1000000);

2.4 案例拆解：一个音频唤醒词检测任务的延迟分析

我们以一个典型的音频唤醒词检测任务为例，说明如何利用 RTOS 机制进行延迟分析。系统硬件为 Cortex-M7 内核（主频 400MHz），配备 512KB SRAM，运行 FreeRTOS，系统节拍为 1ms。任务划分如下：音频采集任务（优先级 5，周期 10ms）、推理任务（优先级 4，周期 20ms）、日志输出任务（优先级 2，周期 100ms）。

初始现象：推理任务的平均 CPU 时间仅为 3.2ms，但端到端响应时间却高达 15ms，导致唤醒词检测的实时性不达标。通过日志系统记录的时间戳发现，推理任务每次被唤醒后，平均需要等待 8ms 才能获得 CPU 执行权。

分析过程：进一步查看任务切换日志，发现音频采集任务（优先级 5）每次运行时间为 1.5ms，但它在每次周期内会调用一个阻塞式 I2S 读取函数，等待 DMA 传输完成。由于 I2S 的 DMA 中断优先级设置较低，导致音频采集任务经常在等待期间被其他中断打断，实际阻塞时间从预期的 2ms 延长到 6ms。更关键的是，音频采集任务在阻塞期间持有了一把互斥锁，而推理任务在启动时需要获取同一把锁来读取音频数据，因此推理任务被长时间阻塞。

解决方案：将 I2S DMA 中断优先级提升至高于音频采集任务优先级，确保 DMA 传输完成后能立即唤醒采集任务；同时，将互斥锁替换为队列——音频采集任务将数据写入队列后立即释放 CPU，推理任务从队列中读取数据，不再需要持有锁。修改后，推理任务的端到端响应时间从 15ms 降至 5.8ms，其中 CPU 时间 3.2ms，调度等待 1.8ms，上下文切换开销 0.8ms。

复盘经验：这个案例揭示了 TinyML 日志采集的核心价值——它不仅仅是记录数据，更是揭示系统调度行为与资源竞争的关键工具。如果没有精确到任务切换级别的时间戳，我们很难定位到互斥锁竞争这个隐蔽的瓶颈。同时，案例也说明，日志系统本身的设计必须考虑 RTOS 的调度特性：日志输出任务优先级不能太高，否则会干扰实时任务；日志缓冲区必须足够大以容纳突发日志，但又不能占用过多内存。

2.5 常见误区与设计要点

在 TinyML 日志与性能分析实践中，存在几个典型误区。第一个误区是盲目追求高时间戳精度。虽然 DWT->CYCCNT 可以提供纳秒级精度，但 RTOS 的调度抖动（Jitter）通常在几十微秒级别，过高的精度反而会引入大量噪声数据，增加日志分析难度。建议根据系统节拍和任务周期选择合适的时间戳分辨率——对于 1ms 节拍的系统，微秒级精度已经足够。

第二个误区是在 ISR 中执行复杂日志操作。有些开发者为了不错过中断事件，直接在 ISR 中调用日志格式化函数，这会导致中断延迟不可控。正确的做法是：ISR 中只记录原始事件（如一个 32 位的时间戳和一个 8 位的事件 ID），放入一个无锁的环形缓冲区，由任务上下文负责格式化与输出。

第三个误区是忽略上下文切换本身的开销。每次任务切换需要 50-200 个 CPU 周期，如果系统有 10 个任务，每秒切换 1000 次，那么上下文切换将消耗 5%-20% 的 CPU 资源。日志系统应该能够统计切换次数和每次切换的耗时，帮助开发者评估是否需要减少任务数量或调整时间片长度。