谁告诉过你，在嵌入式项目中软件更改成本低于硬件？

公司的硬件工程师背着我改了系统的原理图。改了我的设计，当我发现时，质问其为什么修改我的原理图时，说：“因为走线不好走，所以就修改了I/O口。”

 “你知道吗，这会让我修改软件。”
 
“据说，软件的更改成本比硬件低。”
 
当时，我就明白了，这位工程师缺乏系统的思维，并且还有些想当然，我问了如下的问题：
 
“你依据什么说软件更改成本比硬件低？你熟悉软件开发的流程？你熟悉那几个I/O口究竟是做什么用得吗？其软件内部是怎么实现的？你新更换的I/O口可以实现相同的功能吗？”
 
这位硬件工程师不作答了，陷入一片茫然……
 
很多时候，我们缺乏的不是做好事情的知识，而是做好事情的方法。就如同这个硬件工程师一样，没有好的工作方法。在没有搞清楚状况下，就做了结论。是草率而又不负责任的。我们来分析分析这个原因：

1、嵌入式最大的挑战是：硬件和软件同时成熟，出问题时，不知是软件或是硬件问题，两个方面相互影响，致使开发成本大幅度上升。假设这更改的I/O能替代原来的I/O口，也会致使软件修改，修改后一样要做大量的测试，这些都会致使成本大幅度的上升；一般来说，嵌入式项目的开发难度和PC机的开发难度不能一概而论，说谁一定比谁一定难。两种项目难度各有特点，单从调试方面说，嵌入式难度稍大些，其调试手段较 PC机手段少，且有些不稳定，并不能很好的追踪Bug。并且，嵌入式要求软件开发人员了解的过程更加具体，如：AD、DA的工作方式及通讯的时序，这个是PC人员不需要掌握的知识。AD、DA时序的稳定性对AD、DA的数据采集或多或少的都会有些影响。
 
2、原来的I/O口真的能随随便便的被替代吗？一般来讲， MCU的I/O口，都有附属功能，在没有充分理解I/O功能的原理上，实际上是很难判定能不能替代的。比如说，如果这个I/O口做输入，需要中断。中断是电平出发还是边沿触发呢？并不是所有的I/O都支持中断的，并不是所有的I/O都可以边沿、电平触发中断的。这个要从Datasheet中获得；从软件的角度来看，就算可以替代，也要评估一下，更改了这个I/O口，会不会造成软件的模块化封装的难度？一般来说，端口A有8个I/O口，端口B也有8个I/O口，这8个I/O口共用一个中断服务程序，进入中断程序后需要判断到底是哪个I/O口触发了中断。然后再调用中断相关的服务程序。实际上，一个端口多个I/O口中断的编程有很多抽象的办法，但没有一个是比较简单的，代码也较端口中只有一个I/O口的代码复杂。复杂也就意味着有Bug的可能性……同时，这给调试也带来了很多不便。
 
3、关于版本管理和版本兼容的问题。更改了软件，也就意味着更改新的版本，如果有老设备发送到客户那里，也就意味着要升级；如果每版的硬件都有新的特性，那么无疑是版本管理的噩梦！有朋友说可以做兼容，兼容是可以。举个例子，Intel 做的x86架构的CPU为什么在嵌入式领域干不过ARM呢？当然这里有很多因素，其中一个重要的因素就是x86选择了兼容，而ARM没有选择。所以ARM更加的简洁灵巧，或者说突出的特点是低功耗。而Intel的x86为了兼容，很多情况下不能选择最优设计，因为要照顾很多东西，就变成了大而全，很难兼顾的。结果成了低功耗的噩梦，一个i3全速跑起来也是好几十W啊！这和ARM Cortex-A8是不同的概念。做版本兼容是无奈的选择，成本会大幅的上升，维修、更新、测试、交付等等，问题相当的多，不光光是软件成本高，是公司各个部门的成本都会变高。再回头看看，版本管理也是一个巨复杂的工作，如果更改了一个公共的Bug，那需要在所有的硬件上做测试，想想，一两个还不算什么？10个20个硬件版本，这个事情还怎么弄？特别对于资源比较紧张的小公司。如果要市场部门通知客户完成软件的升级，那么这是多大的工作量？一旦出错，损失的是客户的信任，不是一点点成本所能衡量的!所以，好钢要用在刀刃上!
 
一个数字信号，多打几个过孔，可能看起来不是那么美观，但美观不是电路的第一要求，电路的第一要求是信号完整性! 所以，仅为走线不好看，更改I/O口，没有意识到这更改带来的问题，典型的缺乏系统化的思维。不过话又说回来，都吃五谷杂粮，谁又能保证什么事情都能跳出三界之外，识清庐山真面目呢？掌握好的做事情的方法，不要想当然，在深刻的理解的基础上，谨慎的作出决定，是非常必要的。
 
修道之人，都有一个过程，那就是否定之否定的过程，刚开始，看山是山，看水是水；经过一段时间的学习修炼，看山不是山，看水不是水；最后修炼到一定的境界，看山还是山，看水还是水。这其中包含着对事物理解的逐层渗透，认识逐渐升华的过程，其中的复杂需要自己多用身边的事例多多体会。