初入行的困惑
刚毕业那会儿，我进了一家做工业控制的小公司。对桌坐着个老工程师，工位杂乱无章，显示器旁贴着一张皱巴巴的便利贴，上面写着："先跑通，再跑好"。
当时年轻气盛，觉得这话太简单，没什么技术含量。直到后来吃了不少苦头，才明白这句话的分量。
代码背后的责任
记得有次调I2C通信，整整三天没搞定。师父走过来看了五分钟，利落地解决了问题。晚上他请我吃烧烤，第一句话就让我记忆犹新："你写的每行代码，都可能变成别人凌晨三点接到的紧急电话。"
他给我讲了个真实案例。公司以前做过一个温度控制项目，新来的工程师写的程序。测试阶段一切正常，但上线几个月后出了事——冬天半夜，传感器接触不良，数据异常，程序没有容错机制，系统持续加热。等值班人员察觉，温度已经远远超出安全范围。
那位同事最后离开了这个行业。不是技术能力不行，而是承受不住这种压力。
师父用筷子敲着桌子说："做嵌入式开发，代码是要跑在生产设备、医疗器械、行驶车辆里的。一个异常情况没考虑到，造成的损失可能是巨大的。在学校里，代码跑通就算过关。在这里，跑通只是起点。"
那晚回家后，我翻看自己写的程序，发现自己所谓的"完成"，其实只是在特定环境下没有报错而已。
关于技术选型的认知
我年轻时有个毛病，看到新出的芯片就想换项目，听说某款功耗更低就想迁移。师父总是说："先把手里这颗吃透。"
有次我跟他争论："现在主流都换架构了，我为什么还要抱着老方案不放？"
他没直接回答，从抽屉里翻出一块旧电路板。上面的芯片早该淘汰了，但还在客户现场稳定运行。
"知道为什么客户不愿意换吗？不是因为成本。是这个方案跑了十几年，所有潜在问题都被发现了。它的极限温度特性、电磁干扰表现、异常复位条件，我们都了如指掌。换新方案？可以，但你要花多长时间把同样的坑再踩一遍？"
他接着说："追新技术是市场人员的事，工程师追求的是可靠性。把一款芯片的规格书翻透，把它的所有特性摸清，比你粗略掌握十种新工具更有价值。"
后来我按照他说的去做，把常用芯片的技术手册从头到尾研究了一遍，用仪器测量每种接口的时序。半年后，调试通信协议时不用查手册，时序图就在脑子里。那种扎实的感觉，是以前追新方案时从未体验过的。
调试的思维方式
师父有句话，我现在还贴在工位上："调试时，先检查自己的代码，再排查硬件问题，最后才考虑芯片缺陷。"
太多新手遇到问题，第一反应是怀疑工具、怀疑器件、怀疑设计。我也犯过这样的错。有次SPI读取数据总是出错，我信誓旦旦跟硬件同事说："你的布线肯定有问题。"
同事被我纠缠得没办法，拉着我一起排查。最后发现是我自己的DMA配置出了差错——缓冲区地址没有对齐。芯片没问题，电路板没问题，问题出在我自己身上。
师父知道后说了一句话："调试的本质，是在培养一种确定感。每排除一个因素，你的把握就多一分。急着把问题推给别人，你的能力就永远停留在原地。"
从那以后，我养成了一个习惯：出问题先假设自己是个新手。把代码逐行检查，把信号逐帧分析，把每个中间状态都打印出来。通常找到原因时都会自责——但正是这种"自责"，次数越多，成长越快。
传承
师父去年退休了，临走时把他那本旧便利贴本子留给了我。里面记录了将近二十年的经验点滴。
有一条写于十几年前的笔记让我感触很深："嵌入式工程师的价值，不在于用了多先进的芯片，而在于系统出故障时，你能多快定位并解决问题。"
现在我也开始带新人了，也会请他们吃饭聊天，也会讲那个温度控制的故事。有些人听了会认真思考，有些人只是听过就算了。这很正常——这行真正的领悟，不是听来的，是自己吃亏吃出来的。
如果你现在正被一个简单的协议搞到头大，正盯着示波器发呆，正在犹豫要不要转行——再坚持一下。等你走过了"觉得自己都懂"到"发现自己什么都不懂"再到"真正明白了一些"的过程，你会感谢现在没有放弃的自己。
结语
师父没教过我什么高深的理论。但他让我懂得：做嵌入式这一行，最终考验的不是智商，而是对每一个细节的敬畏。
致敬这个行业，致敬代码里那些隐蔽的缺陷，也致敬每一个还在现场排查问题的工程师。
