對MSP430微控制器__delay_cycles精確延時的說明及改正
阿新 • • 發佈:2019-01-03
在這裡, 我來討論一下關於MSP430微控制器使用__delay_cycles延時的問題.
IAR for MSP430編譯器提供了一個編譯器內聯的精確延時函式(並非真正的
函式)以提供使用者精確延時使用, 該函式原型是:
__intrinsic void __delay_cycles(unsigned long __cycles);
該內部函式實現__cycles個CPU週期的延時,但對於該引數的設定,我要陳述一下:
__cycles需要我們傳遞的是CPU執行的週期個數
網上普遍的用法是:
#define CPU_CLOCK 8000000
#define delay_us(us) __delay_cycles(CPU_CLOCK/1000000*(us))
#define delay_ms(ms) __delay_cycles(CPU_CLOCK/1000*(ms))
在CPU主時鐘頻率為8MHz時, 這確實沒有問題, 但是這樣的寫法:
#define CPU_CLOCK 8000000
這很容易讓人們想到, 可以通過修改它的值以實現對不同主頻系統引數的統一,其實
這是不正確的! 比如修改為#define CPU_CLOCK 32768以實現32KHz主頻的延時...
下面來計算看看:
當系統主時鐘頻率CPU_CLOCK為8MHz時:
頻率 f = 8MHz = 8,000,000Hz
機器週期 Tm = 1/f = 1/8MHz = 1/8us
也就是說,一個機器週期(nop)的時長是1/8us,所以延時1us即8*Tm,同上面:
#define delay_us(us) __delay_cycles(8*(us))
#define delay_ms(ms) __delay_cycles(8000*(ms))
按照上面的巨集定義方法,我們把CPU_CLOCK定義成32768,那麼:
頻率 f = 32KHz = 32,768Hz
機器週期 Tm = 1 /f = 1/32768Hz ~= 30.5us
可想而知,CPU最短的指令執行週期為30.5us, 這時, 想延時1us, 這可能嗎?
所以, 簡單地把上面的定義改成
#define CPU_CLOCK 32768
是絕對錯誤的.
同樣, 還有些朋友實現了0.5us的延時, 這在當f = 1MHz = 1000000Hz時也
是不現實的, 此時機器週期Tm = 1us. 在f = 8Mhz時, 4個機器週期為0.5us尚可.
所以, 為避免引起錯誤的使用或不正確的理解,最好像下面這樣定義巨集:
#if CPU_CLOCK == 8000000
#define delay_us(us) __delay_cycles(8*(us))
#define delay_ms(ms) __delay_cycles(8000*(ms))
#else
#pragma error "CPU_CLOCK is defined implicitly!"