硬件转软件，请慎重

直接来源 | 果果小师弟

嵌入式系统设计不仅要求了解硬件，还要求了解软件的作用方式，以及如何与之交互。设计硬件需要的某种范式可能与设计软件完全相反。

当从硬件设计转向包含软件的设计时，软硬件工程师应牢记以下十个技巧。

当工程师首次迈入软件开发领域时，会有种强烈的诱惑力促使他们立刻投入工作并开始写代码。

这样的定式思维就等同于在电路逻辑图还未完成前就试图设计印刷电路板（PCB）。在着手开发软件时，抑制想写代码的冲动是至关重要的，应首先用流程图制定一个软件架构图。

这样的方法会使开发人员对应用所需的不同部分与组件形成一个概念，就像电路逻辑图可以告诉工程师需要哪些硬件元件一样。这样可确保程序整体建立在良好的组织和深思熟虑之上，减少程序调试时间，从长期看，这样做还可以节省时间、省去麻烦。

状态机是20世纪最伟大的软件发明之一。某应用程序往往可被分为多个状态机，每个状态机都控制该应用程序的特定部件。这些状态机都拥有自己的内部状态和状态转换，从中可看出软件如何与各种激励相互作用。

用状态机来设计软件，可简化软件的开发，使之模块化、可维护，并易于理解。目前拥有的广泛资源可演示状态机的理论和算法。

嵌入式特别是单片机os-less的程序，最易范的错误是全局变量满天飞。这个现象在早期汇编转型过来的程序员以及初学者中常见，这帮家伙几乎把全局变量当作函数形参来用。

在.h文档里面定义许多杂乱的结构体，extern一堆令人头皮发麻的全局变量，然后再这个模块里边赋值123，那个模块里边判断123分支决定做什么。

不否认全局变量的重要性，但要十分谨慎地使用它，滥用全局变量会引申带来其它更为严重的结构性系统问题。

1. 它会造成不必要的常量频繁使用，特别当这个常量没有用宏定义“正名”时，代码阅读起来将万分吃力。

2. 它会导致软件分层的不合理，全局变量相当于一条快捷通道，它容易使程序员模糊了“设备层”和“应用层”之间的边界。写出来的底层程序容易自作多情地关注起上层的应用。这在软件系统的构建初期的确效率很高，功能调试进度一日千里，但到了后期往往bug一堆，处处“补丁”，雷区遍布。说是度日如年举步维艰也不为过。

3. 由于软件的分层不合理，到了后期维护，哪怕仅是增加修改删除小功能，往往要从上到下掘地三尺地修改，涉及大多数模块，而原有的代码注释却忘了更新修改，这个时候，交给后来维护者的系统会越来越像一个“泥潭”，注释的唯一作用只是使泥潭上方再加一些迷烟瘴气。

4. 全局变量大量使用，少不了有些变量流连忘返于中断与主回圈程序之间。这个时候如果处理不当，系统的bug就是随机出现的，无规律的，这时候初步显示出病入膏肓的特征来了，没有大牛来力挽狂澜，注定慢性死亡。

两个原则对策

1. 能不用全局变量尽量不用，除了系统状态和控制参数、通信处理和一些需要效率的模块，其他的基本可以靠合理的软件分层和编程技巧来解决。

2. 如果不可避免需要用到，那能藏多深就藏多深。

1)如果只有某.c文件用，就static到该文件中，顺便把结构体定义也收进来；

2)如果只有一个函数用，那就static到函数里面去；

3)如果非要开放出去让人读取，那就用函数return出去，这样就是只读属性了；

4)如果非要赋值，开放函数接口传参赋值；

5)实在非要extern强J我，还可以严格控制包含.h档的对象，而不是放到公共的includes.h中被人围观，丢人现眼。

注意：避免使用，不是不让使用！

无论问哪一名工程师，项目的哪部分最有可能延迟交付并超出预算？答案都是软件。软件往往是复杂的，且难以开发和维护，尤其是当整个应用都存在于单一文件或松散关联的多个文件中时。为了缓解可维护性、可重用性及复杂性，强烈建议程序员充分利用现代编程语言的模块化特性，将常用功能分解成模块。

以这样的方式分解编码，程序员就能着手建立函数与特性库，然后在一个接一个的应用中重用它们，从而通过连续测试而改善代码质量，同时也减少了时间，降低了开发成本。

中断服务例程用来中断处理器对当前代码分支的执行，从而处理刚刚触发中断的外围设备。无论何时执行中断，都需要一定数量的开销，用于保存当前程序的状态、运行中断，然后将处理器回归原程序状态。

现代处理器要比多年前的处理器快得多，但仍需要考虑此花销。一般情况下，程序员都想把中断运行时间降至最低，以避免干扰主代码分支。这意味着中断应该短而简单。

中断中不应调用函数。此外，如果中断开始变得过于复杂或耗时，则仅应在必要时利用中断做最少量的工作，例如，将数据装入缓冲区并设置一个标志，然后让主分支处理输入的数据。这样做可保证大多数处理器周期被用于运行应用，而不是处理中断。

设计硬件时，做原型测试电路总是有益的，这样可确保工程师对电路有正确的理解，然后再做电路板布局。此点对设计软件也同样适用。硅片制造商通常都有示例代码，可用来测试微处理器的各个部分，这样工程师们就可判定该部分的工作情况。

此方法使人们洞察到软件体系架构的应该组织方式，以及可能造成的任何潜在问题。在设计初期阶段认清潜在的障碍，比在产品交付前最后几小时才发现它们要好。

这是预先测试代码片段的一个很好的方法，但需提醒的是，制造商代码往往不是模块化的，未经大的修改不方便用于实际应用。这一局限已随着时间的发展而改变，也许某一天芯片供应商会给出可用于生产的代码。

工程学中有一个旧词叫“KISS”——保持简单和直接。无论在处理何种复杂工作时，最简单的方法就是把它分解为更小、更简单、更易处理的任务。随着工作或功能变得越来越复杂，人们要准确无误地记录所有的细节也变得更困难。

在写一个函数时，其复杂度在当时看似适中，然而要考虑到，一名工程师如何在六个月的维护时间内查看代码。测量函数复杂度（如循环的复杂度）的方法很多。现在有工具可以自动计算某个函数的循环复杂度。经验法则建议，函数的循环复杂度保持在10以下是最理想的。

无论在处理何种复杂工作时，最简单的方法就是把它分解为更易处理的任务。

人都是会犯错误的，写代码时也会犯错。这就是为什么开发人员使用源代码存储库是如此重要。源代码存储库可使开发人员“登记”一个好的代码版本，并描述对该代码所做的修改。该步骤不仅使得开发人员可以复原或追溯到代码的旧版本，还可以比较旧版本之间的不同。

如果开发人员做的一系列改变破坏了系统，只需点击一下即可恢复好的代码版本！请谨记，如果不频繁提交代码，存储库就不会达到预期目的。如果做了不可逆的修改，两周后才提交代码，然后再恢复，就会造成大量工作和时间的损失！

在软件开发的激烈战斗中，开发人员很容易把注意力集中在编写和代码上，因此会忽略详细解释的需求。在压力之下，说明工作往往是项目的收尾工作，因为开发人员认为它是最后的一项工作。

然而，当代码仍在你脑中新鲜热火时就做出详细解释是至关重要的，这样做可使开发人员或你自己读懂注释，理解代码的工作方式。如果开发人员做的一系列改变破坏了系统，只需点击一下即可恢复好的代码版本！

当项目小组做一个相对较复杂的工程时，意味着你不再独自单干。而是和小组成员分工合作，这就要求小组成员各自负责一部分工程。比如你可能只是负责通讯或者显示这一块。

这个时候，你就应该将自己的这一块程序写成一个模块，单独调试，留出接口供其它模块调用。最后，小组成员都将自己负责的模块写完并调试无误后，由项目组长进行组合调试。

像这些场合就要求程序必须模块化。模块化的好处是很多的，不仅仅是便于分工，它还有助于程序的调试，有利于程序结构的划分，还能增加程序的可读性和可移植性。

记住以下四点就可以了：

1. 模块即是一个.c 文件和一个.h 文件的结合，头文件(.h)中是对于该模块接口的声明；
2. 某模块提供给其它模块调用的外部函数及数据需在.h 中文件中冠以extern 关键字声明；
3. 模块内的函数和全局变量需在.c 文件开头冠以static 关键字声明；
4. 永远不要在.h 文件中定义变量！