STM32 延时函数优化实践：从阻塞到非阻塞的进阶之路

最新推荐文章于 2026-05-06 10:38:23 发布

原创

最新推荐文章于 2026-05-06 10:38:23 发布 · 622 阅读

标签

#STM32 #嵌入式开发 #延时函数 #定时器

1. 从“傻等”到“会等”：为什么你的STM32需要更好的延时？

刚接触STM32开发的朋友，十有八九都是从那个经典的 HAL_Delay() 或者自己写的 Delay_ms() 函数开始的。我刚开始做项目那会儿，也是这么干的，简单粗暴，一行代码让程序“等一会儿”，传感器数据就读到了，LED灯就闪烁了，感觉一切尽在掌握。

但很快，我就踩坑了。当时做一个智能小车的遥控器，需要一边扫描按键，一边用蓝牙发送状态。我用了 Delay_ms(20) 来消抖和做发送间隔。结果就是，按下按键时，蓝牙发送卡顿了；蓝牙在发送时，按键怎么按都没反应。整个设备“傻”得不行，用户体验极差。这就是典型的阻塞式延时带来的问题：CPU在“傻等”，宝贵的计算资源被白白浪费，其他紧急任务得不到响应。

所以，今天我想和你深入聊聊STM32的延时函数优化。这绝不仅仅是换个函数调用那么简单，而是一种编程思维的转变——从“顺序执行+死等”的单片机思维，升级到“事件驱动+并行响应”的嵌入式系统思维。无论你是正在做毕业设计的学生，还是已经工作但被产品响应迟缓困扰的工程师，理解从阻塞到非阻塞的进阶之路，都能让你的代码效率提升一个档次，产品体验更加流畅。

我们将从最基础的SysTick阻塞延时讲起，看看它的老底；然后一步步解锁硬件定时器中断、状态机轮询，直到RTOS的任务延时。我会用我实际项目里踩过的坑和填过的坑作为例子，手把手带你实现代码，让你不仅知道“是什么”，更明白“为什么”以及“什么时候用”。放心，我会尽量用最直白的话和看得懂的代码，把这事儿说清楚。

2. 基石与瓶颈：深入理解阻塞式SysTick延时

几乎所有STM32的入门教程，都会教你用SysTick定时器来实现延时。它确实是集成在Cortex-M内核里的一个宝贝，用起来非常方便，但我们得真正弄懂它，才知道它好在哪里，又局限在哪里。

2.1 SysTick的工作原理与代码实现

SysTick是一个24位的递减计数器。你可以告诉它：“数 N 个时钟周期就告诉我一声。” 然后它就开始倒数，数到0的时候，会置位一个标志位（COUNTFLAG），也可以选择产生一个中断。

假设我们的STM32F103运行在72MHz的主频下，那么1个时钟周期就是1/72微秒。要实现1微秒的延时，就需要数72个时钟周期。这就是我们常见代码的由来：

void Delay_us(uint32_t us)
{
    SysTick->LOAD = 72 * us;  // 设置重装载值
    SysTick->VAL = 0x00;       // 清空当前值寄存器
    SysTick->CTRL = 0x05;      // 使能SysTick，使用处理器时钟源，不开启中断
    while((SysTick->CTRL & 0x00010000) == 0); // 等待计数到0的标志
    SysTick->CTRL = 0x04;      // 关闭SysTick
}

这段代码很精炼，但每一行都有讲究。LOAD 寄存器设置的是倒数开始的初始值。VAL 清空是为了从一个确定的状态开始。CTRL 寄存器的第0位置1是使能，第2位置1是选择内核时钟（72MHz），这里关键是没有置位第1位，所以不开启中断。while 循环就是在原地不停地查询那个计数到0的标志位。这个查询过程，就是“阻塞”的核心——CPU的注意力完全被这件事独占。

毫秒和秒级延时，通常就是基于微秒延时的循环：

void Delay_ms(uint32_t ms)
{
    while(ms--)
    {
        Delay_us(1000);
    }
}

看起来没问题，但这里隐藏了一个误差累积的问题。Delay_us(1000) 本身有极小的误差（可能因为中断打断），循环1000次后，这个误差就可能被放大到可察觉的程度。

2.2 阻塞式延时的致命缺点与应用场景

理解了原理，它的缺点就显而易见了：

CPU资源浪费：在等待的几毫秒、几百毫秒甚至几秒里，CPU明明可以执行成千上万条指令，去扫描个按键、刷新一段显示、处理一下通信数据，但它却在“空转”。这在电池供电的设备上是致命的功耗浪费。
系统无响应：就像我开头提到的遥控器例子，这是最影响用户体验的一点。整个程序就像单线程一样，延时函数不返回，其他任何事都干不了。
难以处理外部事件：如果一个紧急的中断（比如电源故障检测）在延时期间发生，虽然中断服务程序会被执行，但一旦中断返回，程序又会回到那个 while 循环里继续“傻等”，无法根据这个紧急事件做出整体的流程调整。

那么，它是不是一无是处呢？当然不是。在以下场景，阻塞式延时依然是简单可靠的选择：