经过一段时间的调试与准备，这块 TinyML 开发板终于稳定下来。今天想重新梳理一个问题：做一块 TinyML 开发板，是不是选一颗算力更强的 MCU 就够了？
规划 STM32H743 开发板时，我反复对照一条实际开发链路：设备先采到数据，在电脑上训练并转换模型，再把模型部署到 MCU，让它处理新采集的数据，最后由 MCU 把判断结果送回设备。
从这条链路往回看，开发板要解决四件事：算得动、采得到、看得清、接得出去。少了任何一环，实验都可能停在“模型文件已经生成”或者“串口打印了一个数字”这一步。
图：这块板上能看到麦克风模块、LCD、USB 与外部接线端子。
一、MCU 要留出模型之外的运行空间
这块板的主控是 STM32H743，采用 Cortex-M7 内核，带 DSP 指令，适合学习传感器分类、声音识别等小模型的 CPU 推理。选型时，我不只看主频，还会关注模型与固件放在哪里、运行时内存从哪里分配，以及一次推理能不能赶在下一批数据到来前完成。
例如用 TensorFlow Lite Micro 部署模型时，模型文件通常放在 Flash 或可读取的外部存储中；运行时还要为输入、输出、中间张量和算子工作区安排 RAM。模型文件能放进 Flash，只解决了存储问题。如果音频缓存、显示缓存和推理工作区同时占用内存，还要核算它们的峰值，不能只按模型文件大小选 MCU。
我在板上安排扩展存储，也是为了给模型、采集数据和图像缓冲留空间。不过外部 Flash 或 SDRAM 并不会自动让推理更快：代码和数据实际落在哪块存储、总线带宽及缓存配置，都要通过工程测试确认。最直接的验收方式，是让固件持续采样，同时记录最大内存占用和每次推理耗时。
二、传感器入口决定了能做什么案例
单片机内部的模型看见的是一串数字。数字从哪里来，决定了这块板能不能从演示走向自己的应用。
我选择保留声音、六轴运动、模拟量和摄像头这几类入口。麦克风适合做声音分类；IMU 可以提供加速度和角速度，用于动作识别；模拟量接口可以接入经过调理的电流、电压或其他传感器信号；摄像头接口则给低分辨率图像实验留下空间。
接口数量只是第一步。举个动作识别的例子：同一个 IMU，如果训练时按固定频率采集，到了板端却忽快忽慢地取样，模型收到的时间窗口就变了。声音也一样，麦克风位置、采样率和前处理一变，输入特征会跟着变。做 TinyML 时，开发板要让人既能采到数据，也能把采集条件记录下来，方便在电脑训练和板端推理之间对齐。
摄像头能插上，并不等于这颗 MCU 适合跑复杂的实时目标检测。图像分辨率、帧缓存和模型计算量都要单独评估；这块板更适合从小尺寸图像分类或简单的视觉判断开始。
三、模型识别了什么，要能当场看出来
初次下载模型时，我最想知道的通常有四项：输入张量是否填对，模型输出了哪一类，各类别分数如何变化，一次推理用了多久。
这也是板上保留 LCD、串口和 USB 的原因。LCD 适合直接显示当前识别结果和采样波形；串口日志便于保存连续输入、输出以及时间戳；USB 方便连接电脑进行调试和数据传输。不同的观察方式可以互相核对。比如屏幕上类别一直不变，先从串口确认原始采样值是否在变化，再看模型输入有没有更新。
分类分数可以帮助比较候选类别，但未经校准时，不宜把“0.92”直接解释为“判断正确的概率是 92%”。面向工程调试，我更希望屏幕能同时显示类别、分数、采样状态和推理时间。只亮一个 LED，定位不了输入错误，也看不出结果为什么会跳变。
四、最后还要把判断结果交给设备
模型输出“电机异常”之后，开发板还需要决定如何传递这个结果。可以通过 UART 或 CAN 向上位机和其他控制器发送状态，也可以通过 GPIO、PWM 或扩展的驱动电路进行联动。
这里有一条边界：继电器线圈和电机不能直接由 MCU 引脚驱动，模型的一次分类结果也不宜直接决定危险动作。 需要驱动与隔离电路、连续确认或状态机，以及独立的过流、过温等硬件和固件保护。开发板上的扩展接口，给这些外部电路提供连接位置；具体负载能否接入，仍要看驱动和供电设计。
完整实验可以从一个很小的动作开始：IMU 采集数据，MCU 输出动作类别，LCD 显示当前状态；稳定识别后，再用 UART 或 CAN 发出状态帧。到这一步，输入、模型和设备输出已经接成一条可检查的链路。
所以在设计这块板时，我希望四类硬件各有明确任务：STM32H743 负责计算，传感器与模拟量接口提供数据，LCD 与串口解释运行结果，通信和扩展接口连接外部设备。训练仍在电脑上完成；开发板要承担的是从现场采集到板端推理，再到结果输出的这半条工程链路。
发表于 昨天 23:48
|
查看: 5|
回复: 0
