2. 嵌入式系统资源基础
在将TFLite Micro模型部署到微控制器（MCU）之前，我们必须先建立对目标硬件资源的清晰认知。MCU不同于桌面CPU或应用处理器，它的Flash、RAM、时钟和外设资源极其有限，且各项资源之间相互制约。本章将系统梳理这些核心资源的概念、度量单位、工程意义，并给出资源评估的具体方法和判断路径，为后续的依赖裁剪和模型移植打下量化基础。
核心原理：MCU四大资源的本质与度量
MCU的资源评估本质上是对存储容量、运行速度、数据通路三个维度的量化分析。Flash和RAM属于存储维度，时钟属于速度维度，外设则决定了数据如何进出芯片。对于TFLite Micro部署而言，这四项资源直接决定了模型能否运行、运行多快、以及如何与传感器和执行器交互。
Flash（闪存）是MCU的非易失性存储，用于存放程序代码（.text段）、只读数据（.rodata段）以及常量模型权重。在TFLite Micro场景中，模型权重通常以C数组或二进制文件形式存储在Flash中。Flash的容量决定了模型文件的最大体积——一个300KB的模型在256KB Flash的芯片上根本无法完整存放。此外，Flash的读取速度通常比RAM慢，频繁从Flash读取权重会拖慢推理速度，因此部分实现会将热点数据缓存到RAM。
RAM（随机存取存储器）是MCU的易失性工作内存，包含静态数据（.data段）、零初始化数据（.bss段）和堆栈空间。TFLite Micro的推理过程需要在RAM中分配张量（Tensor）缓冲区，包括输入张量、输出张量、中间激活张量以及算子临时缓冲区。一个典型的图像分类模型，输入为96×96×3的RGB图像，仅输入张量就需要约27KB RAM，再加上各卷积层的中间激活，RAM峰值可能达到100KB以上。RAM不足是TFLite Micro移植失败的首要原因。
时钟（Clock）决定了CPU的指令执行速率。MCU的主频通常在几十MHz到几百MHz之间。以STM32F4系列为例，主频168MHz，每秒可执行约1.68亿条指令。TFLite Micro的推理延迟与主频直接相关——主频翻倍，推理时间大致减半。但高主频意味着高功耗，对于电池供电的物联网设备，需要在性能与功耗之间做权衡。此外，外设总线（如APB1、APB2）的时钟频率与CPU主频不同，外设通信速率受限于总线时钟。
外设资源包括GPIO、UART、SPI、I2C、DMA、定时器、ADC、DAC等。在TFLite Micro应用中，外设的作用体现在三个方面：一是数据采集（ADC读取传感器、SPI/I2C连接数字传感器）；二是结果输出（UART打印推理结果、GPIO控制执行器）；三是加速辅助（DMA搬运数据、定时器产生PWM波形）。外设资源的评估不仅要看数量，还要看是否支持中断、DMA等高级特性，这些特性直接影响数据采集的实时性和CPU的占用率。
| 资源类型 | 存储属性 | TFLite Micro中的用途 | 典型容量/速率 | 不足时的后果 |
|---|---|---|---|---|
| Flash | 非易失 | 模型权重、代码段、只读常量 | 256KB ~ 2MB | 模型无法完整存储 |
| RAM | 易失 | 输入/输出张量、中间激活、堆栈 | 64KB ~ 512KB | 推理时内存溢出 |
| 时钟 | — | CPU执行速率、外设通信速率 | 16MHz ~ 240MHz | 推理延迟过高 |
| 外设 | — | 传感器数据采集、结果输出、DMA搬运 | UART/SPI/I2C等 | 数据通路受阻 |
判断方法：资源评估的操作流程与量化指标
资源评估不是凭感觉估算，而是需要一套可重复的量化流程。以下是在TFLite Micro移植前必须完成的资源评估步骤：
- 获取芯片数据手册：从芯片厂商官网下载Datasheet和Reference Manual，查找Flash容量、RAM容量、主频范围、外设列表等关键参数。注意区分不同封装型号的差异，同一系列芯片不同型号的资源可能相差数倍。
- 编译固件获取静态占用：使用交叉编译工具链（如arm-none-eabi-gcc）编译一个空的TFLite Micro工程，通过
arm-none-eabi-size命令查看生成的.elf文件中text、data、bss段的大小。text段占用Flash，data+bss段占用RAM。这一步能获得TFLite Micro框架本身的基础开销。 - 估算模型权重体积：将训练好的模型转换为TFLite格式后，直接查看文件大小。若使用量化模型（如int8），权重体积约为float32模型的1/4。例如，一个MobileNetV1 float32模型约16MB，int8量化后约4MB，这仍然超出了大多数MCU的Flash容量，需要进一步裁剪或使用更小的模型架构。
- 计算运行时RAM峰值：TFLite Micro的RAM占用由输入张量、输出张量、中间激活张量和算子工作缓冲区组成。可以使用TFLite的arena allocator机制，通过设置
tflite::MicroInterpreter的tensor arena大小来限制RAM使用。建议先用较大的arena（如128KB）运行一次，观察实际峰值，再逐步缩小。 - 评估时钟与推理延迟：在目标MCU上运行一个基准模型（如Person Detection模型），使用定时器测量单次推理的毫秒数。若延迟超出实时性要求，则需要考虑提高主频、优化算子或更换更高效的模型。
- 盘点外设需求：列出应用所需的所有外设接口，确认目标芯片是否具备。例如，若传感器使用I2C接口，需确认芯片有I2C外设且引脚未被占用；若需要DMA搬运数据，需确认DMA通道数量足够。
关键指标速查：在评估过程中，建议记录以下数据——Flash剩余空间（总容量 - 代码段 - 模型权重）、RAM剩余空间（总容量 - 静态数据 - 堆栈 - 张量arena）、推理延迟（ms）、外设占用率（已用外设/可用外设）。这些数据将作为后续依赖裁剪的量化依据。
案例拆解：基于STM32F411的语音关键词识别部署评估
下面通过一个具体的案例来演示资源评估的完整过程。假设我们要在STM32F411CEU6（Cortex-M4F，主频100MHz，Flash 512KB，RAM 128KB）上部署一个语音关键词识别模型（如MicroNet），识别"是/否"两个关键词。
初始目标与约束：模型输入为40通道×20帧的MFCC特征（约3.2KB），输出为3个类别（是/否/静音）。要求推理延迟小于100ms，RAM占用不超过80KB（预留48KB给系统栈和通信缓冲）。
评估过程：首先编译空的TFLite Micro工程，使用arm-none-eabi-size查看静态占用：text段约85KB（包含TFLite Micro框架、算子库和启动代码），data段约2KB，bss段约15KB。因此，Flash已用85KB，剩余427KB；RAM已用17KB，剩余111KB。
接着将MicroNet模型转换为int8量化TFLite格式，文件大小为210KB。将模型权重以C数组形式编译进固件，Flash占用变为85KB + 210KB = 295KB，剩余217KB，满足512KB的容量限制。
运行时RAM评估：设置tensor arena为64KB，运行推理并监控内存峰值。实测峰值RAM占用为58KB（包括输入张量3.2KB、输出张量0.3KB、中间激活约50KB、算子临时缓冲区4.5KB）。加上静态bss段15KB，总RAM占用约73KB，未超过80KB的预算。
时钟与延迟测试：在主频100MHz下，实测单次推理延迟为85ms，满足100ms的实时性要求。若延迟超标，可考虑将主频提升至100MHz以上（该芯片最高支持100MHz），或使用DMA加速MFCC特征采集以降低CPU负载。
外设评估：语音采集使用I2S接口连接数字麦克风，结果输出使用UART打印。STM32F411具备I2S和UART外设，且引脚配置无冲突。DMA用于I2S数据搬运，占用DMA1的Channel 0，无冲突。
结果与复盘：该方案在资源上完全可行，Flash剩余217KB可支持后续模型升级，RAM剩余55KB可增加调试日志或缓存。复盘发现，中间激活张量占用了大部分RAM，若改用深度可分离卷积或减少通道数，可进一步降低RAM峰值。此外，int8量化将模型从float32的840KB压缩至210KB，是部署成功的关键。
风险提示：在评估过程中，不要忽略堆栈（Stack）的占用。TFLite Micro的递归调用和中断处理可能消耗较多栈空间，建议在链接脚本中设置至少8KB的栈大小，并通过__stack_chk_guard或看门狗进行溢出检测。若堆栈溢出，会导致不可预料的程序跑飞。
常见误区与总结复盘
在MCU资源评估中，工程师常犯以下错误，需要特别警惕：
- 只关注Flash而忽略RAM：模型能存进Flash不代表能运行。很多模型权重不大，但中间激活张量巨大。例如，一个输入为224×224×3的模型，第一层卷积的激活就可能超过100KB，远超MCU的RAM容量。
- 忽略对齐和填充开销：编译器为了对齐访问，会在结构体、数组之间插入填充字节。TFLite Micro的tensor arena通常需要8字节对齐，这可能导致实际RAM占用比理论计算多5%~10%。
- 混淆Flash与RAM的读写速度：从Flash读取权重比从RAM读取慢2~3个周期。如果模型权重频繁被访问，且Flash接口没有缓存，推理延迟会显著增加。此时可考虑将部分权重复制到RAM中，但需权衡RAM容量。
- 外设评估只看数量不看复用：某些外设引脚是复用的（如PA9既可以是UART1_TX也可以是TIM1_CH2），配置冲突会导致外设无法同时使用。评估时必须查看芯片的引脚复用表（AF Table）。
- 忽略低功耗模式下的资源状态：如果设备需要进入睡眠模式，RAM在睡眠期间必须保持供电（否则数据丢失），而Flash可以断电。这会影响电池续航设计，需要在资源评估时一并考虑。
总结复盘：资源评估是TFLite Micro移植的"第一道关卡"，其核心目标是回答三个问题——模型能否装下（Flash）、能否跑起来（RAM）、能否跑得快（时钟+外设）。通过本章的量化评估方法，我们可以将模糊的"可能不行"转化为明确的"Flash剩余217KB、RAM峰值73KB、延迟85ms"等具体数据，为后续的依赖裁剪提供精确的输入。在实际项目中，建议将资源评估结果记录为一份清单文档，并在每次模型更新或代码修改后重新执行评估，确保资源余量始终处于可控范围。