STM32 SysTick中断概念用途及与查询式延时的区别

我正在修读STM32入门课程，近期学习了中断与SysTick相关知识点。目前已经理解GPIO中断的工作逻辑：例如按键按下时，触发信号被检测后会跳转执行对应的处理函数，但尚未掌握SysTick中断的核心概念与适用场景。

我此前基于查询逻辑实现了毫秒级SysTick延时函数，具体代码如下：

void systickDelayMs(int delay){
    //-------Configure Systick-------
    /* Reload with number of clocks per milisecond */
    SysTick->LOAD = SYSTICK_LOAD_VAL;
    /*Clear systick current value register*/
    SysTick->VAL = 0;
    /*Enable systick and select internal clock source */
    SysTick->CTRL = CTRL_ENABLE |  CTRL_CLKSRC;
    for(int i=0; i<delay ; i++){
        /*Wait until the countflag is set*/
        while((SysTick-> CTRL & CTRL_COUNTFLAG)== 0){}
    }

    SysTick->CTRL = 0;

}

SysTick中断可实现哪些上述查询式SysTick延时函数无法完成的功能？

你现在写的查询式SysTick延时本质是阻塞式延时，运行时CPU会完全卡在while轮询计数标志的逻辑里，SysTick只是被你临时拿来当一个单次计数的工具，用完就关。而开启SysTick中断后，你可以把它配置成固定周期触发中断的系统心跳，能实现很多阻塞延时根本做不到的能力：

• 非阻塞多任务并行运行：阻塞延时执行期间CPU没法处理主循环的其他逻辑，比如你写个1000ms的延时，这1秒里CPU除了空转啥也干不了。开SysTick中断后，你只需要在中断里维护一个递增的全局时间计数，主循环里可以同时跑多个独立任务，比如判断时间到了就扫按键、刷新屏幕、读传感器数据，不需要死等，CPU利用率会大幅提升。
• 全局统一时间戳服务：在SysTick中断里累加的全局计数值可以作为系统从启动开始的运行时间戳，所有需要时间判断的逻辑都可以基于这个时间戳实现，比如判断按键按下的持续时长做消抖、计算两次传感器采样的间隔、做通信超时判断，这些功能靠阻塞延时完全实现不了——毕竟阻塞的时候其他逻辑全停了，根本没法记录时间差。
• 多软件定时器支持：基于SysTick提供的全局时基，你可以实现任意数量的软件定时器，给每个定时器绑定不同的回调和周期，比如100ms翻转一次LED、500ms读一次温湿度、2s上报一次数据，这些定时任务可以并行运行，不需要每个任务都写阻塞延时把CPU卡住。
• 低功耗场景适配：阻塞延时的时候CPU一直在跑空循环，根本没法进入休眠低功耗模式。用SysTick中断的方案时，主循环没待处理任务的时候，CPU可以直接执行WFI指令进入休眠，等SysTick中断触发后再唤醒执行对应逻辑，整机功耗可以降到阻塞方案的几十分之一，电池供电场景必须用这种实现。
• 稳定的系统时序保障：阻塞延时很容易打乱整个程序的运行时序，比如你本来要100ms采一次数据，中间插了个200ms的阻塞延时，采样间隔直接就飘了。就算阻塞期间来了其他外设中断，中断返回后还是会回到死等延时的逻辑，主循环的执行节奏完全不可控。而SysTick中断的优先级可以按需求配置，时基计数完全独立于主循环逻辑运行，不管主循环在处理什么业务，时间计数不会停，整个系统的时序精度有稳定保障。

补充说明：你现在写的阻塞式延时每次调用都要重写SysTick的LOAD、VAL寄存器，用完还直接关了SysTick外设，这种用法完全浪费了SysTick作为Cortex-M内核内置系统定时器的核心价值——它从设计之初就是用来给整个操作系统/裸机系统提供统一心跳的，不是拿来做单次阻塞延时的。

内容的提问来源于stack exchange，提问作者cb_ann