★ FEATURED ARTICLE 从0做到量产然后被裁这八个字放在一起做过硬件的人看了大概率会沉默几秒。我是在一个周五下午收到通知的项目刚过完量产评审产线良率爬到了96%以上我负责的板子从原理图第一版到最终量产文件前后改了七版。HR约我谈话的时候我手里还拿着刚打印出来的EMC整改报告。这篇文章不打算贩卖焦虑也不打算写什么行业观察我只想把这三年从零到量产的全过程拆开把那些真正踩过的坑、那些没人会写在教科书里的经验、以及最后被裁时我复盘出来的问题一条一条讲清楚。如果你是刚入行的嵌入式硬件工程师或者正在经历从样机到量产的痛苦阶段这篇内容应该能帮你少走至少半年的弯路。1. 从零到样机那些看起来最不起眼却最致命的选型决策1.1 主控选型不是选性能最强的而是选你最熟悉的我刚进这家公司的时候项目还处于概念阶段。产品是一个带无线通信功能的工业数据采集终端需求文档写得比较粗核心指标就几条支持4G Cat.1通信、本地存储不少于8GB、工作温度-40到85摄氏度、整机功耗在待机状态下低于2瓦。老板给的时间是四个月出样机六个月小批量一年内量产。我拿到的第一个任务是选主控。当时市面上主流的方案有几类STM32MP1系列、NXP的i.MX6ULL、全志的R系列还有瑞芯微的RV1109。我一开始倾向于选i.MX6ULL因为资料多、社区活跃、之前在学校做过类似的项目。但团队里另一个老工程师建议用STM32MP157理由是双核架构A7跑LinuxM4跑实时任务一颗芯片搞定所有事。我当时的判断是双核架构听起来很美但实际调试复杂度会成倍增加。A7和M4之间的通信机制、资源分配、启动流程每一个环节都可能成为项目延期的理由。而且STM32MP157的BGA封装对PCB层数要求更高至少需要六层板成本直接上去了。最终我们选了i.MX6ULL单核A7主频528MHzDDR3内存512MBNAND Flash 256MB。这个配置放在2024年确实不算先进但对于我们的应用场景来说完全够用。这里我想说的是选型的时候不要被“性能过剩”带偏。很多刚入行的工程师会觉得主频越高越好、核心越多越好但实际项目中你真正需要的是稳定的供货周期、成熟的BSP支持、你团队能hold住的调试难度。i.MX6ULL的BSP是NXP官方维护的Yocto工程直接能用内核版本从4.1到5.15都有支持这一点在后期量产时救了我们很多次。1.2 电源树设计别等到EMC测试不过再回头改电源部分是我踩的第一个大坑。样机阶段我们用的是分立DC-DC加LDO的方案输入12V经过两级降压得到5V、3.3V、1.8V和1.2V。原理图看起来没问题样机也能跑起来但到了EMC预测试的时候辐射骚扰在30MHz到100MHz频段超标了将近6dB。排查过程很痛苦。我们先用近场探头定位发现噪声主要来自第一级DC-DC的开关节点。换了屏蔽电感、加了RC吸收电路、调整了开关频率折腾了两周才勉强压下去。但代价是效率从92%降到了87%发热量明显增加。后来复盘的时候一个做电源出身的朋友跟我说了一句话电源树的设计应该在原理图阶段就考虑EMC而不是等测试不过再补救。具体来说DC-DC的输入输出电容要尽量靠近芯片引脚开关回路的面积要尽可能小电感要选屏蔽式的反馈走线要远离开关节点。这些听起来都是基础知识但在实际画板的时候布局工程师往往优先考虑信号走线电源部分被压缩在角落里问题就出来了。我们最终的解决方案是换了一颗集成度更高的PMIC把多路电源集成在一颗芯片里开关频率统一到2MHz外围元件数量减少了三分之一EMC问题自然缓解了很多。这颗PMIC的单片价格比原来分立方案贵了将近两块钱但考虑到EMC整改的人力成本和时间成本这笔账是划算的。1.3 接口防护量产阶段最容易出批量事故的地方样机阶段我们只做了三台接口防护基本没怎么考虑。RS485接口直接用了TVS管USB接口加了ESD保护看起来该有的都有了。但到了小批量试产的时候第一批50台机器发到现场不到一个月就有7台返修问题全部出在RS485接口上。拆开分析后发现TVS管的钳位电压选高了。我们用的是SMBJ6.5CA钳位电压在10.5V左右而RS485收发器的绝对最大耐压是-8V到13V。理论上没问题但实际现场环境中雷击浪涌和静电放电的能量远超标称值TVS管响应速度不够快收发器芯片直接被击穿。后来我们换成了响应速度更快的ESD保护器件同时在RS485的A/B线上串联了10欧姆的电阻配合共模电感使用。这个方案增加了不到一块钱的成本但返修率直接降到了零。这件事让我明白一个道理接口防护不是“有就行”而是要针对实际使用环境做针对性设计。工业现场的电磁环境比实验室恶劣得多样机阶段测不出来的问题量产阶段一定会暴露。2. 从样机到小批量那些让你半夜爬起来改代码的驱动问题2.1 NAND Flash的坏块管理别等到量产才发现数据丢失我们的产品需要本地存储数据选的是256MB的SLC NAND Flash。样机阶段读写都正常但到了小批量的时候有几台机器出现了数据丢失的情况。排查后发现是坏块管理的问题。NAND Flash出厂时就有坏块使用过程中也会产生新的坏块。Linux内核的MTD子系统有坏块管理机制但需要正确配置。我们当时用的是UBI文件系统理论上支持坏块管理和磨损均衡但参数配置有问题。UBI的预留块比例设置得太低只有2%而实际使用中坏块率可能达到3%到5%。当坏块数量超过预留块时UBI就会报错导致数据写入失败。调整参数后问题解决了但这件事给我提了个醒存储方案的设计不能只看容量还要考虑寿命和可靠性。我们后来把预留块比例调到了8%同时增加了数据校验和重传机制。虽然可用容量减少了但数据可靠性有了保障。对于工业设备来说数据丢失的代价远大于存储成本。2.2 看门狗喂狗策略不是所有超时都是坏事看门狗是我们调试过程中最纠结的一个模块。硬件看门狗用的是芯片内置的WDT超时时间设置为10秒。应用层有一个线程专门负责喂狗正常情况下每2秒喂一次。但问题在于有些任务执行时间会超过10秒比如固件升级、大数据量存储、网络重连等。如果这些任务执行期间看门狗超时系统就会复位。我们试过几种方案。第一种是把看门狗超时时间延长到30秒但这样失去了看门狗的意义系统死机后要30秒才能复位。第二种是在长任务执行前先喂狗然后关闭看门狗任务完成后再打开。这个方案的问题是如果任务执行过程中系统真的死机了看门狗被关闭系统就永远不会复位。最终我们采用的方案是分层看门狗。硬件看门狗超时时间设为30秒应用层有一个监控线程每5秒检查一次各个任务的状态。如果某个任务超过预期时间没有更新状态监控线程会主动触发系统复位。这样既保证了长任务能正常执行又能在系统异常时及时复位。这个方案需要应用层和驱动层配合实现起来稍微复杂一些但可靠性最高。2.3 文件系统掉电保护一次意外断电导致的批量返修小批量试产阶段我们遇到了一个非常棘手的问题。现场有几台机器在意外断电后无法启动返修拆机后发现文件系统损坏UBI卷无法挂载。这个问题出现了三次每次都是断电后发生的。分析后发现我们的文件系统在写入数据时没有做掉电保护。Linux的UBI文件系统虽然有日志机制但在写入过程中断电仍然可能导致元数据损坏。解决方案是启用UBIFS的同步写入模式同时在应用层增加数据缓存机制减少频繁的小数据写入。具体来说我们把数据先写入内存缓冲区积累到一定量后再批量写入Flash。同时在每次写入完成后调用sync函数确保数据真正落盘。这个方案增加了内存开销但掉电损坏的概率大幅降低。后来我们又增加了超级电容在检测到断电后提供足够的电力完成最后一次写入操作。这个设计增加了成本但对于工业设备来说数据完整性是底线。3. 从量产到被裁那些和技术无关却决定命运的事3.1 量产评审通过的那一刻其实危机已经埋下了项目量产评审通过的那天团队一起吃了顿饭大家都挺高兴的。良率96%产能爬坡顺利客户反馈也不错。但我现在回头看危机其实在那时候就已经埋下了。第一个问题是成本。我们的BOM成本比竞品高了将近15%主要贵在主控和电源方案上。当时选型的时候优先考虑了稳定性和开发效率没有充分考虑成本控制。量产阶段采购部门反复施压要求降本但硬件方案已经定型改动的代价很大。最后只能通过更换部分物料来压缩成本但效果有限。第二个问题是团队规模。项目从零到量产团队从最初的3个人扩展到了12个人包括硬件、嵌入式软件、测试、结构等。量产之后维护工作量大幅减少团队显得冗余。公司层面的逻辑很简单项目进入维护期不需要这么多人。第三个问题是技术栈的单一性。我们整个项目基于i.MX6ULL和Linux技术栈相对封闭。团队成员在项目期间积累的经验很大程度上局限于这个平台。当公司决定转向新的平台时原有团队的价值就大打折扣。3.2 被裁那天我才明白硬件工程师的护城河不是画板子被裁的消息来得很突然但事后想想其实有很多征兆。公司从半年前开始调整方向新项目全部转向了国产主控平台而我们这些做i.MX6ULL的老员工在新项目里能发挥的作用有限。新平台的BSP、驱动、工具链都需要重新学习公司更倾向于招新人或者内部转岗。我在复盘的时候问自己一个问题如果重新来一次我会怎么做答案不是“把技术做得更深”而是“把技术栈拓宽”。具体来说不要把自己绑定在某一颗主控或者某一个平台上。嵌入式Linux的底层逻辑是相通的设备树、驱动模型、内核子系统这些知识在哪个平台上都能用。但如果你只会用NXP的Yocto工程换到全志或者瑞芯微的平台可能连编译环境都搭不起来。另一个问题是硬件工程师不能只懂硬件。我后来发现那些在裁员中留下来的人要么是软硬兼通的要么是能带团队的要么是能直接对接客户的。纯粹画板子、调电路的工程师在项目进入维护期后价值确实会下降。这不是说硬件不重要而是说硬件的价值需要在更大的上下文里体现。3.3 劳动仲裁这件事该争取的权益不要放弃被裁之后公司给的赔偿方案是N1但计算基数只算了基本工资没有算绩效和奖金。我咨询了做劳动仲裁的朋友他说这个计算方式是不合规的。根据相关规定经济补偿的月工资基数应该是劳动者在劳动合同解除前十二个月的平均工资包括计时工资、计件工资、奖金、津贴和补贴等货币性收入。我最终走了仲裁流程过程比想象中简单。提交材料、开庭、调解前后大概两个月最终拿到了应得的赔偿。我想说的是很多工程师在被裁的时候会觉得“算了不想折腾”但该争取的权益还是要争取。这不是钱的问题而是对自己劳动价值的尊重。4. 给还在路上的嵌入式硬件工程师几条用教训换来的建议4.1 技术层面建立自己的“最小可复用单元”我在项目期间最大的收获不是学会了某一颗芯片的用法而是建立了一套自己的“最小可复用单元”。具体来说就是把常用的电路模块标准化比如电源树、RS485接口、以太网接口、USB接口、调试接口等。每个模块都有经过验证的原理图和PCB布局新项目直接复用只需要根据具体需求调整参数。这套方法的好处是显而易见的。首先减少了重复劳动新项目启动速度大幅提升。其次经过多个项目验证的模块可靠性有保障。最后模块化的设计让排查问题变得更容易出了问题可以快速定位到具体模块。我建议每个硬件工程师都建立自己的模块库不用很复杂哪怕只是几个常用的接口电路积累下来就是一笔财富。这些模块不仅包括原理图还包括布局要点、注意事项、常见问题。比如RS485接口我会记录TVS管的选型依据、共模电感的参数、终端电阻的配置方式、以及在不同波特率下的注意事项。4.2 流程层面把每一次改版的原因记录下来我们项目从原理图第一版到量产文件一共改了七版。每一版改动的原因、影响范围、验证结果我都记录在一个Excel表格里。这个习惯在后期帮了大忙。比如有一次客户反馈某个功能异常我翻看记录发现这个问题在第三版的时候出现过当时的解决方案是调整了某个电阻的值。直接复用当时的方案问题很快就解决了。记录改版原因还有一个好处就是方便交接。项目后期有新同事加入我直接把表格发给他他就能快速了解整个项目的演进过程。这比口头讲解或者看原理图要高效得多。我建议记录的内容包括改版编号、改版日期、改动内容、改动原因、影响范围、验证结果、负责人。不用很复杂但要坚持记录。时间长了你会发现这是一笔非常宝贵的财富。4.3 职业层面不要把鸡蛋放在一个篮子里这句话听起来像废话但真正做起来并不容易。我在这个项目上投入了三年时间技术栈、人脉、甚至日常作息都和这个项目绑定在一起。当项目结束、团队解散的时候我才发现自己需要重新建立很多东西。我的建议是在做好本职工作的同时保持对行业动态的关注。不是说要随时准备跳槽而是要了解外面的世界在发生什么。比如国产主控的崛起、RISC-V的进展、边缘计算的需求变化这些趋势可能会影响你未来的职业选择。另外不要排斥软硬结合。嵌入式硬件工程师如果懂一些应用层开发、懂一些系统调试职业选择会宽很多。我在被裁之后面试了几家公司发现那些要求“软硬兼通”的岗位薪资普遍比纯硬件岗位高20%到30%。这不是说硬件不值钱而是说复合型人才更稀缺。4.4 心态层面被裁不是你的错但复盘是你的责任被裁这件事客观来说和我的技术能力关系不大更多是公司战略调整的结果。但我在复盘的时候还是找到了很多自己可以做得更好的地方。比如成本控制意识不够强、技术栈过于单一、对行业趋势不够敏感。这些问题不会因为换一家公司就自动消失如果不主动改变下一次可能还会遇到类似的情况。我想说的是被裁不是世界末日但也不能完全归咎于外部环境。把能控制的事情做好把不能控制的事情看淡这可能是每个职场人都需要修炼的心态。对于嵌入式硬件工程师来说技术更新速度快、项目周期长、量产压力大这些特点决定了我们需要不断学习、不断调整。保持学习的能力比掌握某一项具体技术更重要。最后分享一个我在仲裁期间学到的小知识劳动合同、工资流水、考勤记录、工作邮件这些材料平时就要有意识地保存。不是为了打官司而是为了在需要的时候能证明自己的价值。我当时因为平时有保存工作邮件的习惯仲裁时提交的证据非常充分整个过程顺利很多。这个习惯建议你也养成。
阅读完成 · 觉得有帮助？
