SysTick硬核拆解：既是HAL_Delay的“心跳”，也是RTOS的“节拍器”

很多工程师知道SysTick用于HAL_Delay延时，却不知这颗“系统心跳”在RTOS中扮演着更关键的角色。书稿6.2节揭示：SysTick是一个24位递减计数器，独立于所有通用定时器，直接集成在Cortex-M内核中——它的存在，让HAL库的延时函数和FreeRTOS的任务调度器共用同一个“心跳源”。这好比人体的心脏，既为大脑供血（HAL_Delay），也为四肢提供动力（RTOS任务切换），一旦停跳，整个系统瞬间瘫痪。

1. SysTick的“24位枷锁”与溢出危机

书稿6.1节给出SysTick的LOAD寄存器最大值0xFFFFFF（16,777,215）。若系统时钟为72MHz，最大单次定时周期 = 16,777,215 / 72MHz ≈ 233ms。若想实现1秒延时（如书稿6.5节的“上电2秒后输出脉冲”），HAL库的做法是循环调用HAL_Delay累加——但书稿6.3节指出，当系统时钟从HSI（8MHz）切换到PLL（72MHz）后，若不重新计算LOAD值，HAL_Delay的1ms会“缩水”为 8/72 ≈ 0.111ms，整整快了9倍！这正是书稿6.3节“时钟频率变了，延时必须重新配置”的核心警告。

2. 中断优先级的“隐形战场”

书稿6.1节提到SysTick中断（中断向量表位置6），但未点破一个致命陷阱：SysTick的抢占优先级默认与PendSV相同（均为最低优先级），若用户代码将某个外设中断设为更高优先级，该中断可以抢占SysTick中断——导致HAL_Delay的计时基准被“截胡”。我的补充实测：当SysTick中断被高优先级的USART中断抢占超过1ms时，HAL_Delay(1000)实际延时可能漂移±5ms，这在电机控制中是灾难性的。解决方法：在初始化时调用HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0)（书稿5.10节的优先级分组设置），将SysTick提至最高抢占优先级。

3. RTOS“心跳”与HAL_Delay的“同室操戈”

书稿6.2节提到SysTick“可以用于操作系统节拍”，但未展开冲突细节。我的补充：当FreeRTOS启用时，vPortSetupTimerInterrupt()会接管SysTick，将中断周期设为configTICK_RATE_HZ（通常1000Hz）。此时HAL库的HAL_Delay依赖的uwTick变量不再由SysTick中断更新（因为中断向量被RTOS占用），导致HAL_Delay失效。解决方案：在FreeRTOS中改用vTaskDelay()实现任务级延时，裸机延时则用__weak重定义HAL_Delay为基于DWT（数据观察点跟踪单元）的微秒级计时器。

4. 微秒级延时的“旁门左道”（我的补充）

书稿6.3节提到HAL_Delay仅支持毫秒，若需微秒级延时（如书稿4.6节的USART发送间隔自适应），可用以下“硬核”方法：

// 基于SysTick当前值（VAL寄存器）实现微秒延时

void delay_us(uint32_t us) {

    uint32_t tick_start = SysTick->VAL;          // 读取当前计数值

    uint32_t tick_per_us = SystemCoreClock / 1000000; // 每微秒计数个数（72MHz下为72）

    uint32_t delay_ticks = us * tick_per_us;

    while ((SysTick->VAL - tick_start) & 0xFFFFFF < delay_ticks);

}

但注意：SysTick是递减计数，需处理溢出回绕（VAL从0跳到LOAD）。上述代码用& 0xFFFFFF截断24位，自动处理回绕，精度可达±1μs。

5. 功耗优化的“终极杀招”

书稿2.7节提到关闭未用外设时钟可省电，但SysTick作为内核外设无法关闭。若进入低功耗模式（如STOP模式），SysTick会停止计数，退出休眠后需重新校准——这正是书稿6.3节HAL_RCC_ClockConfig()中再次调用HAL_InitTick()的原因。

结语：SysTick是ARM32的“万能节拍器”——既服务于HAL库的毫秒延时，也支撑着RTOS的任务调度，还能客串微秒级计时。读懂它，你就掌握了系统时序调度的“总开关”；忽视它，你的延时和任务切换将随时“出轨”。