硬件转软件，要慎重！

2、使用状态机控制程序流程

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

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

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

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

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

它会造成不必要的常量频繁使用，特别当这个常量没有用宏定义“正名”时，代码阅读起来将万分吃力。
它会导致软件分层的不合理，全局变量相当于一条快捷通道，它容易使程序员模糊了“设备层”和“应用层”之间的边界。写出来的底层程序容易自作多情地关注起上层的应用。这在软件系统的构建初期的确效率很高，功能调试进度一日千里，但到了后期往往bug一堆，处处“补丁”，雷区遍布。说是度日如年举步维艰也不为过。
由于软件的分层不合理，到了后期维护，哪怕仅是增加修改删除小功能，往往要从上到下掘地三尺地修改，涉及大多数模块，而原有的代码注释却忘了更新修改，这个时候，交给后来维护者的系统会越来越像一个“泥潭”，注释的唯一作用只是使泥潭上方再加一些迷烟瘴气。
全局变量大量使用，少不了有些变量流连忘返于中断与主回圈程序之间。这个时候如果处理不当，系统的bug就是随机出现的，无规律的，这时候初步显示出病入膏肓的特征来了，没有大牛来力挽狂澜，注定慢性死亡。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91338 人正在系统学习中

来源：嵌入式资讯精选

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！