嵌入式系统设计：那些课本没教你的冷门行业经验
别迷信通用框架，嵌入式的核心永远是定制化适配
现在网上一搜嵌入式教程，铺天盖地都是“10天学会RTOS开发”“百套项目例程免费拿”，新手跟着抄，跑通亮个灯就觉得自己会了。一到实际项目，全瞎。
去年我帮一家做智能门锁的小厂改方案，他们找了个刚毕业的学生做设计，用了网上现成的低功耗RTOS框架，功能全对，就是待机电流怎么都降不到要求的10uA以下，换了三家芯片都不行，差点把整个项目黄了！我拿到手翻了三天代码，最后在框架的初始化文件里找到了问题：通用框架为了兼容所有外设，默认开了一个I2C的外设时钟，他们产品根本不用这个I2C，代码里也没关，就这么个小地方，待机电流多了快80uA。关了之后，一下子就达标了。
智能门锁嵌入式低功耗系统电路图
你说这是谁的错？框架本身没错，错的是很多做设计的人，忘了嵌入式从出生那天起，就是为特定硬件、特定场景服务的。没有通用的好设计，只有适合你产品的好设计。对吧？很多人吹什么“一次设计到处用”，那都是卖框架的噱头，真拿过来用，坑死你不偿命。不过话说回来，现在行业迭代快，赶项目工期，用成熟框架没错，但你得砍，得改，得把不符合你产品的东西全删掉，别留着占资源。
边缘AI爆发，嵌入式系统设计迎来新的底层逻辑
放在五年前，嵌入式系统设计大部分还是做控制，读传感器，发数据，跑个简单的算法，对资源的要求不高。现在不一样了，智能摄像头要做人脸检测，扫地机器人要做路径规划，就连一块智能手表都要跑个大模型语音交互，所有的AI推理都往边缘端放，这对嵌入式设计的要求完全变了。
我上个月帮一个做智能摄像头的客户调性能，他们用的是中端的RISC-V嵌入式芯片，要跑1080P的人脸识别推理，原来的设计帧率只有12帧，达不到要求的25帧，找了好多人都调不上去。什么问题？他们直接把训练好的模型转了个格式就烧进去了，根本没做量化裁剪，也没按照芯片的缓存大小做层拆分，大模型整个塞进RAM，每次推理都要频繁换页，能不卡吗？最后我们把模型做了INT8量化，剪掉了三个没用的卷积层，又按照芯片的L2缓存大小拆分了特征图，帧率直接跑到31帧，功耗还降了20%。
边缘AI嵌入式开发板推理性能测试图
说实话，现在很多做传统嵌入式的开发者，都不太愿意转AI方向，觉得太难。其实核心逻辑没变，还是那一套：适配硬件，裁剪资源，榨干每一点性能。只不过以前你榨的是IO和功耗，现在你榨的是内存和算力而已。
三个没人愿意说，但能救你项目的冷门细节
三个没人愿意说，但能救你项目的冷门细节
做了十几年嵌入式，我踩过的坑比写过的代码还多，说三个最容易忽略，也最重要的细节，记下来，哪天能用得上。
第一个就是上电时序一定要留容错裕量。很多新手做设计，对着datasheet给的时序参数，一分不差的写代码，一点裕量都不留。看起来完全符合规范，结果不同批次的芯片，工艺有波动，环境温度一变，就总有一定概率开不了机，你排查死都找不到原因。我一般不管datasheet给的参数是多少，至少留10%以上的延时裕量，真的多花不了几个功耗，能帮你省掉多少批量退货的麻烦。
第二个就是一定要留异常复位的日志标记。产品跑出去，跑了三五个月，偶尔死一次机，你根本找不到原因，是电压波动？还是硬件干扰？还是代码跑飞了？提前在Flash的某个固定地址，留几个字节的标记，每次复位前把原因写进去，下次开机读一下就知道了，能省你大半年的排查时间，成本就是几个字节的Flash，几分钱的事。
第三个就是量产一定要预留调试焊盘。很多硬件工程师为了省成本，省PCB空间，直接把JTAG或者SWD调试口给砍了，说反正量产不用。我就问你，万一批量出问题，你要刷机要排查，难道把产品全部拆回来？留几个焊盘能占多大地方？能花几分钱？我见过最夸张的案例，一个团队省了四个调试焊盘，最后批量出货一万台，出了软件bug，全要召回刷机，光运费加人工就花了几十万，找谁说理去？
嵌入式系统设计这行，看起来门槛不高，谁都能抄两行程点个灯，真要做好，比很多看似高大上的方向磨人。你得懂硬件，懂软件，懂算法，还得细心，能抠得住那些别人看不到的细节。别信那些几天速成的神话，功夫都是踩坑踩出来的。