短文标题： HAL_Delay(1000) 真准吗？SysTick的1ms基准从哪来
你有没有想过一个问题：HAL_Delay(1000)为什么能延时1秒？靠SysTick。 它每1ms中断一次，累加uwTick变量。HAL_Delay循环读取uwTick直到差值达到参数值。1ms基准的计算，
HAL_InitTick(TickPriority)
{
HAL_SYSTICK_Config(SystemCoreClock / 1000); // 设置1ms中断周期
}
SystemCoreClock是当前CPU内核时钟频率（Hz）：
- HSI 8MHz → 8000000/1000 = 8000 → SysTick每8000个时钟周期中断1次 → 1ms
- HSE 8MHz，PLL 72MHz → SystemCoreClock更新为72000000 → 72000000/1000 = 72000
SysTick的LOAD值随系统时钟频率动态调整，确保中断周期始终是1ms。时钟频率改变后延时不准 ，上电后默认使用HSI（8MHz）→ SystemCoreClock=8000000 → HAL_InitTick配置SysTick。执行SystemClock_Config后，系统时钟切换为PLL输出（72MHz），但SystemCoreClock变量被更新，SysTick的LOAD值仍是8000 。72MHz下8000个时钟周期 = 8000/72MHz ≈ 111μs，不是1ms。结果： HAL_Delay(1000)实际延时约111ms，而不是1000ms。解决方案：重新配置SysTick
HAL库的HAL_RCC_ClockConfig在系统时钟切换后，自动调用HAL_InitTick重新配置SysTick，使用新的SystemCoreClock计算LOAD值。用户手动修改时钟配置时（不通过HAL_RCC_ClockConfig），必须手动调用HAL_InitTick重新初始化SysTick。否则延时功能全部出错。
HAL_Delay的局限性
- 精度有限：中断周期1ms，误差±1ms（中断周期本身）。叠加中断嵌套延迟（高优先级中断阻塞SysTick），误差可达数毫秒
- 阻塞延时：延时期间CPU空转，无法执行其他任务
- 重入问题：在SysTick中断内调用HAL_Delay会死锁（因为uwTick不再累加）
- 不能用于微秒延时：1ms分辨率不够，微秒需用硬件定时器或DWT计数器
这个故事的启示， HAL_Delay的1ms基准依赖正确的SystemCoreClock值。改时钟，必须重配SysTick。 SysTick中断负责累加uwTick，高优先级中断长时间抢占会导致HAL_Delay变慢。写在最后， HAL_Delay方便，但不精准，不适用于高精度定时。微秒级延时用硬件定时器或DWT，毫秒级用HAL_Delay省心。知其然，知其所以然------延时功能背后藏着系统时钟与SysTick的联动。
（本文灵感源于于振南《新概念ARM32单片机》教程第6.3节"SYSTICK定时器代码与时钟配置关联解析"。）
觉得有用？点赞、转发，让更多人看懂HAL_Delay背后的SysTick机制。
