如果你要很精確的延時(shí)，可以使用定時(shí)器，C語(yǔ)言的定時(shí)比較難計(jì)算，你可以用KEIL里的軟件仿真看看運(yùn)行你的子程序需要多少時(shí)間，這樣是最清楚的了。當(dāng)然，如果你的編程能力已經(jīng)達(dá)到比較高的水平就另一個(gè)說(shuō)法，只要程序簡(jiǎn)潔，C或匯編都一樣的高效率。下面我發(fā)一些別人的見(jiàn)解用C語(yǔ)言實(shí)現(xiàn)延時(shí)程序，首先想到的就是C常用的循環(huán)語(yǔ)句。下面這段代碼是我經(jīng)常在網(wǎng)上看到的：
voiddelay2(unsignedchari){　　for(;i!=0;i--);}
到底這段代碼能達(dá)到多高的精度呢？為了直接衡量這段代碼的效果，我把KeilC根據(jù)這段代碼產(chǎn)生的匯編代碼找了出來(lái)：
;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)

真是不看不知道~~~一看才知道這個(gè)延時(shí)程序是多么的不準(zhǔn)點(diǎn)~~~光看主要的那四條語(yǔ)句，就需要6個(gè)機(jī)器周期。也就是說(shuō)，它的精度頂多也就是6us而已，這還沒(méi)算上一條lcall和一條ret。如果我們把調(diào)用函數(shù)時(shí)賦的i值根延時(shí)長(zhǎng)度列一個(gè)表的話，就是：
i　　delaytime/us0　　61　　122　　18
...因?yàn)楹瘮?shù)的調(diào)用需要2個(gè)時(shí)鐘周期的lcall，所以delaytime比從函數(shù)代碼的執(zhí)行時(shí)間多2。順便提一下，有的朋友寫(xiě)的是這樣的代碼：

voiddelay2(unsignedchari)
{　　unsignedchara;　　
for(a=i;a!=0;a--);}
可能有人認(rèn)為這會(huì)生成更長(zhǎng)的匯編代碼來(lái)，但是事實(shí)證明：　　　　　　
;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)

其生成的代碼是一樣的。不過(guò)這的確不是什么好的習(xí)慣。因?yàn)檫@里實(shí)在沒(méi)有必要再引入多余的變量。我們繼續(xù)討論正題。有的朋友為了得當(dāng)更長(zhǎng)的延時(shí)，甚至用了這樣的代碼：

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

;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)

呵呵，這倒是的確可以延遲很長(zhǎng)時(shí)間~~~但是毫無(wú)精度可言了。　　

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

因?yàn)楦鶕?jù)經(jīng)驗(yàn)，越簡(jiǎn)潔的C代碼往往也能得出越簡(jiǎn)潔的機(jī)器代碼。那這樣結(jié)果如何呢？把它生成的匯編代碼拿出來(lái)看一看就知道了。滿懷希望的我按下了“Buildtarget”鍵，結(jié)果打擊是巨大的：　　　　　　
;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)

雖說(shuō)生成的代碼跟用for語(yǔ)句是不大一樣，不過(guò)我可以毫無(wú)疑問(wèn)的說(shuō)，這兩種方法的效率是一樣的。似乎到此為止了，因?yàn)槲覍?shí)在想不出來(lái)源程序還有什么簡(jiǎn)化的余地。看來(lái)我就要得出來(lái)這個(gè)結(jié)論了：“如果需要us級(jí)的延時(shí)精度，需要時(shí)用匯編語(yǔ)言。”但是真的是這樣嗎？我還是不甘心。因?yàn)槲也幌嘈糯竺ΧΦ腒eilC編譯器居然連djnz都不會(huì)用？？？因?yàn)閷?shí)際上程序體里只需要一句loop:djnzr7,loop。近乎絕望之際（往往人在這種情況下確可以爆發(fā)出來(lái)，哦呵呵呵~~~），我隨手改了一下：
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)了......我想這個(gè)程序應(yīng)該已經(jīng)可以滿足一般情況下的需要了。如果列個(gè)表格的話：i　　delaytime/us1　　52　　73　　9...計(jì)算延時(shí)時(shí)間時(shí)，已經(jīng)算上了調(diào)用函數(shù)的lcall語(yǔ)句所花的2個(gè)時(shí)鐘周期的時(shí)間。　　

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