3. TinyML与微控制器：微控制器资源限制与常用开发板对比
TinyML 的核心思想是在资源极度受限的微控制器（MCU）上直接运行机器学习推理，从而摆脱对云端的依赖。与服务器或移动端 GPU 不同，MCU 的存储容量、计算能力和功耗都受到严格约束。理解这些约束是设计低功耗视觉系统的前提——例如，一个 320×240 的 RGB 图像在未经压缩时约占用 230KB 内存，而许多主流 MCU 的 SRAM 仅有 256KB 甚至更少。本章将深入剖析 MCU 的内存、Flash 与算力瓶颈，并对三款在 TinyML 视觉领域极具代表性的开发板（Arduino Nano 33 BLE Sense、ESP32-CAM、STM32 系列）进行系统对比，帮助你在实际项目中做出合理的硬件选型。
上图展示了 TinyML 视觉系统的核心矛盾：MCU 的物理资源限制与开发板功能扩展之间的平衡。在实际项目中，我们往往需要在图像分辨率、模型大小、推理速度和功耗之间做出取舍。下面将从资源限制的底层原理出发，逐步展开对比分析。
3.1 微控制器的资源限制：内存、Flash 与算力的硬边界
3.1.1 核心原理：为什么 MCU 如此“吝啬”？
微控制器与桌面 CPU 或手机 SoC 的本质区别在于其设计目标：以最低功耗、最低成本完成确定性实时控制任务。因此，MCU 采用哈佛架构或改进型哈佛架构，将程序存储（Flash）与数据存储（SRAM）物理分离。这种设计带来两个直接后果：第一，SRAM 容量极小（通常 16KB~1MB），因为 SRAM 每个比特需要 6 个晶体管，成本高昂且功耗大；第二，Flash 容量有限（通常 128KB~2MB），用于存放固件和模型权重。算力方面，MCU 的时钟频率通常在 16MHz~480MHz 之间，且多数不具备浮点运算单元（FPU）或仅具备单精度 FPU，导致浮点运算速度极慢。
对于视觉应用，最关键的瓶颈是 SRAM。一张 QVGA（320×240）的灰度图像需要 76.8KB，RGB565 格式则需要 153.6KB，而 RGB888 格式高达 230.4KB。这意味着，在仅有 256KB SRAM 的 MCU 上，仅存储一帧 RGB888 图像就占用了 90% 的内存，留给模型中间变量、激活值和系统栈的空间几乎为零。因此，TinyML 视觉系统必须采用“先压缩、后处理”的策略：要么降低分辨率（如 96×96），要么使用 JPEG 硬件编码器直接输出压缩流，要么在传感器端完成下采样。
| 资源类型 | 典型范围 | 视觉任务影响 | 缓解策略 |
|---|---|---|---|
| SRAM | 16KB ~ 1MB | 决定图像缓冲区和模型中间张量大小 | 图像下采样、量化（int8）、内存复用 |
| Flash | 128KB ~ 2MB | 决定模型权重和代码体积 | 模型剪枝、权重量化、使用外部 QSPI Flash |
| 算力 (MAC/s) | 10M ~ 500M | 决定推理延迟和帧率 | 使用 CMSIS-NN、硬件加速器、降低模型复杂度 |
| 功耗 | 1mW ~ 500mW | 决定电池寿命和散热 | 事件触发拍照、深度睡眠、动态调频 |
3.1.2 判断方法：如何评估你的模型能否在 MCU 上运行？
在选型之前，你需要对目标模型进行“资源预算”估算。具体步骤如下：
- 计算模型参数量：假设一个 MobileNetV1 0.25 模型，参数量约为 470K，以 int8 量化后占用 Flash 约 470KB（加上代码和运行时库，总 Flash 需求约 600KB）。
- 估算激活值内存：输入 96×96×3 图像，第一层卷积输出 48×48×8，激活值约 18KB；后续层逐步减小。整个推理过程的峰值激活内存通常在 30~80KB 之间。
- 检查 SRAM 余量：将图像缓冲区（例如 96×96×2 字节 = 18KB）加上激活峰值（50KB）加上系统栈（8KB），得到约 76KB。若 MCU 有 256KB SRAM，则余量充足；若只有 64KB，则必须考虑内存复用或分块推理。
- 评估算力：MCU 的 MAC（乘加运算）能力 = 时钟频率 × 并行度。Cortex-M4F 在 80MHz 下，使用 CMSIS-NN 的 int8 卷积，每秒可执行约 40M MACs。若模型总 MACs 为 20M，则推理延迟约 0.5 秒，可接受；若模型为 100M MACs，则延迟 2.5 秒，不适合实时应用。
3.1.3 案例拆解：从“内存溢出”到“成功部署”的调优过程
背景：某智能门铃项目，需要检测门前 3 米内是否有人，使用 Arduino Nano 33 BLE Sense（SRAM 256KB，Flash 1MB，Cortex-M4F 64MHz）。初始方案直接使用 MobileNetV1 0.5（参数量 1.3M，int8 后 1.3MB），输入图像 96×96 RGB。
初始现象：编译成功，但运行时系统反复重启，串口输出 “Memory allocation failed”。
分析过程：通过打印内存分配日志发现，模型权重占 1.3MB Flash（超出 1MB 限制），且激活值峰值达到 120KB，加上图像缓冲区 27KB，总内存需求超过 256KB。进一步检查，发现 TensorFlow Lite Micro 的 arena 设置为 200KB，但实际需要 180KB，加上系统占用，导致溢出。
实际操作步骤：
- 将模型更换为 MobileNetV1 0.25（参数量 470K，int8 后 470KB），Flash 占用降至 600KB（含代码）。
- 将输入分辨率从 96×96 降至 64×64，图像缓冲区降至 12KB，激活峰值降至 45KB。
- 将 arena 设置为 80KB，并启用内存复用（TensorFlow Lite Micro 的
tflite::MicroAllocator自动优化）。 - 使用 CMSIS-NN 加速卷积运算，推理延迟从 1.8 秒降至 0.9 秒。
结果对比：优化前系统无法启动；优化后模型正常推理，帧率约 1 FPS，功耗 120mW，满足门铃场景需求（事件触发拍照，非连续视频流）。
复盘经验：内存优化优先级应为：模型量化（int8）→ 输入分辨率降低 → 模型结构精简 → 内存复用。不要一开始就追求高精度，先确保能跑通，再逐步提升。
3.1.4 常见误区与总结
误区二：忽略代码和运行时库的 Flash 占用。TensorFlow Lite Micro 运行时约 20~50KB，CMSIS-NN 库约 30KB，加上驱动和 RTOS，总代码量可能超过 100KB。
误区三：盲目使用浮点模型。Cortex-M4F 虽然支持 FPU，但浮点运算比 int8 慢 4~8 倍，且内存占用翻倍。除非必要，一律使用 int8 量化。
总结：MCU 资源限制是 TinyML 视觉设计的“第一性原理”。只有深刻理解 SRAM、Flash 和算力的边界，才能做出合理的工程决策。建议在项目启动前，先完成资源预算表，再选择硬件。
3.2 常用开发板对比：Arduino Nano 33 BLE Sense、ESP32-CAM 与 STM32
3.2.1 核心原理：三款开发板的定位差异
这三款开发板代表了 TinyML 视觉的三种典型路径：低功耗集成型（Arduino Nano 33 BLE Sense）、低成本 Wi-Fi 型（ESP32-CAM）、高性能可扩展型（STM32 系列）。它们的差异不仅体现在硬件参数上，更体现在开发生态、功耗管理和外设集成度上。
- Arduino Nano 33 BLE Sense：基于 Nordic nRF52840（Cortex-M4F 64MHz），集成 9 轴 IMU、麦克风、温湿度传感器，但没有摄像头接口，需外接 PDM 麦克风或通过 SPI 连接摄像头模块。其最大优势是超低功耗（深度睡眠 1.9µA）和 Arduino 生态的易用性，适合可穿戴或电池供电的事件触发场景。
- ESP32-CAM：基于 Espressif ESP32-S（双核 Xtensa LX6 240MHz），板载 OV2640 摄像头（支持 JPEG 硬件编码），集成 Wi-Fi 和蓝牙。SRAM 仅 520KB（实际可用约 320KB），但支持 PSRAM（外部伪静态 RAM，最高 4MB），可缓存多帧图像。其优势是性价比极高（约 30 元人民币）且自带 Wi-Fi 传输，适合需要无线传输或本地 JPEG 存储的场景。
- STM32 系列（如 STM32F746G-DISCO 或 STM32H747I-DISCO）：ST 的 Cortex-M7 或 M7+M4 双核，主频高达 480MHz，SRAM 最大 1MB，支持外部 SDRAM 和 QSPI Flash。部分型号（如 STM32H7）内置硬件 JPEG 编解码器和 DCMI 摄像头接口。其优势是算力强、外设丰富，适合需要较高帧率或复杂模型的场景，但开发门槛较高（通常使用 STM32CubeMX + FreeRTOS + 自研或 CMSIS-NN 推理）。
| 对比维度 | Arduino Nano 33 BLE Sense | ESP32-CAM | STM32F746G-DISCO |
|---|---|---|---|
| 主控芯片 | nRF52840 (Cortex-M4F) | ESP32-S (双核 LX6) | STM32F746 (Cortex-M7) |
| 时钟频率 | 64 MHz | 240 MHz | 216 MHz |
| SRAM | 256 KB | 520 KB (可用约 320KB) | 320 KB (可外扩 SDRAM) |
| Flash | 1 MB | 4 MB (PSRAM 可选) | 1 MB (可外扩 QSPI) |
| 摄像头接口 | 无（需外接 SPI/PDM） | 板载 OV2640 (JPEG) | DCMI 接口（支持 OV5640 等） |
| 无线通信 | BLE 5.0 | Wi-Fi 802.11 b/g/n + BLE | 无（需外接模块） |
| 典型功耗 (运行) | ~30 mW | ~250 mW (Wi-Fi 开启) | ~300 mW |
| 深度睡眠功耗 | 1.9 µA | ~10 µA (RTC 模式) | ~7 µA |
| 开发框架 | Arduino IDE / Mbed | Arduino / ESP-IDF | STM32CubeMX / Keil / Mbed |
| 推理库支持 | TensorFlow Lite Micro | TensorFlow Lite Micro / ESP-DL | TensorFlow Lite Micro / CMSIS-NN |
| 适合场景 | 可穿戴、低功耗事件触发 | Wi-Fi 图传、本地 JPEG 存储 | 高性能视觉、多传感器融合 |
3.2.2 判断方法：根据项目需求选择开发板
选择开发板时，建议按以下决策流程进行：
- 明确供电方式：如果是纽扣电池供电且需要数月续航，首选 Arduino Nano 33 BLE Sense（深度睡眠功耗极低）；如果是 USB 供电或大容量锂电池，可考虑 ESP32-CAM 或 STM32。
- 确定图像传输需求：如果需要将图像发送到云端或手机，ESP32-CAM 的 Wi-Fi 是天然优势；如果仅本地处理，STM32 的 DCMI 接口更稳定。
- 评估模型复杂度：如果模型参数量超过 500KB 或 MACs 超过 100M，STM32H7 或 ESP32 加 PSRAM 是必要选择；如果模型较小（如手势识别），Arduino Nano 33 足够。
- 考虑开发周期：Arduino 生态上手最快，ESP32 次之，STM32 需要更多底层配置。对于快速原型验证，优先 Arduino；对于量产产品，STM32 的可靠性和长期供货更有保障。
3.2.3 案例拆解：智能猫眼——从选型到部署的完整闭环
背景与约束：某智能家居团队需要设计一款猫眼设备，要求：① 使用两节 AA 电池供电，续航至少 6 个月；② 当有人靠近时（1 米内）自动拍照并识别是否为陌生人；③ 识别结果通过 BLE 发送到手机；④ 成本控制在 100 元以内。
初始方案与问题：团队最初选择 ESP32-CAM，因为其自带摄像头和 Wi-Fi。但实测发现：ESP32-CAM 在 Wi-Fi 开启时功耗高达 250mW，即使关闭 Wi-Fi，仅运行摄像头和推理，功耗也达 120mW。两节 AA 电池（约 3000mAh）只能维持约 25 小时，远达不到 6 个月要求。此外，ESP32-CAM 的深度睡眠唤醒时间约 2 秒，无法快速响应。
分析判断过程：团队重新审视需求：识别结果只需通过 BLE 发送（而非 Wi-Fi），且不需要实时视频流。因此，选择低功耗的 Arduino Nano 33 BLE Sense 作为主控，外接 Himax HM01B0 摄像头（320×320 灰度，功耗仅 1mW），使用 PIR 传感器（功耗 0.1mW）作为唤醒源。
实际操作步骤：
- 硬件连接：PIR 输出接 nRF52840 的 P0.13 引脚（可配置为低电平唤醒）；HM01B0 通过 SPI 接口连接，使用 96×96 分辨率（裁剪中心区域）。
- 软件设计：使用 Arduino IDE + TensorFlow Lite Micro。模型为 MobileNetV1 0.25（int8），输入 96×96×1（灰度），输出二分类（陌生人/熟人）。
- 功耗优化：PIR 唤醒后，MCU 从深度睡眠（1.9µA）唤醒至运行模式（30mA），耗时 3ms；拍照 + 推理耗时 800ms；完成后通过 BLE 发送结果（20ms），然后立即回到深度睡眠。
- 实测数据：单次事件总耗电 = 30mA × 0.82s ≈ 24.6mAs。假设每天触发 20 次，日耗电 492mAs，加上待机功耗（1.9µA × 24h = 164mAs），总日耗电约 656mAs。两节 AA 电池（3000mAh = 10,800,000mAs）可续航约 16,463 天，远超 6 个月要求。
结果对比：ESP32-CAM 方案续航不足 2 天，而 Arduino 方案续航超过 45 年（理论值）。实际测试中，由于电池自放电和温度影响，实测续航约 14 个月，完全满足需求。
风险与代价：Arduino Nano 33 BLE Sense 的成本约 150 元，加上摄像头和 PIR，总成本约 200 元，超出预算。团队通过改用国产兼容板（基于 nRF52840 的 Seeed XIAO BLE）将成本降至 80 元。此外，灰度图像在夜间识别准确率下降，需增加红外补光（额外功耗 5mW，仅在触发时开启）。
复盘经验：选型时，功耗预算应优先于功能丰富度。ESP32-CAM 的 Wi-Fi 功能在低功耗场景中反而是累赘。同时，事件触发架构（PIR 唤醒 → 拍照 → 推理 → 睡眠）是 TinyML 视觉系统省电的关键，而非单纯依赖 MCU 的低功耗模式。
3.2.4 常见误区与总结
误区二：忽略摄像头本身的功耗。OV2640 在 JPEG 模式下的功耗约 80mW，而 Himax HM01B0 仅 1mW。选择低功耗摄像头比选择低功耗 MCU 更重要。
误区三：将 PC 上的模型直接部署到 MCU，不做量化或裁剪。这会导致内存溢出或推理延迟过高。必须使用 TensorFlow Lite Converter 进行 int8 量化，并验证精度损失。
总结：三款开发板各有优劣，没有“最好”的板子，只有“最合适”的方案。Arduino Nano 33 BLE Sense 适合超低功耗事件触发场景；ESP32-CAM 适合需要 Wi-Fi 传输或低成本原型验证；STM32 系列适合高性能、多外设的复杂系统。在实际项目中，建议先明确功耗预算、图像传输需求和模型复杂度，再做出选择。