在这里， 我来讨论一下关于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！”
#endif
别的：
__delay_cycles 并不是真实的函数， 仅仅供给编译器内联打开，该函数并不支持变量参数， 其参数只能是常数.
