C语言代码怎么编写这个程序

一个程序本质上都是由 BSS 段、data段、text段三个组成的这样的概念在当前的计算机程序设计中是很重要的一个基本概念,而且在嵌入式系统的设计中也非常重要牵涉到嵌入式系统运行时的内存大小分配,存储单元占用空间大小的问题

  • BSS段:在采用段式内存管理的架构中,BSS段(bss segment)通常是指用来存放程序中未初始囮的全局变量的一块内存区域BSS是英文Block Started by Symbol的简称。BSS段属于静态内存分配
  • 数据段:在采用段式内存管理的架构中,数据段(data segment)通常是指用来存放程序中已初始化的全局变量的一块内存区域数据段属于静态内存分配。
  • 代码段:在采用段式内存管理的架构中代码段(text segment)通常是指用来存放程序执行代码的一块内存区域。这部分区域的大小在程序运行前就已经确定并且内存区域属于只读。在代码段中也有可能包含一些只读的常数变量,例如字符串常量等

程序后生成的目标文件至少含有这三个段,这三个段的大致结构图如下所示:

其中.text即为代碼段为只读。.bss段包含程序中未初始化的全局变量和static变量data段包含三个部分:heap(堆)、stack(栈)和静态数据区。

  • 堆(heap):堆是用于存放进程运行中被動态分配的内存段它的大小并不固定,可动态扩张或缩减当进程调用malloc等函数分配内存时,新分配的内存就被动态添加到堆上(堆被扩張);当利用free等函数释放内存时被释放的内存从堆中被剔除(堆被缩减)
  • 栈(stack):栈又称堆栈, 是用户存放程序临时创建的局部变量也就昰说我们函数括弧“{}”中定义的变量(但不包括static声明的变量,static意味着在数据段中存放变量)除此以外,在函数被调用时其参数也会被壓入发起调用的进程栈中,并且待到调用结束后函数的返回值也会被存放回栈中。由于栈的先进先出特点所以栈特别方便用来保存/恢複调用现场。从这个意义上讲我们可以把堆栈看成一个寄存、交换临时数据的区。

当程序在执行时动态分配空间(C中的malloc函数)所分配嘚空间就属于heap。其概念与数据结构中“堆”的概念不同

stack段存放函数内部的变量、参数和返回地址,其在函数被调用时自动分配访问方式就是标准栈中的LIFO方式。(因为函数的局部变量存放在此因此其访问方式应该是栈指针加偏移的方式,否则若通过push、pop操作来访问相当麻煩)

data段中的静态数据区存放的是程序中已初始化的全局变量、静态变量和常量

在采用段式内存管理的架构中(比如intel的80x86系统),BSS 段(Block Started by Symbol segment)通瑺是指用来存放程序中未初始化的全局变量的一块内存区域一般在初始化时 BSS 段部分将会清零。BSS 段属于静态内存分配即程序一开始就将其清零了。

比如在C语言代码之类的程序编译完成之后,已初始化的全局变量保存在.data 段中未初始化的全局变量保存在.bss 段中。

text和data段都在可執行文件中(在嵌入式系统里一般是固化在镜像文件中)由系统从可执行文件中加载;而BSS段不在可执行文件中,由系统初始化

BSS段只保存没有值的变量,所以事实上它并不需要保存这些变量的映像运行时所需要的BSS段大小记录在目标文件中,但BSS段并不占据目标文件的任何涳间

举个具体的C语言代码的例子吧:


  

本文地址:,欢迎访问原出处

}
  • C语言代码是需要编译的编译后執行,建议你找个好一点的编译器。
    全部
}
分享一下我的经历:大一的暑假留在学校把《零基础学C语言代码》一书看完了。我是一个接触新东西比较迟钝的人所以,我是一边看书一边做笔记,一边照着书本嘚例程在电脑上敲代码的大二,专业开设了一门计算机语言课程——C语言代码那时候,任课老师在上面说的话我基本上都已经看过叻。久而久之我去了图书馆找其他C语言代码的书籍看,因为我感觉C语言代码没我想像的那么简单在这里提示一点就是:看过一本教程式的C语言代码教程书籍后,不要再看太多这类书了现在我在学习c++,因为有了大一扎实的C语言代码基础学习c++相对容易接受。在了解了c++之後我是打算入手java的。冥冥中的三者有种异曲同工之妙指针不会,是因为你没有计算机基础知识的积累不了解计算机的内部结构。个囚推荐可以看看《c和指针》一书学计算机语言有时候要试图站在计算机的角度思考问题,你懂的计算机不一定能懂既然要站在计算机嘚角度思考,就要了解算法计算机算法,以及计算机的内部结构另外一点体外话就是,,如果感觉看书无聊的话可以上网找视频看,现在的网络资源也挺多的就好比本站的“程序设计”栏目,里面就有很多类似的资源学习编程要耐的住寂寞,把计算机当作朋友(尽管这样子很傻)本人不才,上述只是本人的一点点看法如有错误,还请各位大神指点一二
}

市面上介绍C语言代码以及编程方法的书数目繁多但对如何编写优质嵌入式C程序却鲜有介绍,特别是对应用于单片机、ARM7、Cortex-M3这类微控制器上的优质C程序编写方法几乎是个空皛本文面向的,正是使用单片机、ARM7、Cortex-M3这类微控制器的底层编程人员

编写优质嵌入式C程序绝非易事,它跟设计者的思维和经验积累关系密切嵌入式C程序员不仅需要熟知硬件的特性、硬件的缺陷等,更要深入一门语言编程不浮于表面。为了更方便的操作硬件还需要对編译器进行深入的了解。

本文将从语言特性、编译器、防御性编程、测试和编程思想这几个方面来讨论如何编写优质嵌入式C程序与很多雜志、书籍不同,本文提供大量真实实例、代码段和参考书目不仅介绍应该做什么,还重点介绍如何做、以及为什么这样做编写优质嵌入式C程序涉及面十分广,需要程序员长时间的经验积累本文希望能缩短这一过程。

语言是编程的基石C语言代码诡异且有种种陷阱和缺陷,需要程序员多年历练才能达到较为完善的地步虽然有众多书籍、杂志、专题讨论过C语言代码的陷阱和缺陷,但这并不影响本节再佽讨论它总是有大批的初学者,前仆后继的倒在这些陷阱和缺陷上民用设备、工业设备甚至是航天设备都不例外。本节将结合具体例孓再次审视它们希望引起足够重视。深入理解C语言代码特性是编写优质嵌入式C程序的基础。

将比较运算符”==”误写成赋值运算符”=”可能是绝大多数人都遇到过的。

代码的本意是比较变量x是否等于常量5但是误将”==”写成了”=”,if语句恒为真如果在逻辑判断表达式Φ出现赋值运算符,现在的大多数编译器会给出警告信息比如keil MDK会给出警告提示:“warning:  #187-D: use of "=" where"==" may have been intended”,但并非所有程序员都会注意到这类警告因此有經验的程序员使用下面的代码来避免此类错误:

将常量放在变量x的左边,即使程序员误将’==’写成了’=’编译器会产生一个任谁也不能無视的语法错误信息:不可给常量赋值!

复合赋值运算符(+=、*=等等)虽然可以使表达式更加简洁并有可能产生更高效的机器代码,但某些複合赋值运算符也会给程序带来隐含Bug比如”+=”容易误写成”=+”,代码如下:

代码本意是想表达tmp=tmp+1但是将复合赋值运算符”+=”误写成”=+”:将正整数常量1赋值给变量tmp。编译器会欣然接受这类代码连警告都不会产生。

如果你能在调试阶段就发现这个Bug真应该庆祝一下,否则這很可能会成为一个重大隐含Bug且不易被察觉。

复合赋值运算符”-=”也有类似问题存在

头文件声明语句最后忘记结束分号

逻辑与&&和位与&、逻辑或||和位或|、逻辑非!和位取反~

字母l和数字1、字母O和数字0

这些误写其实容易被编译器检测出,只需要关注编译器对此的提示信息就能很快解决。

很多的软件Bug源自于输入错误在Google上搜索的时候,有些结果列表项中带有一条警告表明Google认为它带有恶意代码。如果你在2009年1月31ㄖ一大早使用Google搜索的话你就会看到,在那天早晨55分钟的时间内Google的搜索结果标明每个站点对你的PC都是有害的。这涉及到整个Internet上的所有站點包括Google自己的所有站点和服务。Google的恶意软件检测功能通过在一个已知攻击者的列表上查找站点从而识别出危险站点。在1月31日早晨对這个列表的更新意外地包含了一条斜杠(“/”)。所有的URL都包含一条斜杠并且,反恶意软件功能把这条斜杠理解为所有的URL都是可疑的因此,它愉快地对搜索结果中的每个站点都添加一条警告很少见到如此简单的一个输入错误带来的结果如此奇怪且影响如此广泛,但程序就昰这样容不得一丝疏忽。

数组常常也是引起程序不稳定的重要因素C语言代码数组的迷惑性与数组下标从0开始密不可分,你可以定义int test[30]泹是你绝不可以使用数组元素test [30],除非你自己明确知道在做什么

switch…case语句可以很方便的实现多分支结构,但要注意在合适的位置添加break关键字程序员往往容易漏加break从而引起顺序执行多个case语句,这也许是C的一个缺陷之处

对于switch…case语句,从概率论上说绝大多数程序一次只需执行┅个匹配的case语句,而每一个这样的case语句后都必须跟一个break去复杂化大概率事件,这多少有些不合常情

break关键字用于跳出最近的那层循环语呴或者switch语句,但程序员往往不够重视这一点

1990年1月15日,AT&T电话网络位于纽约的一台交换机宕机并且重启引起它邻近交换机瘫痪,由此及彼一个连着一个,很快114台交换机每六秒宕机重启一次,六万人九小时内不能打长途电话当时的解决方式:工程师重装了以前的软件版夲。。事后的事故调查发现这是break关键字误用造成的。《C专家编程》提供了一个简化版的问题源码:

那个程序员希望从if语句跳出但他卻忘记了break关键字实际上跳出最近的那层循环语句或者switch语句。现在它跳出了switch语句执行了use_modes_pointer()函数。但必要的初始化工作并未完成为将来程序嘚失败埋下了伏笔。

2.1.4 意想不到的八进制

将一个整形常量赋值给变量代码如下所示:

答案是不相等的。我们知道16进制常量以’0x’为前缀,10进制常量不需要前缀那么8进制呢?它与10进制和16进制表示方法都不相通它以数字’0’为前缀,这多少有点奇葩:三种进制的表示方法唍全不相通如果8进制也像16进制那样以数字和字母表示前缀的话,或许更有利于减少软件Bug毕竟你使用8进制的次数可能都不会有误使用的佽数多!下面展示一个误用8进制的例子,最后一个数组元素赋值错误:

2.1.5指针加减运算

指针的加减运算是特殊的下面的代码运行在32位ARM架构仩,执行之后a和p的值分别是多少?

对于a的值很容判断出结果为2但是p的结果却是0x。指针p加1后p的值增加了4,这是为什么呢原因是指针莋加减运算时是以指针的数据类型为单位。p+1实际上是按照公式p+1*sizeof(int)来计算的不理解这一点,在使用指针直接操作数据时极易犯错

某项目使鼡下面代码对连续RAM初始化零操作,但运行发现有些RAM并没有被真正清零

通过分析我们发现,由于pRAMaddr是一个无符号int型指针变量所以pRAMaddr+=4代码其实使pRAMaddr偏移了4*sizeof(int)=16个字节,所以每执行一次for循环会使变量pRAMaddr偏移16个字节空间,但只有4字节空间被初始化为零其它的12字节数据的内容,在大多数架構处理器中都会是随机数

不知道有多少人最初认为sizeof是一个函数。其实它是一个关键字其作用是返回一个对象或者类型所占的内存字节數,对绝大多数编译器而言返回值为无符号整形数据。需要注意的是使用sizeof获取数组长度时,不要对指针应用sizeof操作符比如下面的例子:

我们知道,对于一个数组array[20]我们使用代码sizeof(array)/sizeof(array[0])可以获得数组的元素(这里为20),但数组名和指针往往是容易混淆的有且只有一种情况下数組名是可以当做指针的,那就是数组名作为函数形参时数组名被认为是指针,同时它不能再兼任数组名。注意只有这种情况下数组洺才可以当做指针,但不幸的是这种情况下容易引发风险在ClearRAM函数内,作为形参的array[]不再是数组名了而成了指针。sizeof(array)相当于求指针变量占用嘚字节数在32位系统下,该值为4sizeof(array)/sizeof(array[0])的运算结果也为4。所以在main函数中调用ClearRAM(Fle)也只能清除数组Fle中的前四个元素了。

2.1.7增量运算符’++’和减量运算苻’—‘

增量运算符”++”和减量运算符”--“既可以做前缀也可以做后缀前缀和后缀的区别在于值的增加或减少这一动作发生的时间是不哃的。作为前缀是先自加或自减然后做别的运算作为后缀时,是先做运算之后再自加或自减。许多程序员对此认识不够就容易埋下隱患。下面的例子可以很好的解释前缀和后缀的区别

代码执行后,y的值是多少

这个例子并非是挖空心思设计出来专门让你绞尽脑汁的C難题(如果你觉得自己对C细节掌握很有信心,做一些C难题检验一下是个不错的选择那么,《The C Puzzle Book》这本书一定不要错过)你甚至可以将这個难懂的语句作为不友好代码的例子。但是它也可以让你更好的理解C语言代码根据运算符优先级以及编译器识别字符的贪心法原则,第②句代码可以写成更明确的形式:

当赋值给变量y时a的值为8,b的值为1,所以变量y的值为9;赋值完成后变量a自加,a的值变为9千万不要以为y嘚值为10。这条赋值语句相当于下面的两条语句:

为了提高系统效率逻辑与和逻辑或操作的规定如下:如果对第一个操作数求值后就可以嶊断出最终结果,第二个操作数就不会进行求值!比如下面代码:

在这个代码中只有当i>=0时,i++才会被执行这样,i是否自增是不够明确的这可能会埋下隐患。逻辑或与之类似

2.1.9结构体的填充

结构体可能产生填充,因为对大多数处理器而言访问按字或者半字对齐的数据速喥更快,当定义结构体时编译器为了性能优化,可能会将它们按照半字或字对齐这样会带来填充问题。比如以下两个个结构体:

这两個结构体元素都是相同的变量只是元素换了下位置,那么这两个结构体变量占用的内存大小相同吗

其实这两个结构体变量占用的内存昰不同的,对于Keil MDK编译器默认情况下第一个结构体变量占用8个字节,第二个结构体占用12个字节差别很大。第一个结构体变量在内存中的存储格式如图2-1所示:

图2-1:结构体变量1内存分布

第二个结构体变量在内存中的存储格式如图2-2所示对比两个图可以看出MDK编译器是是怎么将数據对齐的,这其中的填充内容是之前内存中的数据是随机的,所以不能再结构之间逐字节比较;另外合理的排布结构体内的元素位置,可以最大限度减少填充节省RAM。

图2-2 :结构体变量2内存分布

2.2不可轻视的优先级

C语言代码有32个关键字却有34个运算符。要记住所有运算符的優先级是困难的稍不注意,你的代码逻辑和实际执行就会有很大出入

比如下面将BCD码转换为十六进制数的代码:

这里uTimeValue存放的BCD码,想要转換成16进制数据实际运行发现,如果uTimeValue的值为0x23按照我设定的逻辑,result的值应该是0x17但运算结果却是0x07。经过种种排查后才发现’+’的优先级昰大于’&’的,相当于(uTimeValue>>4)*10+uTimeValue与0x0F位与结果自然与逻辑不符。符合逻辑的代码应该是:

不合理的#define会加重优先级问题让问题变得更加隐蔽。

按照瑺规方式使用时可能引起误会的运算符还有很多,如表2-1所示C语言代码的运算符当然不会只止步于数目繁多!

有一个简便方法可以避免優先级问题:不清楚的优先级就加上”()”,但这样至少有会带来两个问题:

过多的括号影响代码的可读性包括自己和以后的维护人员

别囚的代码不一定用括号来解决优先级问题,但你总要读别人的代码 

无论如何在嵌入式编程方面,该掌握的基础知识偷巧不得。建议花┅些时间将优先级顺序以及容易出错的优先级运算符理清几遍。

C语言代码的设计理念一直被人吐槽因为它认为C程序员完全清楚自己在莋什么,其中一个证据就是隐式转换C语言代码规定,不同类型的数据(比如char和int型数据)需要转换成同一类型后才可进行计算。如果你混合使用类型比如用char类型数据和int类型数据做减法,C使用一个规则集合来自动(隐式的)完成类型转换这可能很方便,但也很危险

这僦要求我们理解这个转换规则并且能应用到程序中去!

提升在算数运算中通常不会有什么大的坏处,但如果位运算符 ~ 和

假如我们不了解表達式里的类型提升认为在运算过程中变量port一直是unsigned char类型的。我们来看一下运算过程:~port结果为0xa50xa5>>4结果为0x0a,这是我们期望的值但实际上,result_8的結果却是0xfa!在ARM结构下int类型为32位。变量port在运算前被提升为int类型:~port结果为0xffffffa50xa5>>4结果为0x0ffffffa,赋值给变量result_8发生类型截断(这也是隐式的!),result_8=0xfa经過这么诡异的隐式转换,结果跟我们期望的值已经大相径庭!正确的表达式语句应该为:

这种类型提升通常都是件好事,但往往有很多程序员不能真正理解这句话比如下面的例子(int类型表示16位)。

u32x和u32y的结果都是4464()!不要认为表达式中有一个高类别uint32_t类型变量编译器都會帮你把所有其他低类别都提升到uint32_t类型。正确的书写方式:

后一种写法在本表达式中是正确的但是在其它表达式中不一定正确,比如:

3) 茬赋值语句里计算的最后结果被转换成将要被赋予值的那个变量的类型。这一过程可能导致类型提升也可能导致类型降级降级可能会導致问题。比如将运算结果为321的值赋值给8位char类型变量程序必须对运算时的数据溢出做合理的处理。很多其他语言像Pascal(C语言代码设计者の一曾撰文狠狠批评过Pascal语言),都不允许混合使用类型但C语言代码不会限制你的自由,即便这经常引起Bug

当不得已混合使用类型时,一個比较好的习惯是使用类型强制转换强制类型转换可以避免编译器隐式转换带来的错误,同时也向以后的维护人员传递一些有用信息這有个前提:你要对强制类型转换有足够的了解!下面总结一些规则:

并非所有强制类型转换都是由风险的,把一个整数值转换为一种具囿相同符号的更宽类型时是绝对安全的。

精度高的类型强制转换为精度低的类型时通过丢弃适当数量的最高有效位来获取结果,也就昰说会发生数据截断并且可能改变数据的符号位。

精度低的类型强制转换为精度高的类型时如果两种类型具有相同的符号,那么没什麼问题;需要注意的是负的有符号精度低类型强制转换为无符号精度高类型时会不直观的执行符号扩展,例如:

如果你和一个优秀的程序员共事你会发现他对他使用的工具非常熟悉,就像一个画家了解他的画具一样----比尔.盖茨

3.1不能简单的认为是个工具

嵌入式程序开发跟硬件密切相关,需要使用C语言代码来读写底层寄存器、存取数据、控制硬件等C语言代码和硬件之间由编译器来联系,一些C标准不支持的硬件特性操作由编译器提供。

汇编可以很轻易的读写指定RAM地址、可以将代码段放入指定的Flash地址、可以精确的设置变量在RAM中分布等等所囿这些操作,在深入了解编译器后也可以使用C语言代码实现。

C语言代码标准并非完美有着数目繁多的未定义行为,这些未定义行为完铨由编译器自主决定了解你所用的编译器对这些未定义行为的处理,是必要的

嵌入式编译器对调试做了优化,会提供一些工具可以汾析代码性能,查看外设组件等了解编译器的这些特性有助于提高在线调试的效率。

此外堆栈操作、代码优化、数据类型的范围等等,都是要深入了解编译器的理由

如果之前你认为编译器只是个工具,能够编译就好那么,是时候改变这种思想了

3.2不能依赖编译器的語义检查

编译器的语义检查很弱小,甚至还会“掩盖”错误现代的编译器设计是件浩瀚的工程,为了让编译器设计简单一些目前几乎所有编译器的语义检查都比较弱小。为了获得更快的执行效率C语言代码被设计的足够灵活且几乎不进行任何运行时检查,比如数组越界、指针是否合法、运算结果是否溢出等等这就造成了很多编译正确但执行奇怪的程序。

C语言代码足够灵活对于一个数组test[30],它允许使用潒test[-1]这样的形式来快速获取数组首元素所在地址前面的数据;允许将一个常数强制转换为函数指针使用代码(*((void(*)())0))()来调用位于0地址的函数。C语言玳码给了程序员足够的自由但也由程序员承担滥用自由带来的责任。

下面的两个例子都是死循环如果在不常用分支中出现类似代码,將会造成看似莫名其妙的死机或者重启

对于无符号char类型,表示的范围为0~255所以无符号char类型变量i永远小于256(第一个for循环无限执行),永远夶于等于0(第二个for循环无线执行)需要说明的是,赋值代码i=256是被C语言代码允许的即使这个初值已经超出了变量i可以表示的范围。C语言玳码会千方百计的为程序员创造出错的机会可见一斑。

3.2.2不起眼的改变

假如你在if语句后误加了一个分号可能会完全改变了程序逻辑。编譯器也会很配合的帮忙掩盖甚至连警告都不提示。代码如下:

不但如此编译器还会忽略掉多余的空格符和换行符,就像下面的代码也鈈会给出足够提示:

这段代码的本意是n=3时表达式logrec.data=x[0];就不会被执行,给程序埋下了隐患

3.2.3 难查的数组越界

上文曾提到数组常常是引起程序不穩定的重要因素,程序员往往不经意间就会写数组越界

一位同事的代码在硬件上运行,一段时间后就会发现LCD显示屏上的一个数字不正常嘚被改变经过一段时间的调试,问题被定位到下面的一段代码中:

这里声明了拥有30个元素的数组不幸的是for循环代码中误用了本不存在嘚数组元素SensorData[30],但C语言代码却默许这么使用并欣然的按照代码改变了数组元素SensorData[30]所在位置的值, SensorData[30]所在的位置原本是一个LCD显示变量这正是显礻屏上的那个值不正常被改变的原因。真庆幸这么轻而易举的发现了这个Bug

其实很多编译器会对上述代码产生一个警告:赋值超出数组界限。但并非所有程序员都对编译器警告保持足够敏感况且,编译器也并不能检查出数组越界的所有情况比如下面的例子:

你在模块A中萣义数组:

在模块B中引用该数组,但由于你引用代码并不规范这里没有显示声明数组大小,但编译器也允许这么做:

这次编译器不会給出警告信息,因为编译器压根就不知道数组的元素个数所以,当一个数组声明为具有外部链接它的大小应该显式声明。

再举一个编譯器检查不出数组越界的例子函数func()的形参是一个数组形式,函数代码简化如下所示:

这个给SensorData[30]赋初值的语句编译器也是不给任何警告的。实际上编译器是将数组名Sensor隐含的转化为指向数组第一个元素的指针,函数体是使用指针的形式来访问数组的它当然也不会知道数组え素的个数了。造成这种局面的原因之一是C编译器的作者们认为指针代替数组可以提高程序效率而且,可以简化编译器的复杂度

指针囷数组是容易给程序造成混乱的,我们有必要仔细的区分它们的不同其实换一个角度想想,它们也是容易区分的:可以将数组名等同于指针的情况有且只有一处就是上面例子提到的数组作为函数形参时。其它时候数组名是数组名,指针是指针

下面的例子编译器同样檢查不出数组越界。

我们常常用数组来缓存通讯中的一帧数据在通讯中断中将接收的数据保存到数组中,直到一帧数据完全接收后再进荇处理即使定义的数组长度足够长,接收数据的过程中也可能发生数组越界特别是干扰严重时。这是由于外界的干扰破坏了数据帧的某些位对一帧的数据长度判断错误,接收的数据超出数组范围多余的数据改写与数组相邻的变量,造成系统崩溃由于中断事件的异步性,这类数组越界编译器无法检查到

如果局部数组越界,可能引发ARM架构硬件异常

同事的一个设备用于接收无线传感器的数据,一次軟件升级后发现接收设备工作一段时间后会死机。调试表明ARM7处理器发生了硬件异常异常处理代码是一段死循环(死机的直接原因)。接收设备有一个硬件模块用于接收无线传感器的整包数据并存在自己的缓冲区中当硬件模块接收数据完成后,使用外部中断通知设备取數据外部中断服务程序精简后如下所示:

由于存在多个无线传感器近乎同时发送数据的可能加之GetData()函数保护力度不够,数组DataBuf在取数据过程Φ发生越界由于数组DataBuf为局部变量,被分配在堆栈中同在此堆栈中的还有中断发生时的运行环境以及中断返回地址。溢出的数据将这些數据破坏掉中断返回时PC指针可能变成一个不合法值,硬件异常由此产生

如果我们精心设计溢出部分的数据,化数据为指令就可以利鼡数组越界来修改PC指针的值,使之指向我们希望执行的代码

1988年,第一个网络蠕虫在一天之内感染了2000到6000台计算机这个蠕虫程序利用的正昰一个标准输入库函数的数组越界Bug。起因是一个标准输入输出库函数gets()原来设计为从数据流中获取一段文本,遗憾的是gets()函数没有规定输叺文本的长度。gets()函数内部定义了一个500字节的数组攻击者发送了大于500字节的数据,利用溢出的数据修改了堆栈中的PC指针从而获取了系统權限。目前虽然有更好的库函数来代替gets函数,但gets函数仍然存在着

做嵌入式设备开发,如果不对volatile修饰符具有足够了解实在是说不过去。volatile是C语言代码32个关键字中的一个属于类型限定符,常用的const关键字也属于类型限定符

volatile限定符用来告诉编译器,该对象的值无任何持久性不要对它进行任何优化;它迫使编译器每次需要该对象数据内容时都必须读该对象,而不是只读一次数据并将它放在寄存器中以便后续訪问之用(这样的优化可以提高系统速度)

这个特性在嵌入式应用中很有用,比如你的IO口的数据不知道什么时候就会改变这就要求编譯器每次都必须真正的读取该IO端口。这里使用了词语“真正的读”是因为由于编译器的优化,你的逻辑反应到代码上是对的但是代码經过编译器翻译后,有可能与你的逻辑不符你的代码逻辑可能是每次都会读取IO端口数据,但实际上编译器将代码翻译成汇编时可能只昰读一次IO端口数据并保存到寄存器中,接下来的多次读IO口都是使用寄存器中的值来进行处理因为读写寄存器是最快的,这样可以优化程序效率与之类似的,中断里的变量、多线程中的共享变量等都存在这样的问题

不使用volatile,可能造成运行逻辑错误但是不必要的使用volatile会慥成代码效率低下(编译器不优化volatile限定的变量),因此清楚的知道何处该使用volatile限定符是一个嵌入式程序员的必修内容。

一个程序模块通瑺由两个文件组成源文件和头文件。如果你在源文件定义变量:

并在头文件中声明该变量:

编译器会提示一个语法错误:变量’ test’声明類型不一致但如果你在源文件定义变量:

在头文件中这样声明变量:

编译器却不会给出错误信息(有些编译器仅给出一条警告)。当你茬另外一个模块(该模块包含声明变量test的头文件)使用变量test时它已经不再具有volatile限定,这样很可能造成一些重大错误比如下面的例子,紸意该例子是为了说明volatile限定符而专门构造出的因为现实中的volatile使用Bug大都隐含,并且难以理解

在模块A的源文件中,定义变量:

该变量用来茬一个定时器中断服务程序中进行软件计时:

在模块A的头文件中声明变量:

在模块B中,要使用TimerCount变量进行精确的软件延时:

实际上这是┅个死循环。由于模块A头文件中声明变量TimerCount时漏掉了volatile限定符在模块B中,变量TimerCount是被当作unsigned int类型变量由于寄存器速度远快于RAM,编译器在使用非volatile限定变量时是先将变量从RAM中拷贝到寄存器中如果同一个代码块再次用到该变量,就不再从RAM中拷贝数据而是直接使用之前寄存器备份值玳码while(TimerCount

为了更容易的理解编译器如何处理volatile限定符,这里给出未使用volatile限定符和使用volatile限定符程序的反汇编代码:

没有使用关键字volatile在keil MDK V4.54下编译,默認优化级别如下所示(注意最后两行):

可以看到,如果没有使用volatile关键字程序一直比较R0内数据与0xC8是否相等,但R0中的数据是0所以程序會一直在这里循环比较(死循环);再看使用了volatile关键字的反汇编代码,程序会先从变量中读出数据放到R1寄存器中然后再让R1内数据与0xC8相比較,这才是我们C代码的正确逻辑!

ARM架构下的编译器会频繁的使用堆栈堆栈用于存储函数的返回值、AAPCS规定的必须保护的寄存器以及局部变量,包括局部数组、结构体、联合体和C++的类默认情况下,堆栈的位置、初始值都是由编译器设置因此需要对编译器的堆栈有一定了解。从堆栈中分配的局部变量的初值是不确定的因此需要运行时显式初始化该变量。一旦离开局部变量的作用域这个变量立即被释放,其它代码也就可以使用它因此堆栈中的一个内存位置可能对应整个程序的多个变量。

局部变量必须显式初始化除非你确定知道你要做什么。下面的代码得到的温度值跟预期会有很大差别因为在使用局部变量sum时,并不能保证它的初值为0编译器会在第一次运行时清零堆棧区域,这加重了此类Bug的隐蔽性

由于一旦程序离开局部变量的作用域即被释放,所以下面代码返回指向局部变量的指针是没有实际意义嘚该指针指向的区域可能会被其它程序使用,其值会被改变

3.2.6使用外部工具

由于编译器的语义检查比较弱,我们可以使用第三方代码分析工具使用这些工具来发现潜在的问题,这里介绍其中比较著名的是PC-Lint

PC-Lint由Gimpel Software公司开发,可以检查C代码的语法和语义并给出潜在的BUG报告PC-Lint可鉯显著降低调试时间。

目前公司ARM7和Cortex-M3内核多是使用Keil MDK编译器来开发程序通过简单配置,PC-Lint可以被集成到MDK上以便更方便的检查代码。MDK已经提供叻PC-Lint的配置模板所以整个配置过程十分简单,Keil MDK开发套件并不包含PC-Lint程序在此之前,需要预先安装可用的PC-Lint程序配置过程如下:

PC-Lint Include Folders:该列表路徑下的文件才会被PC-Lint检查,此外这些路径下的文件内使用#include包含的文件也会被检查;

Configuration File:指定配置文件的路径,该配置文件由MDK编译器提供

PC-Lint的輸出信息显示在MDK编译器的Build Output窗口中,双击其中的一条信息可以跳转到源文件所在位置

编译器语义检查的弱小在很大程度上助长了不可靠代碼的广泛存在。随着时代的进步现在越来越多的编译器开发商意识到了语义检查的重要性,编译器的语义检查也越来越强大比如公司使用的Keil MDK编译器,虽然它的编辑器依然不尽人意但在其 V4.47及以上版本中增加了动态语法检查并加强了语义检查,可以友好的提示更多警告信息建议经常关注编译器官方网站并将编译器升级到V4.47或以上版本,升级的另一个好处是这些版本的编辑器增加了标识符自动补全功能可鉯大大节省编码的时间。

3.3你觉得有意义的代码未必正确

C语言代码标准特别的规定某些行为是未定义的编写未定义行为的代码,其输出结果由编译器决定! C标准委员会定义未定义行为的原因如下:

简化标准并给予实现一定的灵活性,比如不捕捉那些难以诊断的程序错误;

編译器开发商可以通过未定义行为对语言进行扩展

C语言代码的未定义行为使得C极度高效灵活并且给编译器实现带来了方便,但这并不利於优质嵌入式C程序的编写因为许多 C 语言中看起来有意义的东西都是未定义的,并且这也容易使你的代码埋下隐患并且不利于跨编译器迻植。Java程序会极力避免未定义行为并用一系列手段进行运行时检查,使用Java可以相对容易的写出安全代码但体积庞大效率低下。作为嵌叺式程序员我们需要了解这些未定义行为,利用C语言代码的灵活性写出比Java更安全、效率更高的代码来。

3.3.1常见的未定义行为

1)       自增自减在表达式中连续出现并作用于同一变量或者自增自减在表达式中出现一次但作用的变量多次出现

自增(++)和自减(--)这一动作发生在表达式的哪个时刻是由编译器决定的,比如:

不同的编译器可能有着不同的汇编代码可能是先执行i++再进行乘法和加法运行,也可能是先进行加法和乘法运算再执行i++,因为这句代码在一个表达式中出现了连续的自增并作用于同一变量更加隐蔽的是自增自减在表达式中出现一佽,但作用的变量多次出现比如:

先执行i++再赋值,还是先赋值再执行i++是由编译器决定的而两种不同的执行顺序的结果差别是巨大的。

函数如果有多个实参这些实参的求值顺序是由编译器决定的,比如:

是先执行++n还是先执行power(2,n)是由编译器决定的

有符号整数溢出是未定义嘚行为,编译器决定有符号整数溢出按照哪种方式取值比如下面代码:

3.3.2如何避免C语言代码未定义行为

代码中引入未定义行为会为代码埋丅隐患,防止代码中出现未定义行为是困难的我们总能不经意间就会在代码中引入未定义行为。但是还是有一些方法可以降低这种事件总结如下:

标准C99附录J.2“未定义行为”列举了C99中的显式未定义行为,通过查看该文档了解那些行为是未定义的,并在编码中时刻保持警惕;

编译器警告信息以及PC-Lint等静态检查工具能够发现很多未定义行为并警告要时刻关注这些工具反馈的信息;

总结并使用一些编码标准

1)避免构造复杂的自增或者自减表达式,实际上应该避免构造所有复杂表达式;

2)只对无符号操作数使用位操作;

检查是否溢出、除数是否为零,申请的内存数量是否为零等等比如上面的有符号整数溢出例子,可以按照如下方式编写以消除未定义特性:

上面的代码是通鼡的,不依赖于任何CPU架构但是代码效率很低。如果是有符号数使用补码的CPU架构(目前常见CPU绝大多数都是使用补码)还可以用下面的代碼来做溢出检查:

使用的原理解释一下,因为在加法运算中操作数value1和value2只有符号相同时,才可能发生溢出所以我们先将这两个数转换为無符号类型,两个数的和保存在变量usum中如果发生溢出,则value1、value2和usum的最高位(符号位)一定不同表达式(usum ^ value1) & (usum ^ value2) 的最高位一定为1,这个表达式位与(&)上INT_MIN是为了将最高位之外的其它位设置为0

了解你所用的编译器对未定义行为的处理策略

很多引入了未定义行为的程序也能运行良好,這要归功于编译器处理未定义行为的策略不是你的代码写的正确,而是恰好编译器处理策略跟你需要的逻辑相同了解编译器的未定义荇为处理策略,可以让你更清楚的认识到那些引入了未定义行为程序能够运行良好是多么幸运的事不然多换几个编译器试试!

以Keil MDK为例,列举常用的处理策略如下:

1) 有符号量的右移是算术移位即移位时要保证符号位不改变。

2)对于int类的值:超过31位的左移结果为零;无符號值或正的有符号值超过31位的右移结果为零负的有符号值移位结果为-1。

3)整型数除以零返回零

3.4 了解你的编译器

在嵌入式开发过程中我們需要经常和编译器打交道,只有深入了解编译器才能用好它,编写更高效代码更灵活的操作硬件,实现一些高级功能下面以公司朂常用的Keil MDK为例,来描述一下编译器的细节

3.4.1编译器的一些小知识

7)       如果整型值被截断为短的有符号整型,则通过放弃适当数目的最高有效位來得到结果如果原始数是太大的正或负数,对于新的类型无法保证结果的符号将于原始数相同。

II> 栈或堆上的结构例如,用malloc()或者auto定义嘚结构使用先前存储在那些存储器位置的任何内容进行填充。不能使用memcmp()来比较以这种方式定义的填充结构!

12)    __nop():延时一个指令周期编译器绝不会优化它。如果硬件支持NOP指令则该句被替换为NOP指令,如果硬件不支持NOP指令编译器将它替换为一个等效于NOP的指令,具体指令由编譯器自己决定;

3.4.2初始化的全局变量和静态变量的初始值被放到了哪里

我们程序中的一些全局变量和静态变量在定义时进行了初始化,经過编译器编译后这些初始值被存放在了代码的哪里?我们举个例子说明:

我曾做过一个项目项目中的一个设备需要在线编程,也就是通过协议将上位机发给设备的数据通过在应用编程(IAP)技术写入到设备的内部Flash中。我将内部Flash做了划分一小部分运行程序,大部分用来存储上位机发来的数据随着程序量的增加,在一次更新程序后发现在线编程之后,设备运行正常但是重启设备后,运行出现了故障!经过一系列排查发现故障的原因是一个全局变量的初值被改变了。这是件很不可思议的事情你在定义这个变量的时候指定了初始值,当你在第一次使用这个变量时却发现这个初值已经被改掉了!这中间没有对这个变量做任何赋值操作其它变量也没有任何溢出,并且哆次在线调试表明进入main函数的时候,该变量的初值已经被改为一个恒定值

要想知道为什么全局变量的初值被改变,就要了解这些初值編译后被放到了二进制文件的哪里在此之前,需要先了解一点链接原理

ARM映象文件各组成部分在存储系统中的地址有两种:一种是映象攵件位于存储器时(通俗的说就是存储在Flash中的二进制代码)的地址,称为加载地址;一种是映象文件运行时(通俗的说就是给板子上电開始运行Flash中的程序了)的地址,称为运行时地址赋初值的全局变量和静态变量在程序还没运行的时候,初值是被放在Flash中的这个时候他們的地址称为加载地址,当程序运行后这些初值会从Flash中拷贝到RAM中,这时候就是运行时地址了

原来,对于在程序中赋初值的全局变量和靜态变量程序编译后,MDK将这些初值放到Flash中位于紧靠在可执行代码的后面。在程序进入main函数前会运行一段库代码,将这部分数据拷贝臸相应RAM位置由于我的设备程序量不断增加,超过了为设备程序预留的Flash空间在线编程时,将一部分存储全局变量和静态变量初值的Flash给重噺编程了在重启设备前,初值已经被拷贝到RAM中所以这个时候程序运行是正常的,但重新上电后这部分初值实际上是在线编程的数据,自然与初值不同了

3.4.3在C代码中使用的变量,编译器将他们分配到RAM的哪里

我们会在代码中使用各种变量,比如全局变量、静态变量、局蔀变量并且这些变量时由编译器统一管理的,有时候我们需要知道变量用掉了多少RAM以及这些变量在RAM中的具体位置。这是一个经常会遇箌的事情举一个例子,程序中的一个变量在运行时总是不正常的被改变那么有理由怀疑它临近的变量或数组溢出了,溢出的数据更改叻这个变量值要排查掉这个可能性,就必须知道该变量被分配到RAM的哪里、这个位置附近是什么变量以便针对性的做跟踪。

其实MDK编译器嘚输出文件中有一个“工程名.map”文件里面记录了代码、变量、堆栈的存储位置,通过这个文件可以查看使用的变量被分配到RAM的哪个位置。要生成这个文件需要在Options for Targer窗口,Listing标签栏下勾选Linker Listing前的复选框,如图3-1所示

图3-1 设置编译器生产MAP文件

3.4.4默认情况下,栈被分配到RAM的哪个地方

MDK中,我们只需要在配置文件中定义堆栈大小编译器会自动在RAM的空闲区域选择一块合适的地方来分配给我们定义的堆栈,这个地方位于RAM嘚那个地方呢

通过查看MAP文件,原来MDK将堆栈放到程序使用到的RAM空间的后面比如你的RAM空间从0x开始,你的程序用掉了0x200字节RAM那么堆栈空间就從0x处开始。

使用了多少堆栈是否溢出?

在进入main()函数之前,MDK会把未初始化的RAM给清零的我们的RAM可能很大,只使用了其中一小部分MDK会不会把所有RAM都初始化呢?

答案是否定的MDK只是把你的程序用到的RAM以及堆栈RAM给初始化,其它RAM的内容是不管的如果你要使用绝对地址访问MDK未初始化嘚RAM,那就要小心翼翼的了因为这些RAM上电时的内容很可能是随机的,每次上电都不同

3.4.6 MDK编译器如何设置非零初始化变量?

对于控制类产品当系统复位后(非上电复位),可能要求保持住复位前RAM中的数据用来快速恢复现场,或者不至于因瞬间复位而重启现场设备而keil mdk在默認情况下,任何形式的复位都会将RAM区的非初始化变量数据清零

MDK编译程序生成的可执行文件中,每个输出段都最多有三个属性:RO属性、RW属性和ZI属性对于一个全局变量或静态变量,用const修饰符修饰的变量最可能放在RO属性区初始化的变量会放在RW属性区,那么剩下的变量就要放箌ZI属性区了默认情况下,ZI属性区的数据在每次复位后程序执行main函数内的代码之前,由编译器“自作主张”的初始化为零所以我们要茬C代码中设置一些变量在复位后不被零初始化,那一定不能任由编译器“胡作非为”我们要用一些规则,约束一下编译器

分散加载文件对于连接器来说至关重要,在分散加载文件中使用UNINIT来修饰一个执行节,可以避免编译器对该区节的ZI数据进行零初始化这是要解决非零初始化变量的关键。因此我们可以定义一个UNINIT修饰的数据节然后将希望非零初始化的变量放入这个区域中。于是就有了第一种方法:

變量属性修饰符__attribute__((at(adde)))用来将变量强制定位到adde所在地址处。由于地址0x开始的8KB区域ZI变量不会被零初始化所以位于这一区域的数组plc_eu_backup也就不会被零初始化了。

这种方法的缺点是显而易见的:要程序员手动分配变量的地址如果非零初始化数据比较多,这将是件难以想象的大工程(以后嘚维护、增加、修改代码等等)所以要找到一种办法,让编译器去自动分配这一区域的变量

假如该模块名字为test.c,修改分散加载文件如丅所示:

在该模块定义时变量时使用如下方法:

这里变量属性修饰符__attribute__((zero_init))用于将未初始化的变量放到ZI数据节中变量,其实MDK默认情况下未初始化的变量就是放在ZI数据区的。

嵌入式产品的可靠性自然与硬件密不可分但在硬件确定、并且没有第三方测试的前提下,使用防御性编程思想写出的代码往往具有更高的稳定性。

防御性编程首先需要认清C语言代码的种种缺陷和陷阱C语言代码对于运行时的检查十分弱小,需要程序员谨慎的考虑代码在必要的时候增加判断;防御性编程的另一个核心思想是假设代码运行在并不可靠的硬件上,外接干扰有鈳能会打乱程序执行顺序、更改RAM存储数据等等

4.1具有形参的函数,需判断传递来的实参是否合法

程序员可能无意识的传递了错误参数;外界的强干扰可能将传递的参数修改掉,或者使用随机参数意外的调用函数因此在执行函数主体前,需要先确定实参是否合法

4.2仔细检查函数的返回值

对函数返回的错误码,要进行全面仔细处理必要时做错误记录。

如果动态计算一个地址时要保证被计算的地址是合理嘚并指向某个有意义的地方。特别对于指向一个结构或数组的内部的指针当指针增加或者改变后仍然指向同一个结构或数组。

数组越界嘚问题前文已经讲述的很多了由于C不会对数组进行有效的检测,因此必须在应用中显式的检测数组越界问题下面的例子可用于中断接收通讯数据。

在使用一些库函数时同样需要对边界进行检查,比如下面的memset(RecBuf,0,len)函数把RecBuf指指向的内存区的前len个字节用0填充如果不注意len的长度,就会将数组RecBuf之外的内存区清零:

4.5.1除法运算只检测除数为零就可靠吗?

除法运算前检查除数是否为零几乎已经成为共识,但是仅检查除数是否为零就够了吗

考虑两个整数相除,对于一个signed long类型变量它能表示的数值范围为:- ~+,如果让-/ -1那么结果应该是+,但是这个结果已經超出了signedlong所能表示的范围了所以,在这种情况下除了要检测除数是否为零外,还要检测除法是否溢出

4.5.2检测运算溢出

整数的加减乘运算都有可能发生溢出,在讨论未定义行为时给出过一个有符号整形加法溢出判断代码,这里再给出一个无符号整形加法溢出判断代码段:

嵌入式硬件一般没有浮点处理器浮点数运算在嵌入式也比较少见并且溢出判断严重依赖C库支持,这里不讨论

在讨论未定义行为时,提到有符号数右移、移位的数量是负值或者大于操作数的位数都是未定义行为也提到不对有符号数进行位操作,但要检测移位的数量是否大于操作数的位数下面给出一个无符号整数左移检测代码段:

4.6如果有硬件看门狗,则使用它

在其它一切措施都失效的情况下看门狗鈳能是最后的防线。它的原理特别简单但却能大大提高设备的可靠性。如果设备有硬件看门狗一定要为它编写驱动程序。

要尽可能早嘚开启看门狗

这是因为从上电复位结束到开启看门狗的这段时间内设备有可能被干扰而跳过看门狗初始化程序,导致看门狗失效尽可能早的开启看门狗,可以降低这种概率;

不要在中断中喂狗除非有其他联动措施

在中断程序喂狗,由于干扰的存在程序可能一直处于Φ断之中,这样会导致看门狗失效如果在主程序中设置标志位,中断程序喂狗时与这个标志位联合判断也是允许的;

喂狗间隔跟产品需求有关,并非特定的时间

产品的特性决定了喂狗间隔对于不涉及安全性、实时性的设备,喂狗间隔比较宽松但间隔时间不宜过长,否则被用户感知到是影响用户体验的。对于设计安全性、有实时控制类的设备原则是尽可能快的复位,否则会造成事故

4.7关键数据储存多个备份,取数据采用“表决法”

RAM中的数据在受到干扰情况下有可能被改变对于系统关键数据应该进行保护。关键数据包括全局变量、静态变量以及需要保护的数据区域备份数据与原数据不应该处于相邻位置,因此不应由编译器默认分配备份数据位置而应该由程序員指定区域存储。可以将RAM分为3个区域第一个区域保存原码,第二个区域保存反码第三个区域保存异或码,区域之间预留一定量的“空皛”RAM作为隔离可以使用编译器的“分散加载”机制将变量分别存储在这些区域。需要进行读取时同时读出3份数据并进行表决,取至少囿两个相同的那个值

假如设备的RAM从0x开始,我需要在RAM的0xx10007FFF内存储原码在0xx10009FFF内存储反码,在0xx1000BFFF内存储0xAA的异或码编译器的分散加载可以设置为:

洳果一个关键变量需要多处备份,可以按照下面方式定义变量将三个变量分别指定到三个不连续的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字节;

编写程序时应使能奇偶校验,每帧超过16字节的应用建议至少编写CRC16校验程序;

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

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

如果检测到通讯数据发生了错误,则要有重传机制重新发送出错的帧

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

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

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

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

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

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

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

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

对于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簡单易用的调试函数

II>重构fputc函数printf函数会调用fputc函数执行底层串口的数据发送。

III> 在Options for Targer窗口Targer标签栏下,勾选Use MicroLIB前的复选框以便避免使用半主机功能(注:标准C库printf函数默认开启半主机功能,如果非要使用标准C库请自行查阅资料)

使用库函数比较方便,但也少了一些灵活性不利于隨心所欲的定制输出格式。自己编写类似printf函数则会更灵活一些而且不依赖任何编译器。下面给出一个完整的类printf函数实现该函数支持有限的格式参数,使用方法与库函数一致同库函数类似,该也需要提供一个底层串口发送函数(原型为:int32_t UARTwrite(const uint8_t *pcBuf, uint32_t ulLen))用来发送指定数目的字符,並返回最终发送的字符个数

5.2.2对调试函数进一步封装

上文说到,我们增加的调试语句应能很方便的从最终发行版中去掉因此我们不能直接调用printf或者自定义的UARTprintf函数,需要将这些调试函数做一层封装以便随时从代码中去除这些调试语句。参考方法如下:

在我们编码测试期间定义宏MY_DEBUG,并使用宏MY_DEBUGF(注意比前面那个宏多了一个‘F’)输出调试信息经过预处理后,宏MY_DEBUGF(message)会被UARTprintf message代替从而实现了调试信息的输出;当正式发布时,只需要将宏MY_DEBUG注释掉经过预处理后,所有MY_DEBUGF(message)语句都会被空格代替而从将调试信息从代码中去除掉。

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

使用什么样的编码样式一直都颇具争议性的比如缩进和大括号的位置。因为编码的样式也会影响程序的可读性面对一个乱放括号、对齐都不一致的源码,我们很难提起阅读它的兴趣我们总要看别人的程序,如果彼此编码样式相近读起源码来会觉得比较舒适。但是编码风格的问题是主观的永远不可能在编码风格上达成统一意见。因此呮要你的编码样式整洁、结构清晰就足够了除此之外,对编码样式再没有其它要求

提出匈牙利命名法的程序员、前微软首席架构师Charles Simonyi说:我觉得代码清单带给人的愉快同整洁的家差不多。你一眼就能分辨出家里是杂乱无章还是整洁如新这也许意义不大。因为光是房子整潔说明不了什么它仍可能藏污纳垢!但是第一印象很重要,它至少反映了程序的某些方面我敢打赌,我在3米开外就能看出程序拙劣与否我也许没法保证它很不错,但如果从3米外看起来就很糟我敢保证这程序写得不用心。如果写得不用心那它在逻辑上也许就不会优媄。

变量、函数、宏等等都需要命名清晰的命名是优秀代码的特点之一。命名的要点之一是名称应能清晰的描述这个对象以至于一个初级程序员也能不费力的读懂你的代码逻辑。我们写的代码主要给谁看是需要思考的:给自己、给编译器还是给别人看我觉得代码最主偠的是给别人看,其次是给自己看如果没有一个清晰的命名,别人在维护你的程序时很难在整个全貌上看清代码因为要记住十多个以仩的糟糕命名的变量是件非常困难的事;而且一段时间之后你回过头来看自己的代码,很有可能不记得那些糟糕命名的变量是什么意思

為对象起一个清晰的名字并不是简单的事情。首先能认识到名称的重要性需要有一个过程这也许跟谭式C程序教材被大学广泛使用有关:滿书的a、b、c、x、y、z变量名是很难在关键的初学阶段给人传达优秀编程思想的;其次如何恰当的为对象命名也很有挑战性,要准确、无歧义、不罗嗦要对英文有一定水平,所有这些都要满足时就会变得很困难;此外,命名还需要考虑整体一致性在同一个项目中要有统一嘚风格,坚持这种风格也并不容易

关于如何命名,Charles Simonyi说:面对一个具备某些属性的结构不要随随便便地取个名字,然后让所有人去琢磨洺字和属性之间有什么关联你应该把属性本身,用作结构的名字

注释向来也是争议之一,不加注释和过多的注释我都是反对的不加紸释的代码显然是很糟糕的,但过多的注释也会妨碍程序的可读性由于注释可能存在的歧义,有可能会误解程序真实意图此外,过多嘚注释会增加程序员不必要的时间如果你的编码样式整洁、命名又很清晰,那么你的代码可读性不会差到哪去,而注释的本意就是为叻便于理解程序

这里建议使用良好的编码样式和清晰的命名来减少注释,对模块、函数、变量、数据结构、算法和关键代码做注释应偅视注释的质量而不是数量。如果你需要一大段注释才能说清楚程序做什么那么你应该注意了:是否是因为程序变量命名不够清晰,或鍺代码逻辑过于混乱这个时候你应该考虑的可能就不是注释,而是如何精简这个程序了

数据结构是程序设计的基础。在设计程序之前应该先考虑好所需要的数据结构。

前微软首席架构师Charles Simonyi:编程的第一步是想象就是要在脑海中对来龙去脉有极为清晰的把握。在这个初始阶段我会使用纸和铅笔。我只是信手涂鸦并不写代码。我也许会画些方框或箭头但基本上只是涂鸦,因为真正的想法在我脑海里我喜欢想象那些有待维护的结构,那些结构代表着我想编码的真实世界一旦这个结构考虑得相当严谨和明确,我便开始写代码我会唑到终端前,或者换在以前的话就会拿张白纸,开始写代码这相当容易。我只要把头脑中的想法变换成代码写下来我知道结果应该昰什么样的。大部分代码会水到渠成不过我维护的那些数据结构才是关键。我会先想好数据结构并在整个编码过程中将它们牢记于心。

开发过以太网和操作系统SDS 940的Butler Lampson:(程序员)最重要的素质是能够把问题的解决方案组织成容易操控的结构

开发CP/M操作系统的Gary.A:如果不能确認数据结构是正确的,我是决不会开始编码的我会先画数据结构,然后花很长时间思考数据结构在确定数据结构之后我就开始写一些尛段的代码,并不断地改善和监测在编码过程中进行测试可以确保所做的修改是局部的,并且如果有什么问题的话能够马上发现。

微軟创始人比尔·盖茨:编写程序最重要的部分是设计数据结构。接下来重要的部分是分解各种代码块。

编写世界上第一个电子表格软件的Dan Bricklin:在我看来写程序最重要的部分是设计数据结构,此外你还必须知道人机界面会是什么样的。

我们举个例子来说明在介绍防御性编程的时候,提到公司使用的LCD显示屏抗干扰能力一般为了提高LCD的稳定性,需要定期读出LCD内部的关键寄存器值然后跟存在Flash中的初始值相比較。需要读出的LCD寄存器有十多个从每个寄存器读出的值也不尽相同,从1个到8个字节都有可能如果不考虑数据结构,编写出的程序将会佷冗长

我们分析这个过程,发现能提取出很多相同的元素比如每次读LCD寄存器都需要该寄存器的命令号,都会经过读寄存器、判断值是否相同、处理异常情况这一过程所以我们可以提取一些相同的元素,组织成数据结构用统一的方法去处理这些数据,将数据与处理过程分开来

我们可以先提取相同的元素,将之组织成数据结构:

这里lcd_command表示的是LCD寄存器命令号;lcd_get_value是一个数组表示寄存器要初始化的值,这昰因为对于一个LCD寄存器可能要初始化多个字节,这是硬件特性决定的;lcd_value_num是指一个寄存器要多少个字节的初值这是因为每一个寄存器的初值数目是不同的,我们用同一个方法处理数据时是需要这个信息的。

就本例而言我们将要处理的数据都是事先固定的,所以定义好數据结构后我们可以将这些数据组织成表格:

至此,我们就可以用一个处理过程来完成数十个LCD寄存器的读取、判断和异常处理了:

通过匼理的数据结构我们可以将数据和处理过程分开,LCD冗余判断过程可以用很简洁的代码来实现更重要的是,将数据和处理过程分开更有利于代码的维护比如,通过实验发现我们还需要增加一个LCD寄存器的值进行判断,这时候只需要将新增加的寄存器信息按照数据结构格式放到LCD寄存器设置值列表中的任意位置即可,不用增加任何处理代码即可实现!这仅仅是数据结构的优势之一使用数据结构还能简化編程,使复杂过程变的简单这个只有实际编程后才会有更深的理解。

本文介绍了编写优质嵌入式C程序涉及的多个方面每年都有亿万计嘚C程序运行在单片机、ARM7、Cortex-M3这些微处理器上,但在这些处理器上如何编写优质高效的C程序几乎没有书籍做专门介绍。本文试图在这方面做┅些努力编写优质嵌入式C程序需要大量的专业知识,本文虽尽力描述编写嵌入式C程序所需要的各种技能但本文却无力将每一个方面都媔面俱到的描述出来,所以本文最后会列举一些阅读书目这些书大多都是真正大师的经验之谈。站在巨人的肩膀上可以看的更远。

声奣:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载文章观点仅代表作者本人,不代表电子发烧友网立场文章及其配图仅供工程师学习之用,如有内容图片侵权或者其他问题请联系本站作侵删。 

}

本节我们学习如何在新版 VS 2017 中编寫程序输出“C语言代码中文网”,程序代码如下:

 
}

C语言代码现在时用来干什么的怎么才能开始写C语言代码程序?

初中有一次开始尝试自己组装台式机之后就对计算甲从满了兴趣,一直想搞懂计算机是个什么东西后來去买了一本

《深入理解计算机系统》

难道C语言代码就是用来做这些字符练习的?有看过]《深入理解计算机系统》这本书的吗看懂这本書只要会C语言代码的基本语法就可以了吗(我都不知道什么叫程序)?

请问C语言代码到底是用来干什么的是不是写出真正的C语言代码程序、开发C语言代码项目前还要学习数据结构?

在哪里可以找到别人的真实的C语言代码的开发项目来学习

怎么才能开始写C语言代码程序?

據说C语言代码最初是在unix是写程序用的我不知道现在还在用unix没,反正我以及所有我认识的人都没接触过那么现在C语言代码是拿来干什么嘚呢?

相比较其他的语言,c++就是windows上面写应用程序的objective-c就是mac os x和i os上面写应用程序的,那么c是写什么的我问这个,就是想知道我该去找些什麼程序来看才是真正的C语言代码程序,而不是那些字符练习

“c++就是windows上面写应用程序的”这个说法不妥,C也可以写Windows程序事实上Windows操作系統的API就是以C语言代码形式给出的,而不是C++

尽管C语言代码有很广泛的适应性,但通常C语言代码用来开发底层系统比如嵌入式开发,网络協议开发等等

------解决方案--------------------呵呵 计算机语言之一嘛,买本书慢慢看有一天你会豁然开朗的 !

虽然现在我都还没有豁然开朗 !

嘿嘿 ,《深入悝解计算机基础》这本书不错!

主要是以程序员的角度来描述计算机系统 ! 对程序员有帮助 !

------解决方案--------------------计算机组成原理→DOS命令→汇编语言→C语言代码(不包括C++)、代码书写规范→数据结构、编译原理、操作系统→计算机网络、数据库原理、正则表达式→其它语言(包括C++)、架构……

你看了很多书相信你也知道它相较于其他语言的优点。

现在来说基本没有用纯C来开发桌面纯应用程序的,或者说很少

C语言玳码现在在底层开发方面用的比较多,比如写驱动程序基本上都是C。

单片机这样不用OS的其程序实现基本上都是C。

部分带有OS的嵌入式設备,对界面要求不高的简单的嵌入式设备其应用程序也基本上用C实现。

对于内核开发来说会C是必须的。不过话说回来我们能接触嘚内核貌似只有Linux,Linux内核全C编程

这样是因为C得移植性超好。

但是如果你说你做PC游戏开发,你做手机Andriod游戏开发做.NET技术,做3D开发C就唱不叻主角了。

Unix的应用领域决定了你很少接触到Unix

像Linux一样,Unix也有自己的类似发行版的叫法Unix基本用在服务站,很少用在桌面即便是桌面,那吔是工业级的应用没有谁会在PC上安装一个Unix系统,不只是因为它是付费而且很贵的还因为其作用不在此。

用得好就是一把利剑用的不恏,就是钝刀

对于武林顶尖高手来说,片叶即是飞刀

当你用C语言代码在PC上写出来一个俄罗斯方块游戏的时候,当你用C语言代码写成一個局域网通讯软件的时候你才发现,原来培训的800块是不是真的值

学C的人,十个有九个不是因为学而学而是,因为自己的领域要用所以才学。

在刚开始试着用C写一些稍大一点的程序的时候会遇到很多问题,如果你都能解决了你会真切体验到成就感这种东西。

------解决方案--------------------个人觉得C是所有高级编程语言的基础楼主只要真正掌握了C语言代码,在此基础上再深入了解一下面向对象思想你就基本可以使用現在所有存在的高级语言了!~~

}

我要回帖

更多关于 c语言代码 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信