单片机应用设计注意事项.docx
《单片机应用设计注意事项.docx》由会员分享,可在线阅读,更多相关《单片机应用设计注意事项.docx(10页珍藏版)》请在冰豆网上搜索。
单片机应用设计注意事项
一.单片机项目开发流程介绍
1.确定设计任务
确定待开发产品的功能、所实现的指标、成本,进行可行性分析。
这一过程要越详细越好,不要在设计的半途才发现自己还不清楚到底要设计一个怎样的产品,而且相关技术标准的考察也要详细完备,这样才能选择恰当的单片机以及外围电路,免得后来出现重大的设计失误。
另外还要估计设计的完成时间,这一步经常被忽视,许多工程师并没有仔细地研究自己将要进行的项目,而是草草开工。
2.总体设计
明确设计任务后,我们就可以进行总体方案的设计了,这时候就要根据产品功能确定需要的单片机,选择时单片机的性能要能满足设计任务,另外还要考虑到产品的功耗、使用环境等问题。
3.硬件设计
根据功能确定各部分电路。
绘制原理图及PCB图,选购元器件、焊接线路板、组装、调试。
4.软件设计
绘制流程图,进行资源分配及结构设计,确定算法及设计结构,设计、编制各子程序模块,仿真、调试,固化。
5.样机联调
软硬件结合起来调试,找错、修改软硬件,进行软硬件调试,进行老化实验;高、低温试验和振动试验。
6.送检
完成样机联调后,就要送到质检部或其他检验部门进行最后的功能和性能检验。
质检部门有可能是公司内部的也有可能是专门的组织机构。
7.产品定型
编制使用说明书,技术文件,制定生产工艺流程,形成工艺,进入小批量生产。
整个过程有可能会有反复,比如说第六步的送检没有通过,就有可能回到前面的几步,甚至是回到第一步。
二.原理图设计规范
原理图设计的基本要求是:
图纸清晰、准确、规范、易读。
1.文档相关要求
(1)按统一的要求选择图纸幅面、图框格式、电路图中的图形符号、文字符号。
(2)各功能块布局要合理,整个原理图要布局均衡。
(3)将各功能部分模块化(比如单片机部分,A/D转换部分,D/A转换部分、电源部分等),各功能模块界线要清晰,方便读图。
(4)元件标号按功能块进行标记,元器件明细表中不允许出现无型号的器件。
相同型号的元器件不允许采用不同的表示方法。
元件参数/数值要准确标记。
2.技术性质要求
(1)接插口(如电源,数据引线,接口等)尽量分布在图纸的四周,示意出实际插口外型及每一个插脚的功能。
(2)可调元件(如电位器),切换开关等对应的功能须标记清楚。
(3)每一部件(如TUNER,IC等)电源的去耦电阻/电容需置于对应插脚的就近处。
(4)滤波器件(如高/低频滤波电容,电感)需置于作用部位的就近处。
(5)重要的控制或信号线需标明流向及用文字标明功能。
(6)重要器件(如接插座,IC,TUNER等)外框用粗线(统一0.5mm)。
(7)信号完整性及电磁兼容性考虑。
三.PCB图设计规范
PCB的设计流程可分为网表输入、规则设置、元器件布局、布线、检查、复查、输出等步骤。
1.元器件布局的基本原则
●遵循先难后易、先大后小的原则。
●布局可以参考原理图的大致的布局,根据信号流向规律放置主要元器件。
●相同结构电路部分应尽可能采取对称布局。
●按照均匀分布、重心平衡、版面美观的标准来优化布局。
●同类型的元件应该在x或y方向上一致。
同一类型的有极性分立元件也要力争在x或y方向上一致,以便于生产和调试。
●元器件布局时候,使用同一种电源的元件应考虑尽量放在一起,以便于将来的电源分割。
2.电子电路性能的考虑
●电源线和地线尽量加粗
●去耦电容尽量与VCC直接连接
●总的连线尽可能地短,关键信号线最短
●强信号、弱信号、高电压信号和弱电压信号要完全分开
●高频元件的间隔要充分
●模拟信号、数字信号分开,尽量远离
●集成电路的去耦电容应尽量靠近芯片的电源角,高频以最靠近为原则。
使之与电源和地之间形成的回路最短。
●旁路电容应均匀分布在集成电路周围。
●用于阻抗匹配目的的阻容器件的放置,应根据其属性合理布局。
●匹配电容电阻的布局要分清楚其方法,对于多负载的终端匹配一定要放在信号的最远端进行匹配。
3.生产装配技术的考虑
●元件的放置要便于调试和维修,大元件边上不能放置小元件,需要调试的元件周围应有足够的空间,发热元件应有足够的空间以利于散热,热敏元件应远离发热元件。
●双列直插元件相互的距离要大于2毫米。
电阻电容等贴片小元件相互距离应大于0.7毫米。
贴片元件焊盘外侧与相邻插装元件焊盘外侧要大于2毫米。
压接元件周围5毫米内不可以放置插装元器件。
焊接面周围5毫米内不可以放置贴装元件。
●所有标记字符不可以放在焊盘上,要保证装配以后还可以清晰地看到字符信息。
所有字符在x或y方向上应一致,字符大小应尽量统一。
●在以后生产时需要采用自动生成技术的电路板,要放置PCB的mark点和预留生产工艺边框,这样方便自动生成技术的应用。
四.汇编语言设计规范
现在许多书籍中,把软件设计成为软件工程。
软件设计如果不统一编程规范,则最终写出的程序可读性差,这不仅给代码的理解带来障碍,增减维护阶段的工作量,同时不规范的代码隐含错误的可能性也比较大。
1.排版
●程序块使用缩进方式,函数和标号使用空格缩进。
例如:
ORG0000H
LJMPSTART
ORG0030H
START:
CLRP1.0;P1.0输出低电平“0”,让点亮发光二极管
ACALLDELAY;调用延时子程序延时一段时间,让发光二极管亮一段时间
SETBP1.0;P1.0输出高电平“1”,熄灭发光二极管
ACALLDELAY;调用延时子程序延时一段时间,让发光二极管熄灭一段时间
AJMPSTART;跳转到程序开头重复执行;
********延时子程序********
DELAY:
MOVR7,#255
Y1:
MOVR6,#255
DJNZR6,$
DJNZR7,Y1
RET;延时子程序返回
END;程序结束
●在指令的操作数之间的,使用空格进行间隔,采用这种松散方式编写代码的目的是使代码更兼清晰。
例如:
CJNER2,#20H,LOOP
●一行最多写一条语句。
●变量定义时,保持对齐。
便于阅读和检查内存的使用情况。
●例如:
LEDEQU30H;
BEEPEQU31H;
FlagEQU32H;
2.注释
注释的原则是有助于对程序的阅读理解,注释不宜太多也不能太少。
●程序在必要的地方必须有注释,注释要准确、易懂、简洁。
而如下的注释则意义不大:
MOVFLAG,#00H;将FLAG赋值为0
但如下的注释则给出了额外有用的信息:
JNZCHECK_Err;假如校验出错
●注释应与其描述的代码相近,对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,不可放在下面,如放于上方则需与其上面的代码用空格隔开。
●头文件、源文件的头部,应进行注释。
注释必须列出:
文件名、作者、目的、功能、修改日志等。
●子程序的头部应进行注释,列出:
目的、功能、输入参数、输出参数、涉及的通用变量和寄存器、调用的其他子程序和模块、修改日志等。
●对重要代码段的功能、意图进行注释,提供有用的、额外的信息。
并在该代码段的结束处加一行注释表示该代码段结束。
●维护代码时,要更新相应的注释,删除不再有用的注释。
保持代码、注释的一致性,避免产生误解。
3.命名
●常量的命名
常量的命名规则:
单词的字母全部大写,各单词之间用下画线隔开。
●变量命名规定:
<前缀>+主体;注释
变量命名要考虑简单、直观、不易混淆。
前缀是可选项,表示变量类型,主体是必选项。
●子程序的命名
单词首字母是大写,其余均为小写。
子程序名应以一个动词开头,应类似一个动词断语或祈使句。
例如:
Test_Protect,Check_EEPROM,Init_Para
4.关于缩写
●标识符缩写形式如下的几种缩写技术。
a.去掉所有不在词头的元首字母。
如screen写成scrn,primtive写成prmv。
b.使用每个单词的头一个或几个字母。
如ChannelActivation写成ChanActiv,ReleaseIndication写成RelInd。
c.使用变量名中每个有典型意义的单词。
如CountofFailure写成FailCnt。
d.去掉无用的单词后缀ing,ed等。
如PagingRequest写成PagReq。
e.使用标准的或惯用的缩写形式(包括协议文件中出现的缩写形式)。
如BSIC(BaseStationIdentificationCode)、MAP(MobileApplicationPart)。
●缩写应该保持一致性。
如Channel不要有时缩写成Chan,有时缩写成Ch。
Length有时缩写成Len,有时缩写成len。
五.C51语言设计规范
1.注释
●文件(模块)起始注释内容
功能描述、版权、作者名称、修改时间、背景介绍等,复杂的算法需要加上流程说明,不同的公司会有不同的要求,但必须要有要求。
比如本书采用下面的格式:
/////////////////////////
//功能描述:
控制LED闪烁
//单片机:
51系列单片机
//晶振:
11.059MHz
//编写:
hc
//日期:
2007
//版本:
V1.0
/////////////////////////
●函数开头的注释内容
函数名称、功能、说明输入、返回、函数描述、流程处理、全局变量、调用样例等,复杂的函数需要加上变量用途说明。
////////////////////////////////////
//函数名:
LcdInit
//能描述:
LCD初始化
//全局变量:
//输入:
无
//返回:
无
////////////////////////////////////
●程序中的注释内容
注释内容应简练、清楚、明了,一目了然的语句不加注释。
2.命名
命名必须具有一定的实际意义。
(1)常量的命名:
全部用大写。
(2)变量的命名:
变量名加前缀,前缀反映变量的数据类型,用小写,反映变量意义的第一个字母大写,其他小写。
其中变量数据类型:
unsignedchar前缀ucsignedchar前缀sc
unsignedint前缀uisignedint前缀si
unsignedlong前缀ulsignedlong前缀sl
bit前缀b指针前缀p
例:
ucReceivData接收数据
(3)函数的命名:
函数名首字大写,若包含有两个单词的每个单词首字母大写。
函数原型说明包括:
引用外来函数及内部函数,外部引用必须在右侧注明函数来源:
模块名及文件名,内部函数,只要注释其定义文件名。
3.编辑风格
(1)缩进:
缩进用Tab作为单位,一个Tab为四个空格大小。
预处理语句、全局数据、函数原型、标题、附加说明、函数说明、标号等均顶格书写。
语句块的“{”“}”配对对齐,并与其前一行对齐。
(2)空格:
数据和函数在其类型,修饰名称之间适当空格并据情况对齐。
关键字原则上空一格,如:
If(...)等,运算符的空格规定如下:
“->”、“[”、“]”、“++”“——”、“~”、“!
”、“+”、“-”(指正负号),“&”(取地址或引用)、“*”(指使用指针时)等几个运算符两边不空格(其中单目运算符系指与操作数相连的一边),其他运算符(包括大多数二目运算符和三目运算符),“?
:
”两边均空一格,“(”、“)”运算符在其内侧空一格,在做函数定义时还可据情况多空或不空格来对齐,但在函数实现时可以不用。
“,”运算符只在其后空一格,须对齐时也可不空或多空格,对语句行后加的注释应用适当的空格与语句隔开并尽可能对齐。
(3)对齐:
原则上关系密切的行为对齐,对齐包括类型、修饰、名称、参数等各部分对齐。
另外每一行的长度不应超过屏幕太多,必要时适当换行,换行时尽可能在“,”处或运算符处,换行后最好以运算符大头,并且以下各行均以该句首行缩进,但该语句仍以首行的缩进为准,即如其下一行为“{”应为首行对齐。
(4)空行:
程序文件结构各部分之间空两行,若不必要也可只空一行,各函数实现之间一般空两行。
(5)修改:
版本封存以后的修改一定要将老语句用/**/封闭,不能自行删除或修改,并要在文件及函数的是修改记录中加以记录。
(6)形参:
在定义函数时,在函数名后面括号中直接进行形式参数说明,不再另行说明。
4.可维护性
(1)语句嵌套层次不得超过5层。
嵌套层次太多,增加了代码的复杂度及测试的难度,容易出错,增加代码维护的难度。
(2)避免相同的代码段在多个地方出现。
当某段代码需要在不同的地方重复使用时,应根据代码段的规模大小使用函数,调用或宏调用的方式代替。
这样,对该代码段的修改就可在一处完成,增强代码的可维护性。
(3)每个函数完成单一的功能,不设计多用途面面俱到的函数。
多功能集于一身的函数,很可能使函数的理解、测试、维护等变得困难。
使函数功能明确化,增加程序可读性,亦可方便维护、测试。
5.程序正确性和效率
(1)严禁使用未经初始化的变量
引用未经初始化的变量可能会产生不可预知的后果,特别是引用未经初始化的指针经常会导致系统崩溃,需特别注意。
(2)防止数据存储器的操作越界。
数据存储器的操作越界是软件系统主要错误之一,后果往往非常严重。
(3)这样变量的有效取值范围,防止表达式出现上溢或下溢。
(4)防止易混淆的指令和操作数拼写错误。
(5)避免函数中不必要语句,防止程序中的垃圾代码,预留代码应以注释的方式出现。
程序中的垃圾代码不仅占用额外的空间,而且还常常影响程序的功能与性能,很可能给程序的测试、维护等造成不必要的麻烦。
(6)通过对系统数据机构的划分与组织的改进,以及对程序算法的优化来提高空间效率。
这种方式是解决软件空间效率的根本办法。
(7)在多重循环中,应将最忙的循环放在最内层。
(8)避免循环体内含判断语句,将与循环变量无关的判断语句移到循环体外。
目的是减少判断次数。
循环体中的判断语句是否可以移到循环体外,要视程序的具体情况而言,一般情况,与循环变量无关的判断句可以移到循环体外,而有关的则不可以。
(9)中断和恢复,中断程序应该尽量短,应该在中断中进行标记,在主程序中处理,但实时性很高的程序段例外。
中断时应该保存所有涉及的通用变量和寄存器,如A,PSW,DPTR等。
(10)堆栈设置
堆栈对于程序非常重要,对于堆栈的设置要合理。
堆栈大小,在嵌套调用和容易溢出,造成系统故障;堆栈太大,浪费RAM资源。
为了节约堆栈资源,中断时要求不要保存太多资源,中断嵌套和程序嵌套层数不要太多,尽量不要超过5层。
着就要求合理的划分功能模块。
(11)看门狗电路
看门狗电路用于在单片机死机时自动复位。
单片机需要定时向看门狗发送脉冲,俗称“喂狗”。
喂狗不可太勤,这样看门狗没有起到作用;也不可太慢,这样容易造成单片机复位。
正确的喂狗应该在主循环中进行,最好是建立一个和独立的系统监控进程。
不可以在定时中中断中喂狗,因为单片机有时可能会在主循环中死掉。
6.接口
(1)去掉没有必要的公共变量,编程时应尽量少用公共变量。
公共变量是增大模块间耦合的原因之一,故应减少没必要的公共变量以降低模块间的耦合度。
应该构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
(2)当向公共变量传递数据时,要防止越界现象发生。
对公共变量赋值时,若有必要应进行合法性检查,以提高代码的可靠性、稳定性。
(3)尽量不设计多参数函数,将不使用的参数从接口中去掉,降低接口复杂度,减少函数间接口的复杂度。
(4)对所调用函数的返回码要仔细、全面地处理。
防止把错误传递到后面的处理流程。
如有意不检查其返回码,应明确指明。
(5)检查接口函数所有输入参数的有效性。
(6)检查函数的所有非参数输入,如外部数据、公共变量等。
7.代码可测性
(1)模块编写应该有完善的测试方面的考虑。
(2)源代码中应该设计了代码测试的内容。
在编写代码之前,应预先设计好程序调试与测试的方法和手段,并设计好各种调测开关及相应测试代码。
程序的调试与测试是软件生存周期中很重要的一个阶段,如何对软件进行较全面、高率的测试并尽可能地找出软件中的错误就成为很关键的问题。
因此在编写源代码之前,除了要有一套比较完善的测试计划外,还应设计出一系列代码测试手段,为单元测试、集成测试及系统联调提供方便。
(3)在同一项目组或产品组内,要有一套统一的为集成测试与系统联调准备的调测开关及相应函数,并且要有详细的说明。
本规则是针对项目或产品组的。
(4)在同一项目组或产品组内,调测打印出的信息串的格式要有统一的形式。
信息串中至少要有所在模块名(源文件名)及行号。
统一的调测信息格式便于集成测试。
(5)正式软件产品中应把调测代码去掉(即把软件中有关的调测开关关掉)。
(6)用调测开关来切换软件的DEBUG版和正式版,而不要同时存在正式版本和DEBUG版本的不同源文件,以减少维护的难度。
(7)在软件系统中设置与取消哟管测试手段,不能对软件实现的功能等产生影响。
即有测试代码的软件和关掉测试代码的软件,在功能行为上应一致。
(8)发现错误应该立即修改,并且若有必要记录下来。
(9)开发人员应坚持对代码进行彻底的测试(单元测试),而不依靠他人或测试组来发现问题。
(10)清理、整理或优化后的代码要经过审查及测试。
(11)代码版本升级要经过严格测试。
8.代码编译
(1)打开编译器的所有报警开关对程序进行编译。
防止隐藏可能是错误的报警。
(2)某些语句经编译后产生报警,但如果你认为它是正确的,那么应通过某种手段去掉报警信息。