25/51X=196

来源：蜘蛛抓取(WebSpider) 时间：2018-08-29 05:27 标签： X.25
    如果一个关键变量需要多处备份，可以按照下面方式定义变量，将三个变量分别指定到三个不连续的RAM区中，并在定义时按照原码、反码、0xAA的异或码进行初始化。

          当需要写这个变量时，这三个位置都要更新；读取变量时，读取三个值做判断，取至少有两个相同的那个值。

          为什么选取异或码而不是补码？这是因为MDK的整数是按照补码存储的，正数的补码与原码相同，在这种情况下，原码和补码是一致的，不但起不到冗余作用，反而对可靠性有害。比如存储的一个非零整数区因为干扰，RAM都被清零，由于原码和补码一致，按照3取2的“表决法”，会将干扰值0当做正确的数据。

    4.8对非易失性存储器进行备份存储

    非易失性存储器包括但不限于Flash、EEPROM、铁电。仅仅将写入非易失性存储器中的数据再读出校验是不够的。强干扰情况下可能导致非易失性存储器内的数据错误，在写非易失性存储器的期间系统掉电将导致数据丢失，中，将导致数据存储紊乱。一种可靠的办法是将非易失性存储器分成多个区，每个数据都将按照不同的形式写入到这些分区中，需要进行读取时，同时读出多份数据并进行表决，取相同数目较多的那个值。

    对于初始化序列或者有一定先后顺序的函数调用，为了保证调用顺序或者确保每个函数都被调用，我们可以使用环环相扣，实质上这也是一种软件锁。此外对于一些安全关键代码语句（是语句，而不是函数），可以给它们设置软件锁，只有持有特定钥匙的，才可以访问这些关键代码。也可以通俗的理解为，关键安全代码不能按照单一条件执行，要额外的多设置一个标志。

    比如，向Flash写一个数据，我们会判断数据是否合法、写入的地址是否合法，计算要写入的扇区。之后调用写Flash子程序，在这个子程序中，判断扇区地址是否合法、数据长度是否合法，之后就要将数据写入Flash。由于写Flash语句是安全关键代码，所以程序给这些语句上锁：必须具有正确的钥匙才可以写Flash。这样即使是程序跑飞到写Flash子程序，也能大大降低误写的风险。

    该程序段是编程lpc1778内部Flash，其中调用IAP程序的函数iap_entry(paramin, paramout)是关键安全代码，所以在执行该代码前，先判断一个特定设置的安全锁标志ProgStart，只有这个标志符合设定值，才会执行编程Flash操作。如果因为意外程序跑飞到该函数，由于ProgStart标志不正确，是不会对Flash进行编程的。

          通讯线上的数据误码相对严重，通讯线越长，所处的环境越恶劣，误码会越严重。抛开硬件和环境的作用，我们的软件应能识别错误的通讯数据。对此有一些应用措施：

    •  制定协议时，限制每帧的字节数；

     每帧字节数越多，发生误码的可能性就越大，无效的数据也会越多。对此以太网规定每帧数据不大于1500字节，高可靠性的CAN收发器规定每帧数据不得多于8字节，对于RS485，基于RS485链路应用最广泛的Modbus协议一帧数据规定不超过256字节。因此，建议制定内部通讯协议时，使用RS485时规定每帧数据不超过256字节；

               1)增加缓冲区溢出判断。这是因为数据接收多是在中断中完成，编译器检测不出缓冲区是否溢出，需要手动检查，在上文介绍数据溢出一节中已经详细说明。

     2)增加超时判断。当一帧数据接收到一半，长时间接收不到剩余数据，则认为这帧数据无效，重新开始接收。可选，跟不同的协议有关，但缓冲区溢出判断必须实现。这是因为对于需要帧头判断的协议，上位机可能发送完帧头后突然断电，重启后上位机是从新的帧开始发送的，但是下位机已经接收到了上次未发送完的帧头，所以上位机的这次帧头会被下位机当成正常数据接收。这有可能造成数据长度字段为一个很大的值，填满该长度的缓冲区需要相当多的数据（比如一帧可能1000字节），影响响应时间；另一方面，如果程序没有缓冲区溢出判断，那么缓冲区很可能溢出，后果是灾难性的。

    4.11开关量输入的检测、确认

          开关量容易受到尖脉冲干扰，如果不进行滤除，可能会造成误动作。一般情况下，需要对开关量输入信号进行多次采样，并进行逻辑判断直到确认信号无误为止。

          开关信号简单的一次输出是不安全的，干扰信号可能会翻转开关量输出的状态。采取重复刷新输出可以有效防止电平的翻转。

    4.13初始化信息的保存和恢复

          微处理器的寄存器值也可能会因外界干扰而改变，外设初始化值需要在寄存器中长期保存，最容易被破坏。由于Flash中的数据相对不易被破坏，可以将初始化信息预先写入Flash，待程序空闲时比较与初始化相关的寄存器值是否被更改，如果发现非法更改则使用Flash中的值进行恢复。

    公司目前使用的4.3寸LCD显示屏抗干扰能力一般。如果显示屏与控制器之间的排线距离过长或者对使用该显示屏的设备打静电或者脉冲群，显示屏有可能会花屏或者白屏。对此，我们可以将初始化显示屏的数据保存在Flash中，程序运行后，每隔一段时间从显示屏的寄存器读出当前值和Flash存储的值相比较，如果发现两者不同，则重新初始化显示屏。下面给出校验源码，仅供参考。

        定义const修饰的结构体变量，存储LCD部分寄存器的初始值，这个初始值跟具体的应用初始化有关，不一定是表中的数据，通常情况下，这个结构体变量被存储到Flash中。 

    1. /LCD部分寄存器设置值列表/ 
 
     
    
 实现函数如下所示，函数会遍历结构体变量中的每一个命令，以及每一个命令下的初始值，如果有一个不正确，则跳出循环，执行重新初始化和恢复措施。这个函数中的MY_DEBUGF宏是我自己的调试函数，使用串口打印调试信息，在接下来的第五部分将详细叙述。通过这个函数，我可以长时间监控显示屏的哪些命令、哪些位容易被干扰。程序里使用了一个被妖魔化的关键字：goto。大多数C语言书籍对goto关键字谈之色变，但你应该有自己的判断。在函数内部跳出多重循环，除了goto关键字，又有哪种方法能如此简洁高效！
 
 
    3. * 每隔一段时间调用该程序一次 
 
     

     
    
       对于8051内核单片机，由于没有相应的硬件支持，可以用纯软件设置软件陷阱，用来拦截一些程序跑飞。对于ARM7或者Cortex-M系列单片机，硬件已经内建了多种异常，软件需要根据硬件异常来编写陷阱程序，用来快速定位甚至恢复错误。
 
 

     
    
       有时候程序员会使用while(!flag);语句阻塞在此等待标志flag改变，比如串口发送时用来等待一字节数据发送完成。这样的代码时存在风险的，如果因为某些原因标志位一直不改变则会造成系统死机。
 
 
    
       一个良好冗余的程序是设置一个超时定时器，超过一定时间后，强制程序退出while循环。
 
 
    
     2003年8月11日发生的W32.Blaster.Worm蠕虫事件导致全球经济损失高达5亿美元，这个漏洞是利用了Windows分布式组件对象模型的远程过程调用接口中的一个逻辑缺陷：在调用GetMachineName()函数时，循环只设置了一个不充分的结束条件。
 
 
    
 
 
     
     
    
     微软发布的安全补丁MS03-026解决了这个问题，为GetMachineName()函数设置了充分终止条件。一个解决代码简化如下所示（并非微软补丁代码）：
 
 
     
     
    
        思维再缜密的程序员也不可能编写完全无缺陷的程序，测试的目的正是尽可能多的发现这些缺陷并改正。这里说的测试，是指程序员的自测试。前期的自测试能够更早的发现错误，相应的修复成本也会很低，如果你不彻底测试自己的代码，恐怕你开发的就不只是代码，可能还会声名狼藉。
 
 
    
 优质嵌入式C程序跟优质的基础元素关系密切，可以将函数作为基础元素，我们的测试正是从最基本的函数开始。判断哪些函数需要测试需要一定的经验积累，虽然代码行数跟逻辑复杂度并不成正比，但如果你不能判断某个函数是否要测试，一个简单粗暴的方法是：当函数有效代码超过20行，就测试它。
 
 
    
 程序员对自己的代码以及逻辑关系十分清楚，测试时，按照每一个逻辑分支全面测试。很多错误发生在我们认为不会出错的地方，所以即便某个逻辑分支很简单，也建议测试一遍。第一个原因是我们自己看自己的代码总是不容易发现错误，而测试能暴露这些错误；另一方面，语法正确、逻辑正确的代码，经过编译器编译后，生成的汇编代码很可能与你的逻辑相差甚远。比如我们前文提及的使用volatile以及不使用volatile关键字编译后生成的汇编代码，再比如我们用低优化级别编译和使用高优化级别编译后生成的汇编代码，都可能相差很大，实际运行测试，可以暴漏这些隐含错误。最后，虽然可能性极小，编译器本身也可能有BUG，特别是构造复杂表达式的情况下（应极力避免复杂表达式）。

    5.1使用硬件调试器测试 

     
 
    
        使用硬件调试器（比如J-link）测试是最通用的手段。可以单步运行、设置断点，可以很方便的查看当前寄存器、变量的值。在寻找缺陷方面，使用硬件调试器测试是最简单却又最有效的手段。
 
 
    
        硬件调试器已经在公司普遍使用，这方面的测试不做介绍，想必大家都已经很熟悉了。
 
 

     
    
        就像没有一种方法能完美解决所有问题，在实际项目中，硬件调试器也有难以触及的地方。可以举几个例子说明：
    •  使用了比较大的协议栈，需要跟进到协议栈内部调试的缺陷 
     
    
            比如公司使用lwIP协议栈，如果跟踪数据的处理过程，需要从接收数据开始一直到应用层处理数据，之间会经过驱动层、IP层、TCP层和应用层，会经过十几个文件几十个函数，使用硬件调试器跟踪费时费力；
    •  具有随机性的缺陷 
     
    
           有一些缺陷，可能是不定时出现的，有可能是几分钟出现，也有可能是几个小时甚至几天才出现，像这样的缺陷很难用硬件调试器捕捉到；
    •  需要外界一系列有时间限制的输入条件触发，但这一过程中有缺陷 
     
    
       比如我们用组合键来完成某个功能，规定按下按键1不小于3秒后松开，然后在6秒内分别按下按键2、按键3、按键4这三个按键来执行我们的特定程序，要测试类似这种过程，硬件调试器很难做到；
 
 
    
       除了测试缺陷需要，有时候我们在做稳定性测试时，需要知道软件每时每刻运行到那些分支、执行了哪些操作、我们关心的变量当前值是什么等等，这些都表明，我们还需要一种和硬件调试器互补的测试手段。
 
 
    
       这个测试手段就是在程序中增加额外调试语句，当程序运行时，通过这些调试语句将运行信息输出到可以方便查看的设备上，可以是PC机、LCD显示屏、存储卡等等。
 
 
    
       以串口输出到PC机为例，下面提供完整的测试思路。在此之前，我们先对这种测试手段提一些要求：
 
 
     
    
            我们在初学C语言的时候，都接触过printf函数，这个函数可以方便的输出信息，并可以将各种变量格式化为指定格式的字符串，我们应当提供类似的函数；
    •  调试语句必须方便的从代码中移除 
     
    
           在编码阶段，我们可能会往程序中加入大量的调试语句，但是程序发布时，需要将这些调试语句从代码中移除，这将是件恐怖的过程。我们必须提供一种策略，可以方便的移除这些调试语句。

    5.2.1简单易用的调试函数 

     
 
    
 
 
    
 
 
    
 
 
    9. /这里是一个跟硬件相关函数,将一个字符写到UART / 
 
     
    
 MicroLIB前的复选框以便避免使用半主机功能。（注：标准C库printf函数默认开启半主机功能，如果非要使用标准C库，请自行查阅资料）
 
 
    
 
 
    
       使用库函数比较方便，但也少了一些灵活性，不利于随心所欲的定制输出格式。自己编写类似printf函数则会更灵活一些，而且不依赖任何编译器。下面给出一个完整的类printf函数实现，该函数支持有限的格式参数，使用方法与库函数一致。同库函数类似，该也需要提供一个底层串口发送函数（原型为：int32_t UARTwrite(const

    5.2.2对调试函数进一步封装 

     
 
    
       上文说到，我们增加的调试语句应能很方便的从最终发行版中去掉，因此我们不能直接调用printf或者自定义的UARTprintf函数，需要将这些调试函数做一层封装，以便随时从代码中去除这些调试语句。参考方法如下：
 
 
     
     
    
 在我们编码测试期间，定义宏MY_DEBUG，并使用宏MY_DEBUGF（注意比前面那个宏多了一个‘F’）输出调试信息。经过预处理后，宏MY_DEBUGF(message)会被UARTprintf
 message代替，从而实现了调试信息的输出；当正式发布时，只需要将宏MY_DEBUG注释掉，经过预处理后，所有MY_DEBUGF(message)语句都会被空格代替，而从将调试信息从代码中去除掉。
 
 

     
    
        《计算机程序结构与说明》一书在开篇写到：程序写出来是给人看的，附带能在机器上运行。
 
 

     
    
 使用什么样的编码样式一直都颇具争议性的，比如缩进和大括号的位置。因为编码的样式也会影响程序的可读性，面对一个乱放括号、对齐都不一致的源码，我们很难提起阅读它的兴趣。我们总要看别人的程序，如果彼此编码样式相近，读起源码来会觉得比较舒适。但是编码风格的问题是主观的，永远不可能在编码风格上达成统一意见。因此只要你的编码样式整洁、结构清晰就足够了。除此之外，对编码样式再没有其它要求。
 
 
    
 Simonyi说：我觉得代码清单带给人的愉快同整洁的家差不多。你一眼就能分辨出家里是杂乱无章还是整洁如新。这也许意义不大。因为光是房子整洁说明不了什么，它仍可能藏污纳垢！但是第一印象很重要，它至少反映了程序的某些方面。我敢打赌，我在3米开外就能看出程序拙劣与否。我也许没法保证它很不错，但如果从3米外看起来就很糟，我敢保证这程序写得不用心。如果写得不用心，那它在逻辑上也许就不会优美。
 
 

     
    
 变量、函数、宏等等都需要命名，清晰的命名是优秀代码的特点之一。命名的要点之一是名称应能清晰的描述这个对象，以至于一个初级程序员也能不费力的读懂你的代码逻辑。我们写的代码主要给谁看是需要思考的：给自己、给编译器还是给别人看？我觉得代码最主要的是给别人看，其次是给自己看。如果没有一个清晰的命名，别人在维护你的程序时很难在整个全貌上看清代码，因为要记住十多个以上的糟糕命名的变量是件非常困难的事；而且一段时间之后你回过头来看自己的代码，很有可能不记得那些糟糕命名的变量是什么意思。
 
 
    
 为对象起一个清晰的名字并不是简单的事情。首先能认识到名称的重要性需要有一个过程，这也许跟谭式C程序教材被大学广泛使用有关：满书的a、b、c、x、y、z变量名是很难在关键的初学阶段给人传达优秀编程思想的；其次如何恰当的为对象命名也很有挑战性，要准确、无歧义、不罗嗦，要对英文有一定水平，所有这些都要满足时，就会变得很困难；此外，命名还需要考虑整体一致性，在同一个项目中要有统一的风格，坚持这种风格也并不容易。
 
 
    
        关于如何命名，Charles Simonyi说：面对一个具备某些属性的结构，不要随随便便地取个名字，然后让所有人去琢磨名字和属性之间有什么关联，你应该把属性本身，用作结构的名字。
 
 

     
    
 注释向来也是争议之一，不加注释和过多的注释我都是反对的。不加注释的代码显然是很糟糕的，但过多的注释也会妨碍程序的可读性，由于注释可能存在的歧义，有可能会误解程序真实意图，此外，过多的注释会增加程序员不必要的时间。如果你的编码样式整洁、命名又很清晰，那么，你的代码可读性不会差到哪去，而注释的本意就是为了便于理解程序。
 
 
    
 这里建议使用良好的编码样式和清晰的命名来减少注释，对模块、函数、变量、数据结构、算法和关键代码做注释，应重视注释的质量而不是数量。如果你需要一大段注释才能说清楚程序做什么，那么你应该注意了：是否是因为程序变量命名不够清晰，或者代码逻辑过于混乱，这个时候你应该考虑的可能就不是注释，而是如何精简这个程序了。
 
 

     
    
       数据结构是程序设计的基础。在设计程序之前，应该先考虑好所需要的数据结构。
 
 
    
 Simonyi：编程的第一步是想象。就是要在脑海中对来龙去脉有极为清晰的把握。在这个初始阶段，我会使用纸和铅笔。我只是信手涂鸦，并不写代码。我也许会画些方框或箭头，但基本上只是涂鸦，因为真正的想法在我脑海里。我喜欢想象那些有待维护的结构，那些结构代表着我想编码的真实世界。一旦这个结构考虑得相当严谨和明确，我便开始写代码。我会坐到终端前，或者换在以前的话，就会拿张白纸，开始写代码。这相当容易。我只要把头脑中的想法变换成代码写下来，我知道结果应该是什么样的。大部分代码会水到渠成，不过我维护的那些数据结构才是关键。我会先想好数据结构，并在整个编码过程中将它们牢记于心。
 
 
    
     开发过以太网和操作系统SDS 940的Butler Lampson：（程序员）最重要的素质是能够把问题的解决方案组织成容易操控的结构。
 
 
    
     开发CP/M操作系统的Gary.A：如果不能确认数据结构是正确的，我是决不会开始编码的。我会先画数据结构，然后花很长时间思考数据结构。在确定数据结构之后我就开始写一些小段的代码，并不断地改善和监测。在编码过程中进行测试可以确保所做的修改是局部的，并且如果有什么问题的话，能够马上发现。
 
 
    
     微软创始人比尔·盖茨：编写程序最重要的部分是设计数据结构。接下来重要的部分是分解各种代码块。
 
 
    
     编写世界上第一个电子表格软件的Dan Bricklin：在我看来，写程序最重要的部分是设计数据结构，此外，你还必须知道人机界面会是什么样的。
 
 
    
 我们举个例子来说明。在介绍防御性编程的时候，提到公司使用的LCD显示屏抗干扰能力一般，为了提高LCD的稳定性，需要定期读出LCD内部的关键寄存器值，然后跟存在Flash中的初始值相比较。需要读出的LCD寄存器有十多个，从每个寄存器读出的值也不尽相同，从1个到8个字节都有可能。如果不考虑数据结构，编写出的程序将会很冗长。
 
 
    3. 读第一个寄存器值; 
6. 读第二个寄存器值; 
11. 读第十个寄存器值; 
 
     
    
       我们分析这个过程，发现能提取出很多相同的元素，比如每次读LCD寄存器都需要该寄存器的命令号，都会经过读寄存器、判断值是否相同、处理异常情况这一过程。所以我们可以提取一些相同的元素，组织成数据结构，用统一的方法去处理这些数据，将数据与处理过程分开来。
       我们可以先提取相同的元素，将之组织成数据结构：
 
     
     
    
 这里lcd_command表示的是LCD寄存器命令号；lcd_get_value是一个数组，表示寄存器要初始化的值，这是因为对于一个LCD寄存器，可能要初始化多个字节，这是硬件特性决定的；lcd_value_num是指一个寄存器要多少个字节的初值，这是因为每一个寄存器的初值数目是不同的，我们用同一个方法处理数据时，是需要这个信息的。
 
 
    
       就本例而言，我们将要处理的数据都是事先固定的，所以定义好数据结构后，我们可以将这些数据组织成表格：
 
 
     
    1. /LCD部分寄存器设置值列表/ 
 
          至此，我们就可以用一个处理过程来完成数十个LCD寄存器的读取、判断和异常处理了：
 
    3. * 每隔一段时间调用该程序一次 
 
     
    
 通过合理的数据结构，我们可以将数据和处理过程分开，LCD冗余判断过程可以用很简洁的代码来实现。更重要的是，将数据和处理过程分开更有利于代码的维护。比如，通过实验发现，我们还需要增加一个LCD寄存器的值进行判断，这时候只需要将新增加的寄存器信息按照数据结构格式，放到LCD寄存器设置值列表中的任意位置即可，不用增加任何处理代码即可实现！这仅仅是数据结构的优势之一，使用数据结构还能简化编程，使复杂过程变的简单，这个只有实际编程后才会有更深的理解。
 
 
    
 本文介绍了编写优质嵌入式C程序涉及的多个方面。每年都有亿万计的C程序运行在单片机、ARM7、Cortex-M3这些微处理器上，但在这些处理器上如何编写优质高效的C程序，几乎没有书籍做专门介绍。本文试图在这方面做一些努力。编写优质嵌入式C程序需要大量的专业知识，本文虽尽力描述编写嵌入式C程序所需要的各种技能，但本文却无力将每一个方面都面面俱到的描述出来，所以本文最后会列举一些阅读书目，这些书大多都是真正大师的经验之谈。站在巨人的肩膀上，可以看的更远。
    •  陈正冲 编著 《C语言深度解剖》
    •  杜春雷 编著 《ARM体系结构与编程》
    如果一个关键变量需要多处备份，可以按照下面方式定义变量，将三个变量分别指定到三个不连续的RAM区中，并在定义时按照原码、反码、0xAA的异或码进行初始化。

          当需要写这个变量时，这三个位置都要更新；读取变量时，读取三个值做判断，取至少有两个相同的那个值。

          为什么选取异或码而不是补码？这是因为MDK的整数是按照补码存储的，正数的补码与原码相同，在这种情况下，原码和补码是一致的，不但起不到冗余作用，反而对可靠性有害。比如存储的一个非零整数区因为干扰，RAM都被清零，由于原码和补码一致，按照3取2的“表决法”，会将干扰值0当做正确的数据。

    4.8对非易失性存储器进行备份存储

    非易失性存储器包括但不限于Flash、EEPROM、铁电。仅仅将写入非易失性存储器中的数据再读出校验是不够的。强干扰情况下可能导致非易失性存储器内的数据错误，在写非易失性存储器的期间系统掉电将导致数据丢失，中，将导致数据存储紊乱。一种可靠的办法是将非易失性存储器分成多个区，每个数据都将按照不同的形式写入到这些分区中，需要进行读取时，同时读出多份数据并进行表决，取相同数目较多的那个值。

    对于初始化序列或者有一定先后顺序的函数调用，为了保证调用顺序或者确保每个函数都被调用，我们可以使用环环相扣，实质上这也是一种软件锁。此外对于一些安全关键代码语句（是语句，而不是函数），可以给它们设置软件锁，只有持有特定钥匙的，才可以访问这些关键代码。也可以通俗的理解为，关键安全代码不能按照单一条件执行，要额外的多设置一个标志。

    比如，向Flash写一个数据，我们会判断数据是否合法、写入的地址是否合法，计算要写入的扇区。之后调用写Flash子程序，在这个子程序中，判断扇区地址是否合法、数据长度是否合法，之后就要将数据写入Flash。由于写Flash语句是安全关键代码，所以程序给这些语句上锁：必须具有正确的钥匙才可以写Flash。这样即使是程序跑飞到写Flash子程序，也能大大降低误写的风险。

    该程序段是编程lpc1778内部Flash，其中调用IAP程序的函数iap_entry(paramin, paramout)是关键安全代码，所以在执行该代码前，先判断一个特定设置的安全锁标志ProgStart，只有这个标志符合设定值，才会执行编程Flash操作。如果因为意外程序跑飞到该函数，由于ProgStart标志不正确，是不会对Flash进行编程的。

          通讯线上的数据误码相对严重，通讯线越长，所处的环境越恶劣，误码会越严重。抛开硬件和环境的作用，我们的软件应能识别错误的通讯数据。对此有一些应用措施：

    •  制定协议时，限制每帧的字节数；

     每帧字节数越多，发生误码的可能性就越大，无效的数据也会越多。对此以太网规定每帧数据不大于1500字节，高可靠性的CAN收发器规定每帧数据不得多于8字节，对于RS485，基于RS485链路应用最广泛的Modbus协议一帧数据规定不超过256字节。因此，建议制定内部通讯协议时，使用RS485时规定每帧数据不超过256字节；

               1)增加缓冲区溢出判断。这是因为数据接收多是在中断中完成，编译器检测不出缓冲区是否溢出，需要手动检查，在上文介绍数据溢出一节中已经详细说明。

     2)增加超时判断。当一帧数据接收到一半，长时间接收不到剩余数据，则认为这帧数据无效，重新开始接收。可选，跟不同的协议有关，但缓冲区溢出判断必须实现。这是因为对于需要帧头判断的协议，上位机可能发送完帧头后突然断电，重启后上位机是从新的帧开始发送的，但是下位机已经接收到了上次未发送完的帧头，所以上位机的这次帧头会被下位机当成正常数据接收。这有可能造成数据长度字段为一个很大的值，填满该长度的缓冲区需要相当多的数据（比如一帧可能1000字节），影响响应时间；另一方面，如果程序没有缓冲区溢出判断，那么缓冲区很可能溢出，后果是灾难性的。

    4.11开关量输入的检测、确认

          开关量容易受到尖脉冲干扰，如果不进行滤除，可能会造成误动作。一般情况下，需要对开关量输入信号进行多次采样，并进行逻辑判断直到确认信号无误为止。

          开关信号简单的一次输出是不安全的，干扰信号可能会翻转开关量输出的状态。采取重复刷新输出可以有效防止电平的翻转。

    4.13初始化信息的保存和恢复

          微处理器的寄存器值也可能会因外界干扰而改变，外设初始化值需要在寄存器中长期保存，最容易被破坏。由于Flash中的数据相对不易被破坏，可以将初始化信息预先写入Flash，待程序空闲时比较与初始化相关的寄存器值是否被更改，如果发现非法更改则使用Flash中的值进行恢复。

    公司目前使用的4.3寸LCD显示屏抗干扰能力一般。如果显示屏与控制器之间的排线距离过长或者对使用该显示屏的设备打静电或者脉冲群，显示屏有可能会花屏或者白屏。对此，我们可以将初始化显示屏的数据保存在Flash中，程序运行后，每隔一段时间从显示屏的寄存器读出当前值和Flash存储的值相比较，如果发现两者不同，则重新初始化显示屏。下面给出校验源码，仅供参考。

        定义const修饰的结构体变量，存储LCD部分寄存器的初始值，这个初始值跟具体的应用初始化有关，不一定是表中的数据，通常情况下，这个结构体变量被存储到Flash中。 

    1. /LCD部分寄存器设置值列表/ 
 
     
    
 实现函数如下所示，函数会遍历结构体变量中的每一个命令，以及每一个命令下的初始值，如果有一个不正确，则跳出循环，执行重新初始化和恢复措施。这个函数中的MY_DEBUGF宏是我自己的调试函数，使用串口打印调试信息，在接下来的第五部分将详细叙述。通过这个函数，我可以长时间监控显示屏的哪些命令、哪些位容易被干扰。程序里使用了一个被妖魔化的关键字：goto。大多数C语言书籍对goto关键字谈之色变，但你应该有自己的判断。在函数内部跳出多重循环，除了goto关键字，又有哪种方法能如此简洁高效！
 
 
    3. * 每隔一段时间调用该程序一次 
 
     

     
    
       对于8051内核单片机，由于没有相应的硬件支持，可以用纯软件设置软件陷阱，用来拦截一些程序跑飞。对于ARM7或者Cortex-M系列单片机，硬件已经内建了多种异常，软件需要根据硬件异常来编写陷阱程序，用来快速定位甚至恢复错误。
 
 

     
    
       有时候程序员会使用while(!flag);语句阻塞在此等待标志flag改变，比如串口发送时用来等待一字节数据发送完成。这样的代码时存在风险的，如果因为某些原因标志位一直不改变则会造成系统死机。
 
 
    
       一个良好冗余的程序是设置一个超时定时器，超过一定时间后，强制程序退出while循环。
 
 
    
     2003年8月11日发生的W32.Blaster.Worm蠕虫事件导致全球经济损失高达5亿美元，这个漏洞是利用了Windows分布式组件对象模型的远程过程调用接口中的一个逻辑缺陷：在调用GetMachineName()函数时，循环只设置了一个不充分的结束条件。
 
 
    
 
 
     
     
    
     微软发布的安全补丁MS03-026解决了这个问题，为GetMachineName()函数设置了充分终止条件。一个解决代码简化如下所示（并非微软补丁代码）：
 
 
     
     
    
        思维再缜密的程序员也不可能编写完全无缺陷的程序，测试的目的正是尽可能多的发现这些缺陷并改正。这里说的测试，是指程序员的自测试。前期的自测试能够更早的发现错误，相应的修复成本也会很低，如果你不彻底测试自己的代码，恐怕你开发的就不只是代码，可能还会声名狼藉。
 
 
    
 优质嵌入式C程序跟优质的基础元素关系密切，可以将函数作为基础元素，我们的测试正是从最基本的函数开始。判断哪些函数需要测试需要一定的经验积累，虽然代码行数跟逻辑复杂度并不成正比，但如果你不能判断某个函数是否要测试，一个简单粗暴的方法是：当函数有效代码超过20行，就测试它。
 
 
    
 程序员对自己的代码以及逻辑关系十分清楚，测试时，按照每一个逻辑分支全面测试。很多错误发生在我们认为不会出错的地方，所以即便某个逻辑分支很简单，也建议测试一遍。第一个原因是我们自己看自己的代码总是不容易发现错误，而测试能暴露这些错误；另一方面，语法正确、逻辑正确的代码，经过编译器编译后，生成的汇编代码很可能与你的逻辑相差甚远。比如我们前文提及的使用volatile以及不使用volatile关键字编译后生成的汇编代码，再比如我们用低优化级别编译和使用高优化级别编译后生成的汇编代码，都可能相差很大，实际运行测试，可以暴漏这些隐含错误。最后，虽然可能性极小，编译器本身也可能有BUG，特别是构造复杂表达式的情况下（应极力避免复杂表达式）。

    5.1使用硬件调试器测试 

     
 
    
        使用硬件调试器（比如J-link）测试是最通用的手段。可以单步运行、设置断点，可以很方便的查看当前寄存器、变量的值。在寻找缺陷方面，使用硬件调试器测试是最简单却又最有效的手段。
 
 
    
        硬件调试器已经在公司普遍使用，这方面的测试不做介绍，想必大家都已经很熟悉了。
 
 

     
    
        就像没有一种方法能完美解决所有问题，在实际项目中，硬件调试器也有难以触及的地方。可以举几个例子说明：
    •  使用了比较大的协议栈，需要跟进到协议栈内部调试的缺陷 
     
    
            比如公司使用lwIP协议栈，如果跟踪数据的处理过程，需要从接收数据开始一直到应用层处理数据，之间会经过驱动层、IP层、TCP层和应用层，会经过十几个文件几十个函数，使用硬件调试器跟踪费时费力；
    •  具有随机性的缺陷 
     
    
           有一些缺陷，可能是不定时出现的，有可能是几分钟出现，也有可能是几个小时甚至几天才出现，像这样的缺陷很难用硬件调试器捕捉到；
    •  需要外界一系列有时间限制的输入条件触发，但这一过程中有缺陷 
     
    
       比如我们用组合键来完成某个功能，规定按下按键1不小于3秒后松开，然后在6秒内分别按下按键2、按键3、按键4这三个按键来执行我们的特定程序，要测试类似这种过程，硬件调试器很难做到；
 
 
    
       除了测试缺陷需要，有时候我们在做稳定性测试时，需要知道软件每时每刻运行到那些分支、执行了哪些操作、我们关心的变量当前值是什么等等，这些都表明，我们还需要一种和硬件调试器互补的测试手段。
 
 
    
       这个测试手段就是在程序中增加额外调试语句，当程序运行时，通过这些调试语句将运行信息输出到可以方便查看的设备上，可以是PC机、LCD显示屏、存储卡等等。
 
 
    
       以串口输出到PC机为例，下面提供完整的测试思路。在此之前，我们先对这种测试手段提一些要求：
 
 
     
    
            我们在初学C语言的时候，都接触过printf函数，这个函数可以方便的输出信息，并可以将各种变量格式化为指定格式的字符串，我们应当提供类似的函数；
    •  调试语句必须方便的从代码中移除 
     
    
           在编码阶段，我们可能会往程序中加入大量的调试语句，但是程序发布时，需要将这些调试语句从代码中移除，这将是件恐怖的过程。我们必须提供一种策略，可以方便的移除这些调试语句。

    5.2.1简单易用的调试函数 

     
 
    
 
 
    
 
 
    
 
 
    9. /这里是一个跟硬件相关函数,将一个字符写到UART / 
 
     
    
 MicroLIB前的复选框以便避免使用半主机功能。（注：标准C库printf函数默认开启半主机功能，如果非要使用标准C库，请自行查阅资料）
 
 
    
 
 
    
       使用库函数比较方便，但也少了一些灵活性，不利于随心所欲的定制输出格式。自己编写类似printf函数则会更灵活一些，而且不依赖任何编译器。下面给出一个完整的类printf函数实现，该函数支持有限的格式参数，使用方法与库函数一致。同库函数类似，该也需要提供一个底层串口发送函数（原型为：int32_t UARTwrite(const

    5.2.2对调试函数进一步封装 

     
 
    
       上文说到，我们增加的调试语句应能很方便的从最终发行版中去掉，因此我们不能直接调用printf或者自定义的UARTprintf函数，需要将这些调试函数做一层封装，以便随时从代码中去除这些调试语句。参考方法如下：
 
 
     
     
    
 在我们编码测试期间，定义宏MY_DEBUG，并使用宏MY_DEBUGF（注意比前面那个宏多了一个‘F’）输出调试信息。经过预处理后，宏MY_DEBUGF(message)会被UARTprintf
 message代替，从而实现了调试信息的输出；当正式发布时，只需要将宏MY_DEBUG注释掉，经过预处理后，所有MY_DEBUGF(message)语句都会被空格代替，而从将调试信息从代码中去除掉。
 
 

     
    
        《计算机程序结构与说明》一书在开篇写到：程序写出来是给人看的，附带能在机器上运行。
 
 

     
    
 使用什么样的编码样式一直都颇具争议性的，比如缩进和大括号的位置。因为编码的样式也会影响程序的可读性，面对一个乱放括号、对齐都不一致的源码，我们很难提起阅读它的兴趣。我们总要看别人的程序，如果彼此编码样式相近，读起源码来会觉得比较舒适。但是编码风格的问题是主观的，永远不可能在编码风格上达成统一意见。因此只要你的编码样式整洁、结构清晰就足够了。除此之外，对编码样式再没有其它要求。
 
 
    
 Simonyi说：我觉得代码清单带给人的愉快同整洁的家差不多。你一眼就能分辨出家里是杂乱无章还是整洁如新。这也许意义不大。因为光是房子整洁说明不了什么，它仍可能藏污纳垢！但是第一印象很重要，它至少反映了程序的某些方面。我敢打赌，我在3米开外就能看出程序拙劣与否。我也许没法保证它很不错，但如果从3米外看起来就很糟，我敢保证这程序写得不用心。如果写得不用心，那它在逻辑上也许就不会优美。
 
 

     
    
 变量、函数、宏等等都需要命名，清晰的命名是优秀代码的特点之一。命名的要点之一是名称应能清晰的描述这个对象，以至于一个初级程序员也能不费力的读懂你的代码逻辑。我们写的代码主要给谁看是需要思考的：给自己、给编译器还是给别人看？我觉得代码最主要的是给别人看，其次是给自己看。如果没有一个清晰的命名，别人在维护你的程序时很难在整个全貌上看清代码，因为要记住十多个以上的糟糕命名的变量是件非常困难的事；而且一段时间之后你回过头来看自己的代码，很有可能不记得那些糟糕命名的变量是什么意思。
 
 
    
 为对象起一个清晰的名字并不是简单的事情。首先能认识到名称的重要性需要有一个过程，这也许跟谭式C程序教材被大学广泛使用有关：满书的a、b、c、x、y、z变量名是很难在关键的初学阶段给人传达优秀编程思想的；其次如何恰当的为对象命名也很有挑战性，要准确、无歧义、不罗嗦，要对英文有一定水平，所有这些都要满足时，就会变得很困难；此外，命名还需要考虑整体一致性，在同一个项目中要有统一的风格，坚持这种风格也并不容易。
 
 
    
        关于如何命名，Charles Simonyi说：面对一个具备某些属性的结构，不要随随便便地取个名字，然后让所有人去琢磨名字和属性之间有什么关联，你应该把属性本身，用作结构的名字。
 
 

     
    
 注释向来也是争议之一，不加注释和过多的注释我都是反对的。不加注释的代码显然是很糟糕的，但过多的注释也会妨碍程序的可读性，由于注释可能存在的歧义，有可能会误解程序真实意图，此外，过多的注释会增加程序员不必要的时间。如果你的编码样式整洁、命名又很清晰，那么，你的代码可读性不会差到哪去，而注释的本意就是为了便于理解程序。
 
 
    
 这里建议使用良好的编码样式和清晰的命名来减少注释，对模块、函数、变量、数据结构、算法和关键代码做注释，应重视注释的质量而不是数量。如果你需要一大段注释才能说清楚程序做什么，那么你应该注意了：是否是因为程序变量命名不够清晰，或者代码逻辑过于混乱，这个时候你应该考虑的可能就不是注释，而是如何精简这个程序了。
 
 

     
    
       数据结构是程序设计的基础。在设计程序之前，应该先考虑好所需要的数据结构。
 
 
    
 Simonyi：编程的第一步是想象。就是要在脑海中对来龙去脉有极为清晰的把握。在这个初始阶段，我会使用纸和铅笔。我只是信手涂鸦，并不写代码。我也许会画些方框或箭头，但基本上只是涂鸦，因为真正的想法在我脑海里。我喜欢想象那些有待维护的结构，那些结构代表着我想编码的真实世界。一旦这个结构考虑得相当严谨和明确，我便开始写代码。我会坐到终端前，或者换在以前的话，就会拿张白纸，开始写代码。这相当容易。我只要把头脑中的想法变换成代码写下来，我知道结果应该是什么样的。大部分代码会水到渠成，不过我维护的那些数据结构才是关键。我会先想好数据结构，并在整个编码过程中将它们牢记于心。
 
 
    
     开发过以太网和操作系统SDS 940的Butler Lampson：（程序员）最重要的素质是能够把问题的解决方案组织成容易操控的结构。
 
 
    
     开发CP/M操作系统的Gary.A：如果不能确认数据结构是正确的，我是决不会开始编码的。我会先画数据结构，然后花很长时间思考数据结构。在确定数据结构之后我就开始写一些小段的代码，并不断地改善和监测。在编码过程中进行测试可以确保所做的修改是局部的，并且如果有什么问题的话，能够马上发现。
 
 
    
     微软创始人比尔·盖茨：编写程序最重要的部分是设计数据结构。接下来重要的部分是分解各种代码块。
 
 
    
     编写世界上第一个电子表格软件的Dan Bricklin：在我看来，写程序最重要的部分是设计数据结构，此外，你还必须知道人机界面会是什么样的。
 
 
    
 我们举个例子来说明。在介绍防御性编程的时候，提到公司使用的LCD显示屏抗干扰能力一般，为了提高LCD的稳定性，需要定期读出LCD内部的关键寄存器值，然后跟存在Flash中的初始值相比较。需要读出的LCD寄存器有十多个，从每个寄存器读出的值也不尽相同，从1个到8个字节都有可能。如果不考虑数据结构，编写出的程序将会很冗长。
 
 
    3. 读第一个寄存器值; 
6. 读第二个寄存器值; 
11. 读第十个寄存器值; 
 
     
    
       我们分析这个过程，发现能提取出很多相同的元素，比如每次读LCD寄存器都需要该寄存器的命令号，都会经过读寄存器、判断值是否相同、处理异常情况这一过程。所以我们可以提取一些相同的元素，组织成数据结构，用统一的方法去处理这些数据，将数据与处理过程分开来。
       我们可以先提取相同的元素，将之组织成数据结构：
 
     
     
    
 这里lcd_command表示的是LCD寄存器命令号；lcd_get_value是一个数组，表示寄存器要初始化的值，这是因为对于一个LCD寄存器，可能要初始化多个字节，这是硬件特性决定的；lcd_value_num是指一个寄存器要多少个字节的初值，这是因为每一个寄存器的初值数目是不同的，我们用同一个方法处理数据时，是需要这个信息的。
 
 
    
       就本例而言，我们将要处理的数据都是事先固定的，所以定义好数据结构后，我们可以将这些数据组织成表格：
 
 
     
    1. /LCD部分寄存器设置值列表/ 
 
          至此，我们就可以用一个处理过程来完成数十个LCD寄存器的读取、判断和异常处理了：
 
    3. * 每隔一段时间调用该程序一次 
 
     
    
 通过合理的数据结构，我们可以将数据和处理过程分开，LCD冗余判断过程可以用很简洁的代码来实现。更重要的是，将数据和处理过程分开更有利于代码的维护。比如，通过实验发现，我们还需要增加一个LCD寄存器的值进行判断，这时候只需要将新增加的寄存器信息按照数据结构格式，放到LCD寄存器设置值列表中的任意位置即可，不用增加任何处理代码即可实现！这仅仅是数据结构的优势之一，使用数据结构还能简化编程，使复杂过程变的简单，这个只有实际编程后才会有更深的理解。
 
 
    
 本文介绍了编写优质嵌入式C程序涉及的多个方面。每年都有亿万计的C程序运行在单片机、ARM7、Cortex-M3这些微处理器上，但在这些处理器上如何编写优质高效的C程序，几乎没有书籍做专门介绍。本文试图在这方面做一些努力。编写优质嵌入式C程序需要大量的专业知识，本文虽尽力描述编写嵌入式C程序所需要的各种技能，但本文却无力将每一个方面都面面俱到的描述出来，所以本文最后会列举一些阅读书目，这些书大多都是真正大师的经验之谈。站在巨人的肩膀上，可以看的更远。
    •  陈正冲 编著 《C语言深度解剖》
    •  杜春雷 编著 《ARM体系结构与编程》

我要回帖

更多关于 X.25 的文章

 

随机推荐