2、TinyML基础回顾：嵌入式系统、微控制器、传感器与机器学习推理的基本概念
TinyML 的本质，是在资源极度受限的嵌入式设备上运行机器学习推理。要理解 TinyML 工程分层，首先必须厘清四个核心概念：嵌入式系统、微控制器（MCU）、传感器以及机器学习推理。这四个要素并非孤立存在，而是构成了一条从物理世界采集数据，到在设备端完成智能决策的完整链路。本章将逐一拆解这些基础概念，并重点阐明它们之间的耦合关系——这正是后续章节讨论“解耦”的出发点。
上图展示了 TinyML 系统的基本数据流：物理世界的模拟信号经传感器数字化后，通过 I2C/SPI 等总线送入微控制器，微控制器在资源受限的嵌入式系统边界内完成预处理、特征提取、模型推理与后处理，最终驱动执行器或输出结果。理解这条链路中的每一个环节及其约束，是进行工程分层的前提。
2.1 嵌入式系统与微控制器：资源受限的计算平台
核心原理：嵌入式系统是“为了特定功能而设计的专用计算机系统”，它与通用 PC 的最大区别在于：功能专用、资源受限、实时性要求高、功耗敏感。微控制器（MCU）是嵌入式系统的核心计算单元，它将 CPU、内存（RAM）、存储（Flash）、定时器、通信接口（UART/I2C/SPI）以及模拟外设（ADC/DAC）集成在单一芯片上。与应用处理器（AP，如手机 SoC）不同，MCU 通常运行裸机程序或 RTOS（实时操作系统），没有完整的 Linux 内核，内存以 KB 计，主频以 MHz 计。
判断方法：在 TinyML 项目中，选择 MCU 平台时需关注以下关键指标：
- 算力：核心主频（如 80MHz Cortex-M4）与是否有 DSP 指令或硬件乘法器，直接影响推理速度。
- 内存：SRAM 大小决定了模型激活值（中间张量）能否放下；Flash 大小决定了模型权重和代码的存储空间。
- 外设：ADC 通道数、I2C/SPI 速率、DMA 支持，影响传感器数据采集效率。
- 功耗模式：是否支持 deep sleep / stop 模式，以及唤醒时间，决定电池寿命。
| 对比维度 | 典型 MCU（如 STM32L4） | 应用处理器（如树莓派） |
|---|---|---|
| 主频 | 80 MHz | 1.5 GHz 四核 |
| SRAM | 128 KB | 1 GB LPDDR2 |
| Flash/eMMC | 512 KB | 16 GB SD 卡 |
| 操作系统 | 裸机 / FreeRTOS | Linux |
| 典型功耗 | < 10 mW | 2-5 W |
| 启动时间 | < 1 ms | 数秒 |
2.2 传感器与数据采集：从物理世界到数字信号
核心原理：传感器是将物理量（温度、加速度、光强、声压）转换为电信号的器件。在 TinyML 系统中，传感器输出的模拟信号通常需要经过信号调理（放大、滤波）和 ADC 采样，转换为数字量。常见的数字传感器（如 MPU6050 六轴 IMU、BME280 环境传感器）则直接通过 I2C/SPI 接口输出数字值。数据采集的质量直接决定了模型推理的上限——如果采样率不足或噪声过大，再好的模型也无法准确识别。
操作流程：传感器数据接入 MCU 的标准流程如下：
- 初始化：配置 GPIO 为输入模式，设置 I2C/SPI 时钟速率，使能传感器内部寄存器。
- 触发采集：使用定时器中断或传感器数据就绪引脚（INT）触发采样，避免 CPU 轮询浪费。
- 数据搬运：通过 DMA 将传感器 FIFO 数据直接搬运至内存缓冲区，减少中断开销。
- 时间戳标记：在数据块头部记录当前系统 tick，用于后续时域特征对齐。
// 示例：使用 DMA 读取 IMU 加速度数据（伪代码）
void IMU_Init(void) {
I2C_Init(400000); // 400kHz I2C
IMU_WriteReg(CTRL1_XL, 0x60); // 加速度计 104Hz
DMA_Config(IMU_FIFO_ADDR, buffer, 6*10); // 10组 XYZ 数据
}
void DMA_Complete_ISR(void) {
process_imu_data(buffer); // 触发预处理任务
}2.3 机器学习推理：在 MCU 上执行模型
核心原理：机器学习推理（Inference）是指将训练好的模型参数（权重、偏置）加载到设备端，对新的输入数据执行前向传播计算，得到预测结果。在 TinyML 场景中，推理引擎（如 TensorFlow Lite for Microcontrollers、CMSIS-NN）负责将模型解释为高效的 C++ 代码，并利用 MCU 的 DSP 指令或 SIMD 能力加速矩阵运算。由于 MCU 无法运行 Python 或完整框架，模型必须经过 量化（通常为 int8）和 转换（转换为 FlatBuffer 格式）后才能部署。
判断方法：评估一个模型是否适合在特定 MCU 上运行，需计算以下指标：
- 模型大小：量化后权重文件大小必须小于 Flash 剩余空间。
- RAM 峰值：推理过程中最大中间张量占用，可通过 Arena 分配器估算。
- 单次推理延迟：通过 CMSIS-NN 优化后，每层卷积的计算周期数。
| 模型类型 | 典型大小 (int8) | RAM 需求 | 适用 MCU 等级 |
|---|---|---|---|
| 线性/逻辑回归 | < 2 KB | < 1 KB | 8-bit 低端 MCU |
| 决策树/随机森林 | 5-20 KB | 2-5 KB | Cortex-M0+ |
| 1D-CNN (关键词唤醒) | 30-60 KB | 10-20 KB | Cortex-M4 |
| 2D-CNN (图像分类) | 100-500 KB | 50-200 KB | Cortex-M7 或更高 |
2.4 四要素的耦合关系与工程分层动机
核心原理：嵌入式系统、MCU、传感器和推理引擎在物理上紧密耦合，但在工程上必须逻辑解耦。例如，传感器驱动代码不应直接调用模型推理函数，而应通过统一的数据结构（如环形缓冲区）传递原始数据。推理引擎也不应关心数据来自 IMU 还是麦克风，只负责处理浮点或 int8 张量。这种解耦的动机在于：
- 可移植性：更换传感器型号时，只需修改驱动层，不影响推理逻辑。
- 可测试性：可以在 PC 上模拟传感器数据流，单独验证推理引擎的正确性。
- 可维护性：业务逻辑（如“振动超标则报警”）与底层硬件细节分离，便于迭代。
案例拆解：以一个工业电机预测性维护系统为例。初始方案中，工程师将振动传感器读取、FFT 特征提取、CNN 推理和报警逻辑全部写在了一个 while(1) 循环中。当需要将加速度计从 ADXL345 更换为更灵敏的 IIS2DH 时，不得不修改特征提取代码中的寄存器配置，甚至影响了模型输入格式。重构后，系统分为四层：驱动层（仅提供 read_accel_data() 接口）、预处理层（输出固定长度的频谱向量）、推理层（输入频谱，输出故障类别）、应用层（根据类别和置信度决定是否报警）。更换传感器时，只需重写驱动层，其余三层完全不变。