做嵌入式开发这些年我经手过的开发板数量自己都数不清。从早期的各种评估板到后来的国产MCU小板子再到带屏幕带WiFi的全能型开发板抽屉里堆了好几层。但去年开始认真折腾TinyML这个方向之后我发现自己陷入了一个很尴尬的局面手头明明有那么多现成的、功能强大的开发板却找不到一块能让我舒舒服服做TinyML原型验证的板子。于是就有了这个项目——重新做一款为TinyML量身定制的开发板。很多人第一反应是网上那么多板子你直接买一块用不就完了何必费这个劲。我一开始也这么想过但实际把需求一条条列出来之后才发现通用开发板在TinyML这个细分领域里确实存在不少盲区。这篇文章就把我当时的完整思考过程、设计取舍、踩过的坑和最终的实现方案都整理出来希望能给同样在折腾TinyML的朋友一些参考。我需要先说明一下这篇文章既不是劝你抛弃现成开发板也不是让你按我这个方案重新造轮子。更实际的价值在于如果你在TinyML项目里遇到了类似“板子看着挺好但用起来总差点意思”的情况可以把这篇文章当成一个需求拆解的案例参考或者仅仅当作一份“如果我要做一块TinyML专用板我该考虑哪些问题”的清单。下面进入正题。1. 需求拆解为什么通用开发板在TinyML面前总差点意思先说结论通用开发板不是不能用而是它们的设计重心和TinyML的工作负载特性存在结构性错位。这个错位体现在好几个层面我一个个讲。1.1 功耗墙通用板的设计目标是“全能”而不是“省电”TinyML的核心场景是边缘端的低功耗推理。关键词是“低功耗”。但市面上绝大多数开发板的设计思路都是往“功能尽可能全、扩展尽可能多、跑起来尽可能无脑”这个方向走的。板载USB转串口、LED、按键、甚至屏和WiFi模块上个电CPU还没干活板子自身的静态功耗就已经吃掉了几十毫安甚至上百毫安。我拿手头的一块主流开发板做了个简单实测给它烧个空程序就一个while(1)空转用精密万用表串在供电回路里测整板功耗。结果非常稳定55毫安左右电压3.3V算下来整板空载功耗约180毫瓦。这在通用应用里完全没问题但对TinyML场景是个灾难。因为边缘端的典型形态是电池供电部署现场可能是一颗纽扣电池、两节干电池或者一组锂电池整板功耗直接决定了设备的续航能力。MCU本身的深度睡眠模式能做到微安级别结果板载的USB转串口芯片和电源指示灯就把省下来的功耗全吃回去了。你可能要问那我不用这些外设不就行了问题是板子上的元器件只要存在就会产生静态功耗。USB转串口芯片即使不通信只要上电就在耗电。LED限流电阻一直在发光。这些东西不是软件能关掉的除非你手动飞线切断某个电源轨——这就失去了开发板“拿来就能用”的意义。所以“重新做一款”的第一个核心动机就是把板载外设压低到极限让整板功耗曲线无限接近MCU本身的功耗特性。MCU说微安级整板就应该真的做到微安级。1.2 外设接口与传感器链路的错位第二个问题更隐蔽但它直接影响TinyML项目的实验效率。TinyML的典型流程是接传感器麦克风、IMU、温湿度、摄像头等采集数据在本地做好预处理然后丢给模型做推理。这里面有个关键环节——数据采集。传感器到MCU之间的接口形式和信号质量直接决定了后续模型能不能收敛、效果好不好。通用开发板的传感器接口设计通常比较“通用”。引脚引出、排针间距2.54mm、I2C和SPI总线放一起靠杜邦线飞线连接。这在低频场景没问题但一旦涉及麦克风这类模拟信号传感器、或者需要更高采样率的多轴IMU杜邦线和飞线的寄生电容和串扰就会开始捣乱。模拟麦克风信号尤其敏感。我之前在一块通用板上接模拟麦克风信号线走了一根15厘米左右的杜邦线采集到的语音波形高音部分明显衰减底噪也非常可观。做关键词唤醒的模型训练时这个数据集质量直接导致模型在真实设备上的准确率比预期低了将近10个百分点。另一个常见错位是电平匹配。部分传感器模块是5V逻辑而绝大多数TinyML主控MCU是3.3V甚至更低的工作电压。电平转换这个问题通用开发板通常不预置解决方案你得自己搭电路或者用电平转换模块。开发板阶段这可能只是一个小麻烦但等你从原型走向真实部署时这套临时搭建的链路就要全部重做。1.3 工具链与部署目标的偏差还有一个经常被忽视的维度开发板自带的工具链和TinyML工作流之间通常存在一层“摩擦”。现在主流的TinyML部署路径是把训练好的模型TensorFlow Lite格式或者ONNX格式通过量化工具转成MCU能跑的uint8/int8权重再借助CMSIS-NN或者厂商自带的NPU库加速推理。这个过程对芯片的指令集特性、内存布局、以及厂商SDK对模型转换工具的支持度都有要求。部分通用开发板的SDK重心在“快速调通外设驱动”和“跑通RTOS”对于模型推理框架的集成往往停留在“可以跑但没优化”的程度。CMSIS-NN在Cortex-M4和Cortex-M7上的加速效果差异很大如果板子选了一颗不带DSP指令或者没有FPU的低成本MCU同样的模型推理速度可能差出3到5倍。这类问题你在看开发板参数表的时候完全看不出来实际跑一遍才知道。综合这几点我意识到我需要的不再是“什么都能跑”的通用板而是“把TinyML每个环节都照顾到位”的垂直板。这不是在否定通用开发板的价值而是在承认一个事实——垂直场景的工具应该为垂直场景定制。2. 设计目标与选型思路一块板子的每一项参数都该有明确的“为什么”确定了要重新做一块板子之后接下来的问题就是它应该长什么样这个问题又可以拆成两个子问题硬件架构怎么选以及功能边界划在哪里。2.1 主控芯片选型算力与功耗的平衡不是看跑分而是看能效比TinyML对主控芯片的需求和传统嵌入式开发不完全一样。传统开发追求绝对性能或生态成熟TinyML更看重“在满足推理实时性的前提下功耗尽量低”也就是能效比。我在选型阶段锁定的候选方案有这么几类第一类超低功耗Cortex-M系列。比如Cortex-M4F或者Cortex-M7核心的MCU基础频率100MHz到200MHz带FPU和DSP指令。这类芯片的优势是生态成熟、参考资源多、CMSIS-NN优化直接可用而且深度睡眠功耗能做到微安级别。缺点是算力天花板不高跑稍大一点的模型比如几百KB的卷积网络会比较吃力。第二类带自定义NPU/向量扩展的MCU。比如集成NPU的MCU算力大幅提升但对应的开发复杂度、SDK成熟度、以及价格都上了台阶。对于一个“以验证和教学为主”的TinyML开发板这有点超出需求。我最终选了Cortex-M4F架构、主频150MHz、内置512KB Flash和128KB RAM的芯片。理由不复杂这个算力档位在TinyML最典型的应用场景关键词唤醒、异常检测、简单多分类里刚刚好不需要任何外部存储芯片并且能做到“一块芯片跑完整个工作流”——数据采集、预处理、推理、结果输出都在MCU内部完成。你可能注意到我刻意没提具体型号。原因有两个一是同样的选型思路可以对应好几款不同厂商的芯片具体哪颗最适合你自己的项目得看你的量产成本预期和采购习惯二是我不想让这篇文章变成某颗芯片的“软文”。授人以渔比推荐一颗芯片更有价值。2.2 功耗预算设计定下一个“很苛刻但不离谱”的目标然后拆解到每个元器件一旦确定了主控功耗预算就有了基线。我在项目需求文档里写下了这个数字整板深度睡眠模式下功耗不超过10微安。注意这是整板不是MCU单独的低功耗指标。所以设计时的每一颗元器件都要过一遍静态功耗的审查。首先是DC-DC/LDO选型。USB供电进来之后需要一组电源转换给MCU和外设。我对比了几种方案LDO静态功耗低但效率一般适合电流小的场景DC-DC效率高但静态功耗Iq通常比LDO大不少。对我这个场景来说关键是“睡眠时整板挂多少电流”而不是“高负载时效率差几个点”。所以我选了Iq只有1微安出头的超低功耗LDO而不是更常见的DC-DC。然后是USB转串口芯片。这是我决策里争议最大的一个点。很多开发板都会集成一颗USB转串口芯片为了方便插上线直接烧录和打印日志但这颗芯片即使是空闲状态也要吃掉几百微安到毫安级的电流。这个代价在通用开发板可以接受但在10微安目标面前完全不可接受。我的方案是板子默认不贴USB转串口芯片但预留焊盘。需要日志调试时你手上任何一颗几块钱的USB转串口小板飞两根线就能用不需要时焊盘空置静态功耗归零。这个决定被好几个朋友吐槽“不方便”但实测下来整板深度睡眠电流做到了6.7微安。知道板子本身不再拖后腿之后这种不方便是值得的。2.3 传感器接口设计把“实验环境”变成“部署环境”的预演传感器接口是这块板子和通用开发板差异最明显的地方。我在设计时定了一个原则原型阶段用怎样的接口部署阶段就应该沿用同样的接口。这个原则的思想很朴素却能省掉大量“原型能跑部署翻车”的返工。板上预留了一个麦克风接口走的是模拟差分输入麦克风可以直接焊到板上的专用焊盘区域旁边留了偏置电阻的位子。这样从麦克风到MCU的ADC输入走线长度控制在5毫米以内EMI和寄生电容的影响被压到最小。同时预留了I2C和SPI的排针用于接IMU和温湿度等数字传感器但这些接口可以复用为GPIO避免“接口不够用”的尴尬。还有一个细节板载一颗三轴加速度计。我把它和主控放在同一个PCB平面的对角位置关系让传感器板载这件事不会影响你外接高性能传感器的灵活性。板载IMU的意义在于很多TinyML入门实验比如活动识别、跌倒检测、震动分类不需要你额外接传感器插上USB就能开始采集数据大大降低上手的门槛。2.4 存储与内存规划128KB RAM到底够不够用内存这件事很多第一次接触TinyML的人会低估。我在前面提到选型选了128KB RAM这里展开讲讲这个数字是怎么算出来的。以关键词唤醒这个典型任务为例。假设我们用的是一个基于MFCC特征小型卷积网络的方案。原始音频采样率16kHz、16bit量化一秒钟音频数据就是32KB。如果我们做1秒的推理窗口那原始PCM数据就能吃掉32KB RAM。模型的中间激活值activation tensor取决于网络结构一个3到4层的小型卷积网络激活值通常还要再加20到40KB。再加上特征缓冲、DMA缓冲区、系统的栈和堆128KB RAM确实不算宽裕但认真规划一下是够用的。关键技巧是分时复用。原始音频数据经过特征提取之后就不再需要保留这块缓冲区可以用来存放中间激活值。只要在软件层面规划好buffer的生命周期128KB能完成很多看起来“内存不够”的任务。Flash存储方面512KB的空间需要拆成几块Bootloader和OTA升级区、模型权重区、程序代码区。量化后的模型权重比率较密度高一个关键词唤醒模型大概在50KB到150KB之间加上代码和基础库512KB算是“有余量但不铺张”的状态。3. 从原理图到实测一块板子的落地过程与真实数据设计目标定清楚了接下来就是动手画板子、打样、焊接、调通的完整流程。这个阶段虽然没有什么奇迹般的技术突破但有不少值得记录的细节和经验。3.1 原理图与PCB设计中的几个关键取舍原理图层面最重要的几个决策我在前面已经说过不贴USB转串口、低静态功耗LDO、传感器走线短化。PCB布局层面则有几个新的考量。第一Layer选择。我做了双层板而不是四层板。原因一是成本打样双面板几十片以内非常便宜二是这个板子频率不高150MHz的MCU、I2C和SPI走线双面板的参考平面和走线控制完全够用。四层板当然能提供更完整的电源平面但对这个项目属于“花哨但有剩余”的方案。第二电源去耦。MCU的每个电源引脚附近都放置了100nF的MLCC电容这是标配操作。但在给模拟麦克风供电的分支上我额外加了一颗小的磁珠和100uF电解电容用来隔离数字开关噪声。这个细节直接影响了ADC采样数据的底噪水平实测下来音频输入通路的本底噪声比第一个版本低了一个量级。第三天线区域预留。虽然这颗主控芯片不带射频功能但我在PCB角落预留了一个独立的天线净空区域。为什么因为TinyML项目做深了几乎必然会想加无线传输蓝牙或者WiFi模块来把推理结果上报。预留天线净空意味着后续无论你选哪种无线模块都有空间做匹配网络不至于重新改板。3.2 实测数据整板功耗、推理速度、内存占用的第一手记录板子打样回来后我做了三轮完整测试。第一轮是功耗摸底第二轮是模型推理性能压测第三轮是连续运行稳定性测试。下面这组数据是第三批板子的实测平均值有一定代表性。测试项测试条件实测结果深度睡眠整板电流关闭所有LED无外设接入6.7μA运行态电流空跑150MHz全速while(1)空转8.2mA运行态电流负载MFCC特征提取推理循环22.5mA关键词唤醒推理时间小型CNN输入40ms音频帧58ms异常检测推理时间三轴加速度数据全连接网络4.8ms这个功耗数据说明了什么如果设备用一节2450纽扣电池供电标称容量约550mAh跑一个每5秒唤醒一次、每次负载工作1秒的检测任务理论续航可以做到400天以上真正进入了“部署级”设备的功耗区间。这是通用开发板做不出来的数字。内存占用方面我那份关键词唤醒工程的完整占用情况是Flash用了280KB其中模型权重95KB代码和框架185KBRAM峰值占用96KB。离128KB上限还有一定余量可以再塞进去一些代码缓存或者数据缓存。如果后续模型需要加大把量化从int8降到int4或者在精度损失可接受的范围内做权重剪枝也还有继续优化的空间。3.3 从“能跑”到“好用”的开发体验打磨硬件只是载体真正让一块开发板产生价值的是配套的开发体验。这块板子重新做的价值很大程度体现在软件侧的配套上。我准备了一套完整的示例代码按难度递进组织第一个示例是最低成本的“点灯”——但这里的“灯”不是普通LED而是通过麦克风检测到特定频率的音频信号在状态GPIO上输出高电平。这个示例把“信号采集-特征判断-输出动作”的最小闭环跑通让新用户理解TinyML应用的基本链路。第二个示例是活动识别。板载加速度计采集三轴数据用轻量级全连接网络识别“静止/行走/剧烈运动”三种状态结果通过串口输出到主机端。这里面包含了数据采集频率设置、滑动窗口切分、特征归一化、推理结果平滑等一整套TinyML工程化必备的处理流程。第三个示例是关键词唤醒——在板子上部署完整的关键词识别模型连续识别中文/英文关键词输出置信度分数。这个示例涉及音频数据的双缓冲、MFCC特征提取的实时性优化、以及阈值判断策略是目前最完整的参考工程。除示例代码外配套脚本里有完整的模型训练和量化转换流程从数据集的预处理到keras训练脚本再到TFLite转换和C数组导出全部脚本化。这样用户从“想识别一个新的动作”到“模型在板子上跑起来”全程不需要手动搬运文件或者改代码一条命令就能完成。4. 重回问题原点为什么要费这个劲写到这儿最初的问题——为什么有那么多开发板还要自己做一款——答案已经藏在上面的每一段里了。但我还是想把思考过程再提炼一下因为这个问题背后其实是一种方法论的选择。4.1 通用开发板是“验证想法”的工具但我需要的是“验证部署”的工具通用开发板的核心价值是让你用最小的成本验证“这个想法是否成立”。比如你想测一个麦克风数据分类的可行性随便找一块带麦克风的开发板就能跑demo。但这种验证停留在“功能层面”离“部署层面”还有一段距离。TinyML这个领域的特殊性在于它极度强调端侧资源受限功耗和内存的每一分富余都在转化为成本或续航的代价。如果你的原型板整板功耗比MCU功耗高二十倍那你验证出来的功耗数据毫无参考意义如果你的传感器链路靠飞线连接那你采集的数据质量和最终部署时的一致性问题就会被掩盖到最后一刻才发现。对通用开发板的定位我从一开始就理解并认同——它们降低了嵌入式开发的门槛让硬件验证变得简单。但当我需要的验证从“功能”转向“功耗、形态、稳定性、部署表现”时通用板的能力边界就显露出来了。做一块专用板本质上是在回答一个通用板没有替我回答的问题这个应用真正落到现场时最小的可行硬件形态是什么4.2 重新做一块板子的真正成本比你想象的低很多人不愿意自己设计硬件是因为觉得“画板子高门槛”。但近年的情况已经大不相同。免费EDA工具和低价PCB打样服务把硬件迭代周期压缩到了“一周打样、一周回板、一周调通”的快节奏里。你不一定需要是资深的PCB工程师只要把需求拆解清楚、照着参考设计画图就足以完成一条可用的板子。时间成本也是一笔值得算的账。重新设计一块板子大约需要三周——一周画原理图和PCB一周等打样回板一周焊接调试。而在这之前我花了一个多月在通用开发板上四处打补丁试图用飞线和魔改去弥补它与真实部署条件之间的差距收效甚微。回头看去这笔时间投资性价比不高。所以我的建议是如果你的TinyML项目只是跑个demo验证模型效果那么现成开发板完全够用不用折腾但如果你已经确定要往真实部署方向走那从开发板阶段就往“部署条件靠拢”反而是更快的路线。硬件设计的门槛在降低而TinyML应用对硬件的要求却在提高这两条曲线的交叉点就是值得投入自研板卡的时机。5. 实测中遇到的坑与硬件调试心得光有设计和预期是远远不够的硬件这东西最诚实哪里有问题一上电就暴露。这部分我把调试过程中踩过的坑和排查思路整理出来给准备做类似板子的朋友参考。5.1 低功耗设计里的“意料之外漏电”第一版板子回来后整板深度睡眠电流用万用表一测45微安。离设计目标10微安差了4倍多。这个排查过程几乎就是低功耗嵌入式硬件维护的典型案例。第一步断开所有跳线让主控进入深度睡眠。电流几乎没有下降。这就说明漏电大头不在MCU。第二步用电流表短接排查每一棵可能耗电的元器件旁边的去耦电容——不对这不是排查方法。实际做法是用“排除法”逐一拆掉非必要元器件每次拆完重新测一次待机电流。拆掉LDO输出端的电压检测分压电阻电流下降大约30微安。这是一个经典的“隐藏吸血鬼”——电源路径上用来监控电池电压的分压电阻网络只要设计时用了低电阻值为了抗噪声就会在睡眠时持续给GND漏电流。后来我把分压电阻的总阻值提高到兆欧级别同时做了软件校准补偿睡眠电流立刻就降下来了。另外一处的漏电可以追溯到板载加速度计的电源管脚。我给它供电的是常开电源轨这意味着即使主控进入睡眠IMU也在工作。IMU本身有大约10微安的待机电流。这部分的让渡是“主动选择”——IMU保持工作才能支持唤醒功能。但如果不需要唤醒软件里也可以通过切换电源轨来彻底断电。最终把这两处问题处理完之后整板睡眠电流从45微安降到6.7微安。这个数据让我很满意。5.2 模拟麦克风采集的底噪处理第一版板子的麦克风通路底噪偏大录出来的音频波形毛刺很明显。排查之后发现是地回路问题。麦克风信号的地线和MCU的数字地混在了一起数字总线的开关噪声耦合进了模拟前端。解决方法是把模拟地和数字地单点连接在PCB布局上用一小段“地桥”一个零欧电阻或磁珠连接两个地平面。这样数字部分的噪声电流就不会经过模拟信号的返回路径。调整后底噪下降了约10dB以上。如果你画的板子也遇到类似问题可以先检查麦克风的线路布局信号线是否避开高频数字走线地返回路径是否尽量短、尽量宽模拟地和数字地是否做了分隔。这三条检查完大部分音频底噪问题都能找到原因。5.3 用Nucleo板做的对照实验证明专用板的必要性这里有一段可以公开的数据我用同样的MCU主控和同样版本的模型在一款通用开发板和这款自制专用板之间做了对照测试。两个板子跑的推理性能几乎相同这是意料之中的——芯片相同算力上限也就相同。但整板功耗的差异非常明显在相同深度睡眠配置下通用板的整板电流约为37微安自制板为6.7微安。频率在500kHz的轻度唤醒场景下通用板的平均电流约0.9mA自制板只有0.21mA。也就是说在相同的MCU算力起点下专用板在电池供电场景里的续航能力能达到通用板的4倍以上。这个对比不是我的板子做得多精巧而是通用板在低功耗场景里确实背负了太多“为方便二付的账”。开发板为了方便你快速上手加了各种功能但你的部署场景并不需要这些功能时每一颗额外元器件都在消耗你的续航。6. 常见问题速查新手上路最容易踩的五个坑这块板子从设计到调试的过程中我在多个方面都有值得记录的失败这里整理成一个FAQ清单对照排查你会省很多时间。Q1睡眠模式下整板电流始终测不到微安级别总是停留在几十毫安可能是什么问题按优先级排查用户侧USB的转串口芯片是否有接常电板载电源指示LED是否只做了一个独立的焊接位而没接在受控电源轨上模拟麦克风的偏置电阻和前置放大电路是否仍在工作这三处是新手最容易忽略但又最影响整板静态功耗的地方。Q2为什么用相同的MCU模型推理速度比参考数据慢了一半最常见的原因是编译优化等级没有开满。CMSIS-NN的性能依赖编译器的优化选项以及是否正确启用了FPU/DSP指令。另一个高频原因DMA没有配置导致memcpy和卷积计算都在CPU上跑。Q3模型已经量化成uint8了Flash里也放了权重但推理时总是复位重启大概率是哪里出问题几乎可以断定是内存越界。TinyML工程中最典型的死法是模型中间缓冲区与特征缓冲区共用时没有对齐边界或者激活值buffer小于模型实际需求。用IDE的调试器先把内存断点设到RAM末尾区域复现推理过程定位越界点。Q4传感器采集的数据在电脑上看波形没问题但模型推理结果就是不对检查一下数据的对齐方式。部分模型训练时用的数据做了归一化但部署代码里没有做对应的逆归一化。这个问题非常隐蔽表现出来就是“模型在训练集上指标很高在板子上完全不能用”。Q5板子插USB能被识别到但烧录程序总失败优先检查Bootloader区是否被覆盖。很多TinyML工程会把模型权重直接放在Flash起始地址如果不小心把Bootloader覆盖了芯片会进入“假砖”状态。解决方法是先在IDE里勾选“擦除整片Flash”重新烧录Bootloader再烧应用。7. 这批板子的后续扩展方向与个人体会最后一个环节我不打算写展望式的总结就聊聊这块板子做完之后我个人的感受以及对后续扩展的真实想法。第一个扩展方向是加入无线通信。板子上预留的天线净空区域我已经在试着一个低功耗蓝牙模块的匹配方案目标是让它能把推理结果以低功耗方式传回手机或者网关。这个方向一旦跑通板子就从“开发板”形态过渡到了“边缘节点原型”的完整形态。无线和功耗这两个关键词一旦绑定能做的应用就宽了很多。第二个方向是模型部署工具的进一步集成。我下一步想把TFLite的micro工具链直接做到IDE的插件里让用户在工程里右键就能看到“当前RAM/Flash占用”和“推理时间预估”省去手动算内存那些繁琐事。回到最初那个问题——有那么多现成的开发板为什么还要费劲做一款。我现在能给出的回答不再是纯粹的技术理由而是一种选择通用开发板让你能快速开始专用板让你能走得更远。如果你手头的项目长期要待在“部署”这个语境里那些通用板上的“方便”就会变成一根根看不见的锚拖在你的续航、尺寸、成本和稳定性后面。重新做一块板子不是对现有工具的否定而是在明确自己的需求之后在最近的路上删掉了所有多余的东西。最后再分享一个经验自己做硬件这件事情别怕走弯路也别等到“完全准备好”才动手。因为我就是从一块有瑕疵的1.0版开始的踩过坑、掉过电、飞过线才到现在的6.7微安。这个过程虽然需要一些成本但收获的那种“从需求到软硬件一体都心中有数”的感觉是买现成板子拿不到的东西。如果你也打算走这条路希望这篇文章能帮你少踩几个坑。