运用单片机的时分，常常会遇到需求短时刻延时的状况。需求的延时时刻很短，一般都是几十到几百奇妙（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代码往往能够生成简练的方针代码（虽然不是在所有的状况下都建立）。
