1. STM32MP边缘AI部署全景

STM32MP系列是ST在通用微处理器（MPU）与微控制器（MCU）之间架起的一座“异构桥梁”。它不是把Cortex-A和Cortex-M简单拼在一起，而是让两类内核在同一颗芯片上各司其职：Cortex-A负责操作系统、网络、文件系统、摄像头与显示等复杂任务；Cortex-M负责实时控制、传感器采集、电机驱动、安全监控等确定性任务。边缘AI推理部署的核心，就是让模型在合适的内核上运行，并让两个世界通过共享内存与消息机制高效协作。

一、异构架构：A核与M核的分工

以STM32MP157为例，芯片内部包含双核Cortex-A7（最高约650MHz~800MHz，视具体型号与散热条件而定）和单核Cortex-M4（最高约209MHz）。A7侧通常运行Linux（如OpenSTLinux），拥有MMU、DDR控制器、GPU、显示接口和丰富的外设；M4侧运行裸机或RTOS（如FreeRTOS），拥有独立的NVIC、低延迟中断和确定性外设。两者通过内部总线与IPCC（处理器间通信控制器）连接，并共享一块DDR区域用于大数据交换。

这种分工决定了AI推理的部署策略：大模型、复杂预处理、多路视频分析通常放在A核Linux侧，借助NEON SIMD和GPU加速；小模型、低延迟、硬实时闭环则放在M核侧，借助CMSIS-NN和DSP指令。两者不是替代关系，而是互补关系。

二、边缘AI推理部署流程

从PC端训练好的模型到STM32MP上稳定运行，通常经历五个阶段：模型训练与导出、模型转换与量化、交叉编译与打包、目标板部署、性能与精度验证。每个阶段都有明确的输入输出和判断依据。

以图像分类任务为例，假设在PC端用TensorFlow训练了一个输入为224×224×3的MobileNetV2模型，准确率约92%。第一步导出为SavedModel或ONNX格式；第二步使用STM32Cube.AI或TensorFlow Lite Converter将其转换为目标格式。若部署到M核，通常需要做int8量化，把浮点权重和激活值映射到8位整数，模型体积可缩小约4倍，推理速度提升2~4倍，但准确率可能下降1~3个百分点，需用验证集确认是否可接受。

第三步交叉编译：A核侧用Yocto/OpenSTLinux SDK编译Linux应用，链接TFLite或ONNX Runtime库；M核侧用STM32CubeIDE或Makefile编译固件，链接CMSIS-NN和Cube.AI生成的代码。第四步通过STM32CubeProgrammer烧录固件，通过SCP或NFS把Linux应用和模型文件放到目标板。第五步在目标板上运行推理，用/usr/bin/time或应用内计时统计单帧耗时，用测试集统计精度，并与PC端结果对比。

三、工具链总览

STM32MP的边缘AI工具链可以按“模型侧”和“系统侧”两条线理解。模型侧包括：STM32Cube.AI（把Keras/TFLite/ONNX模型转成C代码，支持M核和A核）、TensorFlow Lite for Microcontrollers（M核轻量推理）、ONNX Runtime（A核多框架支持）、X-CUBE-AI（Cube.AI的扩展包）。系统侧包括：OpenSTLinux发行版、Yocto构建系统、STM32CubeProgrammer、STM32CubeIDE、以及用于性能分析的perf、gprof和STM32CubeMonitor。

四、部署时最容易踩的坑

第一，内存边界不清。A核Linux有MMU，M核通常无MMU或使用MPU，共享内存的地址映射必须两边一致，否则会出现“A核写进去、M核读出来是乱码”。第二，量化校准集选择不当。int8量化需要代表性校准数据，若只用少量随机图片，激活值范围估计偏差大，精度会明显下降。第三，实时性误判。M核虽然快，但如果模型层数多、算子不被CMSIS-NN支持，实际耗时可能远超预期，必须用DWT周期计数器实测。第四，工具链版本不匹配。Cube.AI、CubeIDE、OpenSTLinux SDK版本之间常有依赖关系，建议锁定一套经过验证的版本组合。