嵌入式 | 硬件转软件的几条建议

建议1：先制作流程图，后进行代码实现

设计嵌入式系统不仅需要了解硬件，还需要了解软件的工作方式，以及与其交互的方式。在设计硬件时，可能需要采用一种与设计软件完全相反的范式。因此，当由硬件设计转向具有软件设计时，硬件工程师应该谨记以下十个技巧：

在首次进入软件开发领域时，会有一种强烈的诱惑使工程师立即进入编码阶段。然而，这种单一的思维方式有点像在PCB设计之前尝试设计电路逻辑图一样，非常不可取。在开始进行软件开发之前，应首先使用流程图来制定软件架构。

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

建议2：使用状态机控制程序流程

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

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

建议3：避免使用全局变量

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

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

建议4：利用模块性的好处

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

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

建议5：保持中断服务例程的简单性

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

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

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

建议6：使用处理器示例代码做外设的实验

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

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

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

建议7：限制功能复杂度

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

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

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

建议8：使用源代码存储库

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

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

建议9：代码做详细说明

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

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

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！