This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好!
我正在使用函数调用
SysCtlClockSet (SYSCTL_SYSDIV_5|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHz|SYSCTL_OSC_MAIN);
用于设置时钟。
在 上述设置下、我获得所需的(400/(2*5))= 40MHz 时钟。
当我将 SYSCTL_SYSDIV_5因子增加到 SYSCTL_SYSDIV_6时、我得到预期的33.3MHz 时钟。
当我将分频值从5减少到3并使用 SYSCTL_SYSDIV_3时、我应该得到的系统控制时钟为400/6 = 66.6MHz
系统控制时钟的时间周期应为15nS。
SysCtlDelay 函数的一个计数输入提供3个时钟周期延迟= 45nS 延迟。
PF1上的红色 LED 指示灯在5、000次计数中设置为高电平。 这将使红色 LED 的导通时间 为= 45nS* 5、000 = 22.5ms。
但是、示波器显示 PF1导通时间为25ms、这意味着系统控制时钟为60MHz、而不是66.6MHz。 我附加了示波器窗口、显示导通时间为25 ms。
为什么会出现这种差异?
您好!
[引用用户="balaji Sankar"]... 示波器显示 PF1导通时间为25ms、这意味着系统控制时钟为60MHz、而不是66.6MHz。[/QUERP]
我不确定这是正确的结论。 按照我的解释:
[引用 user="balaji Sankar"] SysCtlDelay 函数的一个计数输入提供3个时钟周期延迟= 45nS 延迟。
(再次)我不清楚"您如何得出结论、"系统时钟"运行频率@ 60MHz。" 我是否可以问:
监控"系统时钟"的一种出色方法是使用 MCU 的计时器之一来"输出经调节频率的系统时钟版本"。 (这种缩放使测量更轻松- 并且会在计时器捕获 MCU 的 GPIO 时减少频率输出(驱动需求)。)
一般规则-'SysCtlDelay()'提供'廉价/脏/放松的延迟'-但不是'以高精度和高精度而闻名!' (许多) ARM MCU 的定时器之一-证明提供此类精度是一流的...
注- IIRC -并非所有的分频因子都可以应用于系统时钟。 (MCU 手册应正确详述...)
标签: 'SysCtlDelay'可能无法提供绝对准确且一致的延迟...
您好 CB1_MOBILE、
感谢你的答复。
使用 SysCtlDelay 测量 CPU 时钟时出错。 我使用 SysStlClockGet ()函数并暂停代码以在表达式窗口中查看其输出值,它接近66.66 MHz。 当时钟一直 运行正常。
大家好、上一页-谢谢我的朋友。
你是“聪明的”,能够识别和响应 SysCtlDelay()的“轻松和快速”吸引力。 然而、您"不知道"这些限制-在这个基本函数中存在。 当所有其它失败时-应考虑 RTFM (阅读用户手册)。 在这种情况下-是"管制法律机构"-并警告:
26.2.2.10 SysCtlDelay
提供较小的延迟。
原型:空 SysCtlDelay (uint32_t ui32Count)
参数:ui32Count 是要执行的延迟循环迭代次数。
说明:此函数通过执行一个指定次数的简单3指令周期循环来提供一个生成延迟的方法。 它以汇编语言编写、以使循环指令计数在工具链中保持一致。 需要注意的是、该函数不提供精确的计时机制。 尽管延迟循环长达3个指令周期,但循环的执行时间会根据应用程序的中断环境而有很大的变化(除非在禁用中断的情况下运行循环,否则循环将被中断,这通常是一个不明智的操作) 以及当前系统时钟速率和闪存时序(等待状态和预取缓冲器的操作会影响时序)
还请注意、当系统时钟超过40MHz 时、可能会插入"等待状态"、从而降低 了更高频率的优势...
标签: '123用户手册列出了 SysCtlDelay()所受的限制。