MSP430：__delay_cycles() 是 slow/MCLK 可能很慢
MSP430: __delay_cycles() is slow/MCLK might be slow
恐怕我的 MSP430F5529 launchpad 可能有问题，因为我无法 __delay_cycles 正常运行。它总是使用工作正常但现在突然似乎有问题。我只想使用计时器模块来造成延迟，但当前程序已经在使用所有这些模块，我更愿意让它们专注于它们的任务。我只需要在初始化过程中有几个延迟，所以 "try not to use __delay_cycles" 的典型警告因为它停止了程序在这里并不是真正的问题。
所以问题是使用 __delay_cycles() 比它应该花费的时间要长，尽管事实上我最近在另一个程序上使用它没有问题。我已经尝试在具有默认设置的不同项目上使用相同的代码，并确保我的代码没有做一些奇怪的事情我制作了一个快速程序，它在应该延迟一秒后才打开 LED：
void main(void){
WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
P1OUT &= ~(BIT0);
P1DIR |= BIT0;
P1REN |= BIT0;
__delay_cycles(25000000);
P1OUT |= BIT0;
}
由于 25MHz 的 MCLK 运行s 延迟 2500 万个周期应该会产生大约 1 秒的延迟，但相反，在调试器中启动程序后，LED 需要大约 25 秒才能打开。这让我担心我的微控制器上的 MCLK 有问题，虽然我觉得这不太可能，但据我所知，在我没有改变任何东西之后，我似乎找不到发生这种情况的另一个原因.由于 LED 需要 25 秒才能打开，因此几乎看起来 MCLK 在 1MHz 时 运行ning，或者由于某种原因该功能来自 SMCLK。
我一直都处于高电平状态并且在使用 __delay_cycles() 时 MCLK 总是 运行s 在 1MHz 吗？而且我只是没有注意到，因为我之前使用 "successfully" 的延迟只有几毫秒？我发誓默认情况下 MCLK 的频率是 25MHz，唯一改变的方法是通过代码设置它。所以在我看来要么：
- A) 默认情况下，MSP430 不 运行 在 25MHz，我没有
codded 使这一点显而易见
- B) __delay_cycles() 改变执行过程中MCCLCK的速度
我从来没有注意到，因为我需要的延迟是如此之快
- C) 我不小心更改了编译器中的一些设置，或者为了
编译器优化器搞砸了的某些原因
__delay_cycles()
的编译
- D) 我的 MCLK broken/half 坏了
顺便说一下，如果该信息相关，我的编译器是 Code Composer Studio 6.1.0.00104。
有没有人有智慧分享可能出错的地方？
谢谢。
用户指南在第 5.2 节中说：
After a PUC, the UCS module default configuration is:
- XT1 in LF mode is selected as the oscillator source for XT1CLK.
- DCOCLKDIV is selected for MCLK.
- FLL operation is enabled and XT1CLK is selected as the FLL reference clock, FLLREFCLK.
[…] XT1 will remain disabled until the PSEL bits associated with the crystal pins are set.
并在第 5.2.12 节中：
When using XT1 operation in LF mode as the reference source into the FLL (SELREF = {0}), a crystal fault automatically causes the FLL reference source, FLLREFCLK, to be sourced by the REFO.
默认 FLL 配置（FLLN = 0x1F，FLLD = 1）导致 DCO 频率为 64 × 32768 Hz = 2.097152 MHz，MCLK 频率为 1.048576 MHz（好吧，如果 REFO 足够准确以证明这一点精度）。
要在 25 MHz 下 运行 CPU，您必须重新编程 FLL（并增加 PMMCOREV）。
恐怕我的 MSP430F5529 launchpad 可能有问题，因为我无法 __delay_cycles 正常运行。它总是使用工作正常但现在突然似乎有问题。我只想使用计时器模块来造成延迟，但当前程序已经在使用所有这些模块，我更愿意让它们专注于它们的任务。我只需要在初始化过程中有几个延迟，所以 "try not to use __delay_cycles" 的典型警告因为它停止了程序在这里并不是真正的问题。
所以问题是使用 __delay_cycles() 比它应该花费的时间要长，尽管事实上我最近在另一个程序上使用它没有问题。我已经尝试在具有默认设置的不同项目上使用相同的代码，并确保我的代码没有做一些奇怪的事情我制作了一个快速程序，它在应该延迟一秒后才打开 LED：
void main(void){
WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
P1OUT &= ~(BIT0);
P1DIR |= BIT0;
P1REN |= BIT0;
__delay_cycles(25000000);
P1OUT |= BIT0;
}
由于 25MHz 的 MCLK 运行s 延迟 2500 万个周期应该会产生大约 1 秒的延迟，但相反，在调试器中启动程序后，LED 需要大约 25 秒才能打开。这让我担心我的微控制器上的 MCLK 有问题，虽然我觉得这不太可能，但据我所知，在我没有改变任何东西之后，我似乎找不到发生这种情况的另一个原因.由于 LED 需要 25 秒才能打开，因此几乎看起来 MCLK 在 1MHz 时 运行ning，或者由于某种原因该功能来自 SMCLK。
我一直都处于高电平状态并且在使用 __delay_cycles() 时 MCLK 总是 运行s 在 1MHz 吗？而且我只是没有注意到，因为我之前使用 "successfully" 的延迟只有几毫秒？我发誓默认情况下 MCLK 的频率是 25MHz，唯一改变的方法是通过代码设置它。所以在我看来要么：
- A) 默认情况下，MSP430 不 运行 在 25MHz，我没有 codded 使这一点显而易见
- B) __delay_cycles() 改变执行过程中MCCLCK的速度 我从来没有注意到，因为我需要的延迟是如此之快
- C) 我不小心更改了编译器中的一些设置，或者为了 编译器优化器搞砸了的某些原因 __delay_cycles() 的编译
- D) 我的 MCLK broken/half 坏了
顺便说一下，如果该信息相关，我的编译器是 Code Composer Studio 6.1.0.00104。
有没有人有智慧分享可能出错的地方？
谢谢。
用户指南在第 5.2 节中说：
After a PUC, the UCS module default configuration is:
- XT1 in LF mode is selected as the oscillator source for XT1CLK.
- DCOCLKDIV is selected for MCLK.
- FLL operation is enabled and XT1CLK is selected as the FLL reference clock, FLLREFCLK.
[…] XT1 will remain disabled until the PSEL bits associated with the crystal pins are set.
并在第 5.2.12 节中：
When using XT1 operation in LF mode as the reference source into the FLL (SELREF = {0}), a crystal fault automatically causes the FLL reference source, FLLREFCLK, to be sourced by the REFO.
默认 FLL 配置（FLLN = 0x1F，FLLD = 1）导致 DCO 频率为 64 × 32768 Hz = 2.097152 MHz，MCLK 频率为 1.048576 MHz（好吧，如果 REFO 足够准确以证明这一点精度）。
要在 25 MHz 下 运行 CPU，您必须重新编程 FLL（并增加 PMMCOREV）。