📄 单片机汇编程序编码规范.htm
字号:
<P> 规则2<BR> 每个函数的源程序行数原则上应该少于200行。<BR> 对于消息分流处理函数,完成的功能统一,但由于消息的种类多,可能超过200行的限制,不属于违反规定。</P>
<P> 规则3<BR> 语句嵌套层次不得超过5层。<BR> 嵌套层次太多,增加了代码的复杂度及测试的难度,容易出错,增加代码维护的难度。</P>
<P> 规则4<BR> 避免相同的代码段在多个地方出现。<BR> 当某段代码需在不同的地方重复使用时,应根据代码段的规模大小使用函数调用或宏调用的方式代替。这样,对该代码段的修改就可在一处完成,增强代码的可维护性。</P>
<P> 规则5<BR> 每个函数完成单一的功能,不设计多用途面面俱到的函数。<BR> 多功能集于一身的函数,很可能使函数的理解、测试、维护等变得困难。使函数功能明确化,增加程序可读性,亦可方便维护、测试。</P>
<P> 规则6<BR> 在函数的项目维护文档中,应该指出软件适用的硬件平台及版本。</P>
<P><BR> 建议1<BR> 使用专门的初始化函数对所有的公共变量进行初始化。</P>
<P><BR> 5.程序正确性、效率<BR> 规则1<BR> 严禁使用未经初始化的变量。<BR> 引用未经初始化的变量可能会产生不可预知的后果,特别是引用未经初始化的指针经常会导致系统崩溃,需特别注意。</P>
<P> 规则2<BR> 防止内存操作越界。<BR> 说明:内存操作越界是软件系统主要错误之一,后果往往非常严重。</P>
<P> 规则3<BR> 注意变量的有效取值范围,防止表达式出现上溢或下溢。</P>
<P> 规则4<BR> 防止易混淆的指令和操作数拼写错误。</P>
<P> 规则5<BR> 避免函数中不必要语句,防止程序中的垃圾代码,预留代码应以注释的方式出现。<BR> 程序中的垃圾代码不仅占用额外的空间,而且还常常影响程序的功能与性能,很可能给程序的测试、维护等造成不必要的麻烦。</P>
<P> 规则6<BR> 通过对系统数据结构的划分与组织的改进,以及对程序算法的优化来提高空间效率。<BR> 这种方式是解决软件空间效率的根本办法。</P>
<P> 规则7<BR> 循环体内工作量最小化。<BR> 应仔细考虑循环体内的语句是否可以放在循环体之外,使循环体内工作量最小,从而提高程序的时间效率。</P>
<P> 规则8<BR> 在多重循环中,应将最忙的循环放在最内层。</P>
<P> 规则9<BR> 避免循环体内含判断语句,将与循环变量无关的判断语句移到循环体外。<BR> 目的是减少判断次数。循环体中的判断语句是否可以移到循环体外,要视程序的具体情况而言,一般情况,与循环变量无关的判断语句可以移到循环体外,而有关的则不可以。</P>
<P> 规则10<BR> 中断和恢复<BR> 中断程序应该尽量短,应该在中断中进行标记,在主程序中处理。但实时性很高的程序段例外。<BR> 中断时应该保存所有涉及到的通用变量和寄存器,如A, PSW, DPTR等。</P>
<P> 规则11 <BR> 堆栈设置<BR> 堆栈对于程序非常重要,对于堆栈的设置要合理。堆栈太小,在嵌套调用和很容易溢出,造成系统故障;堆栈太大,浪费RAM资源。<BR> 为了节约堆栈资源,中断时要求不要保存太多资源,中断嵌套和程序嵌套层数不要太多,尽量不要超过5层。这就要求合理的划分功能模块。</P>
<P> 规则12<BR> 看门狗<BR> 看门狗电路用于在单片机死机时自动复位。单片机需要定时向看门狗发送脉冲,俗称”喂狗”。喂狗不可太勤,这样看门狗没有起到作用;也不可太慢,这样容易造成单片机复位。正确的喂狗应该在主循环中进行,最好是建立一个独立的系统监控进程。不可以在定时中断中喂狗,应为单片机有时可能会在主循环中死掉。</P>
<P><BR> 6.接口<BR> 规则1<BR> 去掉没有必要的公共变量,编程时应尽量少用公共变量。<BR> 公共变量是增大模块间耦合的原因之一,故应减少没必要的公共变量以降低模块间的耦合度。应该构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象。</P>
<P> 规则2<BR> 当向公共变量传递数据时,要防止越界现象发生。<BR> 对公共变量赋值时,若有必要应进行合法性检查,以提高代码的可靠性、稳定性。</P>
<P> 规则3<BR> 尽量不设计多参数函数,将不使用的参数从接口中去掉,降低接口复杂度,减少函数间接口的复杂度。</P>
<P> 规则4<BR> 对所调用函数的返回码要仔细、全面地处理。<BR> 防止把错误传递到后面的处理流程。如有意不检查其返回码,应明确指明。</P>
<P> 规则5<BR> 检查接口函数所有输入参数的有效性。</P>
<P> 规则6<BR> 检查函数的所有非参数输入,如外部数据、公共变量等。</P>
<P><BR> 7.代码可测性<BR> 规则1<BR> 模块编写应该有完善的测试方面的考虑。</P>
<P> 规则2<BR> 源代码中应该设计了代码测试的内容。<BR> 在编写代码之前,应预先设计好程序调试与测试的方法和手段,并设计好各种调测开关及相应测试代码。<BR> 程序的调试与测试是软件生存周期中很重要的一个阶段,如何对软件进行较全面、高率的测试并尽可能地找出软件中的错误就成为很关键的问题。因此在编写源代码之前,除了要有一套比较完善的测试计划外,还应设计出一系列代码测试手段,为单元测试、集成测试及系统联调提供方便。</P>
<P> 规则3<BR> 在同一项目组或产品组内,要有一套统一的为集成测试与系统联调准备的调测开关及相应函数,并且要有详细的说明。本规则是针对项目组或产品组的。</P>
<P> 规则4<BR> 在同一项目组或产品组内,调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名(或源文件名)及行号。<BR> 统一的调测信息格式便于集成测试。</P>
<P> 规则5<BR> 正式软件产品中应把调测代码去掉(即把有关的调测开关关掉)。</P>
<P> 规则6<BR> 用调测开关来切换软件的DEBUG版和正式版,而不要同时存在正式版本和DEBUG版本的不同源文件,以减少维护的难度。</P>
<P> 规则7<BR> 在软件系统中设置与取消有关测试手段,不能对软件实现的功能等产生影响。<BR> 即有测试代码的软件和关掉测试代码的软件,在功能行为上应一致。</P>
<P> 规则8<BR> 发现错误应该立即修改,并且若有必要记录下来。</P>
<P> 规则9<BR> 开发人员应坚持对代码进行彻底的测试(单元测试),而不依靠他人或测试组来发现问题。</P>
<P> 规则10<BR> 清理、整理或优化后的代码要经过审查及测试。</P>
<P> 规则11<BR> 代码版本升级要经过严格测试。</P>
<P><BR> 8.代码编译<BR> 规则1<BR> 打开编译器的所有告警开关对程序进行编译。<BR> 防止隐藏可能是错误的告警。</P>
<P> 规则2<BR> 某些语句经编译后产生告警,但如果你认为它是正确的,那么应通过某种手段去掉告警信息。</P>
<P><BR> ps:从网上收集了一些相关内容,结合我自己的经验,欢迎拍砖,谢绝辱骂;<BR> ps2:有些可能不常用,因为大家写不到那么长的代码,就我自己写的最长的汇编代码也不超过10K行;</P>
<P> </P>
<P><BR> 签名:</P>
<P> ︻┳═一</P>
<P> 如有问题:<BR> 1.查有关手册、帮助文件能否解决问题?<BR> 2.到版面以关键字查旧贴或精华贴能否解决问题?<BR> 3.以关键字到google等其他搜索引擎搜索能否解决问题?<BR> 4.如果以上都没解决,欢迎发贴讨论啦~~:) </P>
<P> </P>
<P> ·---<BR> 报名Intel嵌入式解决方案网上研讨会,赢MP3</P>
<P><BR> luhuaren 发表于 2005-7-13 19:20 侃单片机 ←返回版面 </P>
<P> RE</P>
<P> 怎样让汇编语言写出的程序依旧有层次感?条理清晰,让人很容易看懂?<B
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -