如果你要很精確的延時，可以使用定時器，C語言的定時比較難計算，你可以用KEIL里的軟件仿真看看運行你的子程序需要多少時間，這樣是最清楚的了。當然，如果你的編程能力已經(jīng)達到比較高的水平就另一個說法，只要程序簡潔，C或匯編都一樣的高效率。下面我發(fā)一些別人的見解用C語言實現(xiàn)延時程序，首先想到的就是C常用的循環(huán)語句。下面這段代碼是我經(jīng)常在網(wǎng)上看到的：
voiddelay2(unsignedchari){　　for(;i!=0;i--);}
到底這段代碼能達到多高的精度呢？為了直接衡量這段代碼的效果，我把KeilC根據(jù)這段代碼產(chǎn)生的匯編代碼找了出來：
;FUNCTION_delay2(BEGIN)　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#18
;----Variable"i"assignedtoRegister"R7"----　　　　　　　　　　　　　　　　　　　　　;SOURCELINE#19　　　　　　　　　　　　　　　　　　　　　;SOURCELINE#20
0000　　　　?C0007:
0000EF　　　　　　　　MOV　　A,R7
00016003　　　　　　　JZ　　　?C001
000031F　　　　　　　　DEC　　R7
000480FA　　　　　　　SJMP　　?C0007　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#21
0006　　　　?C0010:
000622　　　　　　　　RET　　　　　　　　
;FUNCTION_delay2(END)

真是不看不知道~~~一看才知道這個延時程序是多么的不準點~~~光看主要的那四條語句，就需要6個機器周期。也就是說，它的精度頂多也就是6us而已，這還沒算上一條lcall和一條ret。如果我們把調(diào)用函數(shù)時賦的i值根延時長度列一個表的話，就是：
i　　delaytime/us0　　61　　122　　18
...因為函數(shù)的調(diào)用需要2個時鐘周期的lcall，所以delaytime比從函數(shù)代碼的執(zhí)行時間多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:
0000EF　　　　　　　　MOV　　A,R7
00016003　　　　　　　JZ　　　?C001
000031F　　　　　　　　DEC　　R7
000480FA　　　　　　　SJMP　　?C0007　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#22
0006　　　　?C0010:
000622　　　　　　　　RET　　　　　　　　
;FUNCTION_delay2(END)

其生成的代碼是一樣的。不過這的確不是什么好的習慣。因為這里實在沒有必要再引入多余的變量。我們繼續(xù)討論正題。有的朋友為了得當更長的延時，甚至用了這樣的代碼：

voiddelay2(unsignedlongi){　　for(;i!=0;i--);}
這段代碼產(chǎn)生的匯編代碼是什么樣子的？其實不用想也知道它是如何恐怖的$#^%&$......讓我們看一看：　　　　　　

;FUNCTION_delay2(BEGIN)　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#18
00008F00　　　　R　　MOV　　i+03H,R7
00028E00　　　　R　　MOV　　i+02H,R6
00048D00　　　　R　　MOV　　i+01H,R5
00068C00　　　　R　　MOV　　i,R4　　　　　　　　　　　　　　　　　　　　　;SOURCELINE#19　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#20
0008　　　　?C0007:
0008E4　　　　　　　　CLR　　A
0009FF　　　　　　　　MOV　　R7,A
000AFE　　　　　　　　MOV　　R6,A
000BFD　　　　　　　　MOV　　R5,A
000CFC　　　　　　　　MOV　　R4,A
000DAB00　　　　R　　MOV　　R3,i+03H
000FAA00　　　　R　　MOV　　R2,i+02H
0011A900　　　　R　　MOV　　R1,i+01H
0013A800　　　　R　　MOV　　R0,i
0015C3　　　　　　　　CLR　　C
0016120000　　　E　　LCALL　?C?ULCMP
0019601A　　　　　　　JZ　　　?C0010
001BE500　　　　R　　MOV　　A,i+03H
001D24FF　　　　　　　ADD　　A,#0FFH
001FF500　　　　R　　MOV　　i+03H,A
0021E500　　　　R　　MOV　　A,i+02H
002334FF　　　　　　　ADDC　　A,#0FFH
0025F500　　　　R　　MOV　　i+02H,A
0027E500　　　　R　　MOV　　A,i+01H
002934FF　　　　　　　ADDC　　A,#0FFH
002BF500　　　　R　　MOV　　i+01H,A
002DE500　　　　R　　MOV　　A,i
002F34FF　　　　　　　ADDC　　A,#0FFH
0031F500　　　　R　　MOV　　i,A
003380D3　　　　　　　SJMP　　?C0007　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#21
0035　　　　?C0010:
003522　　　　　　　　
RET　　　　　　　　
;FUNCTION_delay2(END)

呵呵，這倒是的確可以延遲很長時間~~~但是毫無精度可言了?！　?/p>

那么，用C到底能不能實現(xiàn)精確的延時呢？我把代碼稍微改了一下：
voiddelay1(unsignedchari){　　while(i--);}

因為根據(jù)經(jīng)驗，越簡潔的C代碼往往也能得出越簡潔的機器代碼。那這樣結果如何呢？把它生成的匯編代碼拿出來看一看就知道了。滿懷希望的我按下了“Buildtarget”鍵，結果打擊是巨大的：　　　　　　
;FUNCTION_delay1(BEGIN)　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#13
;----Variable"i"assignedtoRegister"R7"----　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#14
0000　　　　?C0004:　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#15
0000AE07　　　　　　　MOV　　R6,AR7
00021F　　　　　　　　DEC　　R7
0003EE　　　　　　　　MOV　　A,R6
000470FA　　　　　　　JNZ　　?C0004　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#16
0006　　　　?C0006:
000622　　　　　　　　
RET　　　　　　　　
;FUNCTION_delay1(END)

雖說生成的代碼跟用for語句是不大一樣，不過我可以毫無疑問的說，這兩種方法的效率是一樣的。似乎到此為止了，因為我實在想不出來源程序還有什么簡化的余地。看來我就要得出來這個結論了：“如果需要us級的延時精度，需要時用匯編語言。”但是真的是這樣嗎？我還是不甘心。因為我不相信大名鼎鼎的KeilC編譯器居然連djnz都不會用？？？因為實際上程序體里只需要一句loop:djnzr7,loop。近乎絕望之際（往往人在這種情況下確可以爆發(fā)出來，哦呵呵呵~~~），我隨手改了一下：
voiddelay1(unsignedchari){　　while(--i);}
心不在焉的編譯，看源碼：　　　　　　
;FUNCTION_delay1(BEGIN)　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#13;
----Variable"i"assignedtoRegister"R7"----　　　　　　　　　　　　　　　　　　　　　;SOURCELINE#14
0000　　　　?C0004:　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#15
0000DFFE　　　　　　　
DJNZ　　R7,?C0004　　　　　　　　　　　　　　　　　　　　　
;SOURCELINE#16
0002　　　　?C0006:
000222　　　　　　　　
RET　　　　　　　　
;FUNCTION_delay1(END)

天~~~奇跡出現(xiàn)了......我想這個程序應該已經(jīng)可以滿足一般情況下的需要了。如果列個表格的話：i　　delaytime/us1　　52　　73　　9...計算延時時間時，已經(jīng)算上了調(diào)用函數(shù)的lcall語句所花的2個時鐘周期的時間。　　

終于，結果已經(jīng)明了了。只要合理的運用，C還是可以達到意想不到的效果。很多朋友抱怨C效率比匯編差了很多，其實如果對KeilC的編譯原理有一個較深入的理解，是可以通過恰當?shù)恼Z法運用，讓生成的C代碼達到最優(yōu)化。即使這看起來不大可能，但還是有一些簡單的原則可循的：1.盡量使用unsigned型的數(shù)據(jù)結構。2.盡量使用char型，實在不夠用再用int，然后才是long。3.如果有可能，不要用浮點型。4.使用簡潔的代碼，因為按照經(jīng)驗，簡潔的C代碼往往可以生成簡潔的目標代碼（雖說不是在所有的情況下都成立）。