嵌入式 | 硬件转软件的几条建议-技术圈

关注、星标公众号，直达精彩内容

来源：网路素材

嵌入式系统设计不仅要求了解硬件，还要求了解软件的作用方式，以及如何与之交互。设计硬件需要的某种范式可能与设计软件完全相反。当从硬件设计转向包含软件的设计时，硬件工程师应牢记以下十个技巧。

建议1：流程图第一，实现第二

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

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

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

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

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

在函数式编程的年代，函数要先于形式，程序员的唯一目标是尽可能地让程序按预期方式快速运行，而不用考虑程序结构或可重用性。这种编程范式会毫无顾虑地使用全局性变量，程序中的任何函数都可能修改它。

其结果就造成了变量被破坏的几率增加或变量被误用。在新推荐的面向对象范式中，应在最小的范围内定义变量并封装它们，以防止其他函数的误用或破坏。因此，建议您限制全局范围使用的变量数量。可在C语言中用外部关键字标识这些变量。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧

关注我的微信公众号，回复“加群”按规则加入技术交流群。


点击“阅读原文”查看更多分享，欢迎点分享、收藏、点赞、在看。