51单片机短时间延时

运用单片机的时分，常常会遇到需求短时刻延时的状况。需求的延时时刻很短，一般都是几十到几百奇妙(us)。有时分还需求很高的精度，比方用单片机驱动DS18B20的时分，差错容许的范围在十几us以内，否则很简略犯错。这种状况下，用计时器往往有点小题大做。而在极点的状况下，计时器乃至现已悉数派 上了其他用处。这时就需求咱们另想其他办法了。
曾经用汇编言语写单片机程序的时分，这个问题仍是相对简略处理的。比方用的是12MHz晶振的51，计划延时20us，只需用下面的代码，就能够满意一般的需求：
mov r0, #09h
loop: djnz r0, loop
51单片机的指令周期是晶振频率的1/12，也便是1us一个周期。mov r0, #09h需求2个极端周期，djnz也需求2个极端周期。那么存在r0里的数便是(20-2)/2。用这种办法，能够十分便利的完成256us以下时刻的 延时。假如需求更长时刻，能够运用两层嵌套。并且精度能够到达2us，一般来说，这现已足够了。
现在，运用更广泛的毫无疑问是Keil的C编译器。相对汇编来说，C固然有许多长处，比方程序易保护，便于了解，合适大的项目。但缺陷（我觉得这是C的唯 一一个缺陷了）便是实时性没有确保，无法猜测代码履行的指令周期。因而在实时性要求高的场合，还需求汇编和C的联合运用。可是是不是这样一个延时程序，也 需求用汇编来完成呢？为了找到这个答案，我做了一个试验。
用C言语完成延时程序，首要想到的便是C常用的循环句子。下面这段代码是我常常在网上看到的：
void delay2(unsigned char i)
{
for(; i != 0; i–);
}
究竟这段代码能到达多高的精度呢？为了直接衡量这段代码的作用，我把Keil C依据这段代码发生的汇编代码找了出来：
; FUNCTION _delay2 (BEGIN)
; SOURCE LINE # 18
;—- Variable i assigned to Register R7 —-
; SOURCE LINE # 19
; SOURCE LINE # 20
0000 ?C0007:
0000 EF MOV A,R7
0001 6003 JZ ?C0010
0003 1F DEC R7
0004 80FA SJMP ?C0007
; SOURCE LINE # 21
0006 ?C0010:
0006 22 RET
; FUNCTION _delay2 (END)
真是不看不知道~~~一看才知道这个延时程序是多么的不准点~~~光看首要的那四条句子，就需求6个机器周期。也便是说，它的精度顶多也便是6us罢了，这还没算上一条lcall和一条ret。假如咱们把调用函数时赋的i值根延时长度列一个表的话，便是：
i delay time/us
0 6
1 12
2 18
…
由于函数的调用需求2个时钟周期的lcall，所以delay time比从函数代码的履行时刻多2。趁便提一下，有的朋友写的是这样的代码：
void delay2(unsigned char i)
{
unsigned char a;
for(a = i; a != 0; a–);
}
或许有人以为这会生成更长的汇编代码来，可是事实证明：
; FUNCTION _delay2 (BEGIN)
; SOURCE LINE # 18
;—- Variable i assigned to Register R7 —-
; SOURCE LINE # 19
; SOURCE LINE # 21
;—- Variable a assigned to Register R7 —-
0000 ?C0007:
0000 EF MOV A,R7
0001 6003 JZ ?C0010
0003 1F DEC R7
0004 80FA SJMP ?C0007
; SOURCE LINE # 22
0006 ?C0010:
0006 22 RET
; FUNCTION _delay2 (END)
其生成的代码是相同的。不过这确实不是什么好的习气。由于这儿真实没有必要再引进剩余的变量。咱们持续评论正题。有的朋友为了妥当更长的延时，乃至用了这样的代码：
void delay2(unsigned long i)
{
for(; i != 0; i–);
}
这段代码发生的汇编代码是什么姿态的？其实不必想也知道它是怎么恐惧的$#^%&%$……让咱们看一看：
; FUNCTION _delay2 (BEGIN)
; SOURCE LINE # 18
0000 8F00 R MOV i+03H,R7
0002 8E00 R MOV i+02H,R6
0004 8D00 R MOV i+01H,R5
0006 8C00 R MOV i,R4
; SOURCE LINE # 19
; SOURCE LINE # 20
0008 ?C0007:
0008 E4 CLR A
0009 FF MOV R7,A
000A FE MOV R6,A
000B FD MOV R5,A
000C FC MOV R4,A
000D AB00 R MOV R3,i+03H
000F AA00 R MOV R2,i+02H
0011 A900 R MOV R1,i+01H
0013 A800 R MOV R0,i
0015 C3 CLR C
0016 120000 E LCALL ?C?ULCMP
0019 601A JZ ?C0010
001B E500 R MOV A,i+03H
001D 24FF ADD A,#0FFH
001F F500 R MOV i+03H,A
0021 E500 R MOV A,i+02H
0023 34FF ADDC A,#0FFH
0025 F500 R MOV i+02H,A
0027 E500 R MOV A,i+01H
0029 34FF ADDC A,#0FFH
002B F500 R MOV i+01H,A
002D E500 R MOV A,i
002F 34FF ADDC A,#0FFH
0031 F500 R MOV i,A
0033 80D3 SJMP ?C0007
; SOURCE LINE # 21
0035 ?C0010:
0035 22 RET
; FUNCTION _delay2 (END)
呵呵，这倒是确实能够推迟很长时刻~~~可是毫无精度可言了。
那么，用C究竟能不能完成准确的延时呢？我把代码略微改了一下：
void delay1(unsigned char i)
{
while(i–);
}
由于依据经历，越简练的C代码往往也能得出越简练的机器代码。那这样成果怎么呢？把它生成的汇编代码拿出来看一看就知道了。满怀希望的我按下了“Build target”键，成果冲击是巨大的：
; FUNCTION _delay1 (BEGIN)
; SOURCE LINE # 13
;—- Variable i assigned to Register R7 —-
; SOURCE LINE # 14
0000 ?C0004:
; SOURCE LINE # 15
0000 AE07 MOV R6,AR7
0002 1F DEC R7
0003 EE MOV A,R6
0004 70FA JNZ ?C0004
; SOURCE LINE # 16
0006 ?C0006:
0006 22 RET
; FUNCTION _delay1 (END)
虽 说生成的代码跟用for句子是不大相同，不过我能够毫无疑问的说，这两种办法的功率是相同的。好像到此为止了，由于我真实想不出来历程序还有什么简化的余 地。看来我就要得出来这个定论了：“假如需求us级的延时精度，需求时用汇编言语。”可是真的是这样吗？我仍是不甘心。由于我不相信大名鼎鼎的Keil C编译器竟然连djnz都不会用？？？由于实际上程序体里只需求一句loop: djnz r7, loop。近乎失望之际（往往人在这种状况下确能够迸发出来，哦呵呵呵~~~），我顺手改了一下：
void delay1(unsigned char i)
{
while(–i);
}
心猿意马的编译，看源码：
; FUNCTION _delay1 (BEGIN)
; SOURCE LINE # 13
;—- Variable i assigned to Register R7 —-
; SOURCE LINE # 14
0000 ?C0004:
; SOURCE LINE # 15
0000 DFFE DJNZ R7,?C0004
; SOURCE LINE # 16
0002 ?C0006:
0002 22 RET
; FUNCTION _delay1 (END)
天~~~奇观呈现了……我想这个程序应该现已能够满意一般状况下的需求了。假如列个表格的话：
i delay time/us
1 5
2 7
3 9
…
核算延时时刻时，现已算上了调用函数的lcall句子所花的2个时钟周期的时刻。
总算，成果现已明了了。只需合理的运用，C仍是能够到达意想不到的作用。许多朋友诉苦C功率比汇编差了许多，其实假如对Keil C的编译原理有一个较深化的了解，是能够经过恰当的语法运用，让生成的C代码到达最优化。即便这看起来不大或许，但仍是有一些简略的准则可循的：1.尽量 运用unsigned型的数据结构。2.尽量运用char型，真实不够用再用int，然后才是long。3.假如有或许，不要用浮点型。4.运用简练的代 码，由于依照经历，简练的C代码往往能够生成简练的方针代码（虽然不是在所有的状况下都建立）。5…想不起来了，哦呵呵呵