Keil C51程序设计中几种精确延时方法.docx
《Keil C51程序设计中几种精确延时方法.docx》由会员分享，可在线阅读，更多相关《Keil C51程序设计中几种精确延时方法.docx（12页珍藏版）》请在冰点文库上搜索。
KeilC51程序设计中几种精确延时方法
KeilC51程序设计中几种精确延时方法
延时通常有两种方法：
一种是硬件延时，要用到定时器/计数器，这种方法可以提高CPU的工作效率，也能做到精确延时；另一种是软件延时，这种方法主要采用循环体进行。
1使用定时器/计数器实现精确延时
单片机系统一般常选用11.0592MHz、12MHz或6MHz晶振。
第一种更容易产生各种标准的波特率，后两种的一个机器周期分别为1μs和2μs，便于精确延时。
本程序中假设使用频率为12MHz的晶振。
最长的延时时间可达216=65536μs。
若定时器工作在方式2，则可实现极短时间的精确延时；如使用其他定时方式，则要考虑重装定时初值的时间（重装定时器初值占用2个机器周期）。
在实际应用中，定时常采用中断方式，如进行适当的循环可实现几秒甚至更长时间的延时。
使用定时器/计数器延时从程序的执行效率和稳定性两方面考虑都是最佳的方案。
但应该注意，C51编写的中断服务程序编译后会自动加上PUSHACC、PUSHPSW、POPPSW和POPACC语句，执行时占用了4个机器周期；如程序中还有计数值加1语句，则又会占用1个机器周期。
这些语句所消耗的时间在计算定时初值时要考虑进去，从初值中减去以达到最小误差的目的。
2软件延时与时间计算
在很多情况下，定时器/计数器经常被用作其他用途，这时候就只能用软件方法延时。
下面介绍几种软件延时的方法。
2.1短暂延时
可以在C文件中通过使用带_NOP_（）语句的函数实现，定义一系列不同的延时函数，如Delay10us（）、Delay25us（）、Delay40us（）等存放在一个自定义的C文件中，需要时在主程序中直接调用。
如延时10μs的延时函数可编写如下：
voidDelay10us（）{
_NOP_（）;
_NOP_（）;
_NOP_（）;
_NOP_（）;
_NOP_（）;
_NOP_（）;
}
Delay10us（）函数中共用了6个_NOP_（）语句，每个语句执行时间为1μs。
主函数调用Delay10us（）时，先执行一个LCALL指令（2μs），然后执行6个_NOP_（）语句（6μs），最后执行了一个RET指令（2μs），所以执行上述函数时共需要10μs。
可以把这一函数当作基本延时函数，在其他函数中调用，即嵌套调用\[4\]，以实现较长时间的延时；但需要注意，如在Delay40us（）中直接调用4次Delay10us（）函数，得到的延时时间将是42μs，而不是40μs。
这是因为执行Delay40us（）时，先执行了一次LCALL指令（2μs），然后开始执行第一个Delay10us（），执行完最后一个Delay10us（）时，直接返回到主程序。
依此类推，如果是两层嵌套调用，如在Delay80us（）中两次调用Delay40us（），则也要先执行一次LCALL指令（2μs），然后执行两次Delay40us（）函数（84μs），所以，实际延时时间为86μs。
简言之，只有最内层的函数执行RET指令。
该指令直接返回到上级函数或主函数。
如在Delay80μs（）中直接调用8次Delay10us（），此时的延时时间为82μs。
通过修改基本延时函数和适当的组合调用，上述方法可以实现不同时间的延时。
2.2在C51中嵌套汇编程序段实现延时
在C51中通过预处理指令#pragmaasm和#pragmaendasm可以嵌套汇编语言语句。
用户编写的汇编语言紧跟在#pragmaasm之后，在#pragmaendasm之前结束。
如：
#pragmaasm
…
汇编语言程序段
…
#pragmaendasm
延时函数可设置入口参数，可将参数定义为unsignedchar、int或long型。
根据参数与返回值的传递规则，这时参数和函数返回值位于R7、R7R6、R7R6R5中。
在应用时应注意以下几点：
◆#pragmaasm、#pragmaendasm不允许嵌套使用；
◆在程序的开头应加上预处理指令#pragmaasm，在该指令之前只能有注释或其他预处理指令；
◆当使用asm语句时，编译系统并不输出目标模块，而只输出汇编源文件；
◆asm只能用小写字母，如果把asm写成大写，编译系统就把它作为普通变量；
◆#pragmaasm、#pragmaendasm和asm只能在函数内使用。
将汇编语言与C51结合起来，充分发挥各自的优势，无疑是单片机开发人员的最佳选择。
2.3使用示波器确定延时时间
利用示波器来测定延时程序执行时间。
方法如下：
编写一个实现延时的函数，在该函数的开始置某个I/O口线如P1.0为高电平，在函数的最后清P1.0为低电平。
在主程序中循环调用该延时函数，通过示波器测量P1.0引脚上的高电平时间即可确定延时函数的执行时间。
方法如下：
sbitT_point=P1^0;
voidDly1ms（void）{
unsignedinti,j;
while
（1）{
T_point=1;
for（i=0;i<2;i++）{
for（j=0;j<124;j++）{;}
}
T_point=0;
for（i=0;i<1;i++）{
for（j=0;j<124;j++）{;}
}
}
}
voidmain（void）{
Dly1ms（）;
}
把P1.0接入示波器，运行上面的程序，可以看到P1.0输出的波形为周期是3ms的方波。
其中，高电平为2ms，低电平为1ms，即for循环结构“for（j=0;j<124;j++）{;}”的执行时间为1ms。
通过改变循环次数，可得到不同时间的延时。
当然，也可以不用for循环而用别的语句实现延时。
这里讨论的只是确定延时的方法。
2.4使用反汇编工具计算延时时间
用KeilC51中的反汇编工具计算延时时间，在反汇编窗口中可用源程序和汇编程序的混合代码或汇编代码显示目标应用程序。
为了说明这种方法，还使用“for（i=0;i在程序中加入这一循环结构，首先选择buildtaget，然后单击start/stopdebugsession按钮进入程序调试窗口，最后打开Disassemblywindow，找出与这部分循环结构相对应的汇编代码，具体如下：
C:
0x000FE4CLRA//1T
C:
0x0010FEMOVR6,A//1T
C:
0x0011EEMOVA,R6//1T
C:
0x0012C3CLRC//1T
C:
0x00139FSUBBA,DlyT//1T
C:
0x00145003JNCC:
0019//2T
C:
0x00160EINCR6//1T
C:
0x001780F8SJMPC:
0011//2T
可以看出，0x000F～0x0017一共8条语句，分析语句可以发现并不是每条语句都执行DlyT次。
核心循环只有0x0011~0x0017共6条语句，总共8个机器周期，第1次循环先执行“CLRA”和“MOVR6，A”两条语句，需要2个机器周期，每循环1次需要8个机器周期，但最后1次循环需要5个机器周期。
DlyT次核心循环语句消耗（2+DlyT×8+5）个机器周期，当系统采用12MHz时，精度为7μs。
当采用while（DlyT--）循环体时，DlyT的值存放在R7中。
相对应的汇编代码如下：
C:
0x000FAE07MOVR6,R7//1T
C:
0x00111FDECR7//1T
C:
0x0012EEMOVA,R6//1T
C:
0x001370FAJNZC:
000F//2T
循环语句执行的时间为（DlyT+1）×5个机器周期，即这种循环结构的延时精度为5μs。
通过实验发现，如将while（DlyT--）改为while（--DlyT），经过反汇编后得到如下代码：
C:
0x0014DFFEDJNZR7,C:
0014//2T
可以看出，这时代码只有1句，共占用2个机器周期，精度达到2μs，循环体耗时DlyT×2个机器周期；但这时应该注意，DlyT初始值不能为0。
注意：
计算时间时还应加上函数调用和函数返回各2个机器周期时间。
应用单片机的时候，经常会碰到需要短时间延时的情况。
需要的延时时间很短，一般都是几十到几百微妙（us）。
有时候还需要很高的精度，比如用单片机驱动DS18B20的时候，误差容许的范围在十几us以内，不然很轻易出错。
这种情况下，用计时器往往有点小题大做。
而在极端的情况下，计时器甚至已经全部派上了别的用途。
这时就需要我们另想别的办法了。
以前用汇编语言写单片机程序的时候，这个问题还是相对轻易解决的。
比如用的是12MHz晶振的51，打算延时20us，只要用下面的代码，就可以满足一般的需要：
movr0,#09h
loop:
djnzr0,loop
51单片机的指令周期是晶振频率的1/12，也就是1us一个周期。
movr0,#09h需要2个极其周期，djnz也需要2个极其周期。
那么存在r0里的数就是（20-2）/2。
用这种方法，可以非常方便的实现256us以下时间的延时。
假如需要更长时间，可以使用两层嵌套。
而且精度可以达到2us，一般来说，这已经足够了。
现在，应用更广泛的毫无疑问是Keil的C编译器。
相对汇编来说，C固然有很多优点，比如程序易维护，便于理解，适合大的项目。
但缺点（我觉得这是C的唯一一个缺点了）就是实时性没有保证，无法猜测代码执行的指令周期。
因而在实时性要求高的场合，还需要汇编和C的联合应用。
但是是不是这样一个延时程序，也需要用汇编来实现呢？
为了找到这个答案，我做了一个实验。
用视频教程'>c语言实现延时程序，首先想到的就是C常用的循环语句。
下面这段代码是我经常在网上看到的：
voiddelay2（unsignedchari）
{
for（;i!
=0;i--）;
}
到底这段代码能达到多高的精度呢？
为了直接衡量这段代码的效果，我把KeilC根据这段代码产生的汇编代码找了出来：
;FUNCTION_delay2（BEGIN）
;SOURCELINE#18
;----Variable'i'assignedtoRegister'R7'----
;SOURCELINE#19
;SOURCELINE#20
0000?
C0007:
0000EFMOVA,R7
00016003JZ?
C0010
00031FDECR7
000480FASJMP?
C0007
;SOURCELINE#21
0006?
C0010:
000622RET
;FUNCTION_delay2（END）
真是不看不知道~~~一看才知道这个延时程序是多么的不准点~~~光看主要的那四条语句，就需要6个机器周期。
也就是说，它的精度顶多也就是6us而已，这还没算上一条lcall和一条ret。
假如我们把调用函数时赋的i值根延时长度列一个表的话，就是：
idelaytime/us
06
112
218
...
因为函数的调用需要2个时钟周期的lcall，所以delaytime比从函数代码的执行时间多2。
顺便提一下，有的朋友写的是这样的代码：
voiddelay2（unsignedchari）
{
unsignedchara;
for（a=i;a!
=0;a--）;
}
可能有人认为这会生成更长的汇编代码来，但是事实证实：
;FUNCTION_delay2（BEGIN）
;SOURCELINE#18
;----Variable'i'assignedtoRegister'R7'----
;SOURCELINE#19
;SOURCELINE#21
;----Variable'a'assignedtoRegister'R7'----
0000?
C0007:
0000EFMOVA,R7
00016003JZ?
C0010
00031FDECR7
000480FASJMP?
C0007
;SOURCELINE#22
0006?
C0010:
000622RET
;FUNCTION_delay2（END）
其生成的代码是一样的。
不过这的确不是什么好的习惯。
因为这里实在没有必要再引入多余的变量。
我们继续讨论正题。
有的朋友为了得当更长的延时，甚至用了这样的代码：
voiddelay2（unsignedlongi）
{
for（;i!
=0;i--）;
}
这段代码产生的汇编代码是什么样子的？
其实不用想也知道它是如何恐怖的$#^%&%$......让我们看一看：
;FUNCTION_delay2（BEGIN）
;SOURCELINE#18
00008F00RMOVi+03H,R7
00028E00RMOVi+02H,R6
00048D00RMOVi+01H,R5
00068C00RMOVi,R4
;SOURCELINE#19
;SOURCELINE#20
0008?
C0007:
0008E4CLRA
0009FFMOVR7,A
000AFEMOVR6,A
000BFDMOVR5,A
000CFCMOVR4,A
000DAB00RMOVR3,i+03H
000FAA00RMOVR2,i+02H
0011A900RMOVR1,i+01H
0013A800RMOVR0,i
0015C3CLRC
0016120000ELCALL?
C?
ULCMP
0019601AJZ?
C0010
001BE500RMOVA,i+03H
001D24FFADDA,#0FFH
001FF500RMOVi+03H,A
0021E500RMOVA,i+02H
002334FFADDCA,#0FFH
0025F500RMOVi+02H,A
0027E500RMOVA,i+01H
002934FFADDCA,#0FFH
002BF500RMOVi+01H,A
002DE500RMOVA,i
002F34FFADDCA,#0FFH
0031F500RMOVi,A
003380D3SJMP?
C0007
;SOURCELINE#21
0035?
C0010:
003522RET
;FUNCTION_delay2（END）
呵呵，这倒是的确可以延迟很长时间~~~但是毫无精度可言了。
那么，用C到底能不能实现精确的延时呢？
我把代码稍微改了一下：
voiddelay1（unsignedchari）
{
while（i--）;
}
因为根据经验，越简洁的C代码往往也能得出越简洁的机器代码。
那这样结果如何呢？
把它生成的汇编代码拿出来看一看就知道了。
满怀希望的我按下了“Buildtarget”键，结果打击是巨大的：
;FUNCTION_delay1（BEGIN）
;SOURCELINE#13
;----Variable'i'assignedtoRegister'R7'----
;SOURCELINE#14
0000?
C0004:
;SOURCELINE#15
0000AE07MOVR6,AR7
00021FDECR7
0003EEMOVA,R6
000470FAJNZ?
C0004
;SOURCELINE#16
0006?
C0006:
000622RET
;FUNCTION_delay1（END）
虽说生成的代码跟用for语句是不大一样，不过我可以毫无疑问的说，这两种方法的效率是一样的。
似乎到此为止了，因为我实在想不出来源程序还有什么简化的余地。
看来我就要得出来这个结论了：
“假如需要us级的延时精度，需要时用汇编语言。
”但是真的是这样吗？
我还是不甘心。
因为我不相信大名鼎鼎的KeilC编译器居然连djnz都不会用？
？
？
因为实际上程序体里只需要一句loop:
djnzr7,loop。
近乎绝望之际（往往人在这种情况下确可以爆发出来，哦呵呵呵~~~），我随手改了一下：
voiddelay1（unsignedchari）
{
while（--i）;
}
心不在焉的编译，看源码：
;FUNCTION_delay1（BEGIN）
;SOURCELINE#13
;----Variable'i'assignedtoRegister'R7'----
;SOURCELINE#14
0000?
C0004:
;SOURCELINE#15
0000DFFEDJNZR7,?
C0004
;SOURCELINE#16
0002?
C0006:
000222RET
;FUNCTION_delay1（END）
天~~~奇迹出现了......我想这个程序应该已经可以满足一般情况下的需要了。
假如列个表格的话：
idelaytime/us
15
27
39
...
计算延时时间时，已经算上了调用函数的lcall语句所花的2个时钟周期的时间。
终于，结果已经明了了。
只要合理的运用，C还是可以达到意想不到的效果。
很多朋友抱怨C效率比汇编差了很多，其实假如对KeilC的编译原理有一个较深入的理解，是可以通过恰当的语法运用，让生成的C代码达到最优化。
即使这看起来不大可能，但还是有一些简单的原则可循的：
1.尽量使用unsigned型的数据结构。
2.尽量使用char型，实在不够用再用int，然后才是long。
3.假如有可能，不要用浮点型。
4.使用简洁的代码，因为按照经验，简洁的C代码往往可以生成简洁的目标代码（虽说不是在所有的情况下都成立）。
5...想不起来了，哦呵呵呵~~~
本文章来自21视频教程网
51单片机KeilC延时程序的简单研究_C语言程序设计教程原文链接：
升级会员 