基于SysTick的高精度延时设计
SysTick定时器与高精度延时系统的设计艺术
在嵌入式开发的世界里，时间从来不是抽象的概念。它是一次传感器采样的窗口，是通信协议中毫秒级的握手间隔，也是LED闪烁节奏背后那根看不见的脉搏。而在这其中， SysTick定时器 就像一位沉默却精准的节拍师，默默为整个系统提供心跳。
你有没有遇到过这样的场景？
写了个简单的 Delay_ms(10) ，结果实际延迟了30ms；或者在中断里加了一段延时，发现UART数据全乱了……这些问题的背后，往往不是代码写错了，而是我们对“时间”的理解还不够深入。
今天，咱们就来聊聊这个藏在Cortex-M内核里的小家伙—— SysTick ，以及如何用它构建一个真正可靠、可移植、甚至能在RTOS和裸机之间自由切换的时间系统。准备好了吗？🚀
从24位计数器说起：SysTick到底有多“简单”？
ARM Cortex-M系列的每个芯片都内置了一个叫 SysTick 的东西。别看名字像个玩具，它是操作系统的心脏起搏器，也是裸机项目中最常用的延时工具。
它的核心机制非常朴素：
- 是一个 24位向下递减计数器
- 从重装载值（LOAD）开始倒数
- 减到0时触发中断，并自动重新加载初始值
- 可选时钟源：HCLK 或 HCLK/8
听起来是不是像极了小时候玩过的沙漏⏳？只不过这个沙漏每秒能翻转上千万次！
举个例子，假设你的STM32主频是72MHz，选择HCLK作为SysTick时钟源：
每滴答时间 = 1 / 72,000,000 ≈ 13.89ns
如果想让它每1ms中断一次，那就要让它数72,000下：
SysTick->LOAD = 72000 - 1; // 注意要减1！
SysTick->VAL = 0;
SysTick->CTRL = 0x07; // 使能 | 中断 | HCLK
✅ 小贴士：为什么减1？因为计数是从
LOAD值递减到0共经历(LOAD + 1)次时钟周期。所以你要的是72000个周期，就得设成71999。
这比传统的 for 循环延时强在哪？
| 方式 | 是否受优化影响 | 移植性 | 精度 |
|---|---|---|---|
| for循环 | ❌ 容易被优化掉 | 差 | 不稳定 |
| SysTick轮询 | ✅ 不受影响 | 好 | 高 |
| HAL_Delay() | ✅ 可靠 | 很好 | 中~高 |
所以说，一旦你跨过了“空循环”的阶段，SysTick就是通往专业级设计的第一步。
STM32CubeMX：图形化配置下的时间起点
现在谁还手敲寄存器啊？😎 至少我不会轻易去碰那些复杂的RCC结构体了——除非你想花半小时查手册确认PLL分频系数是不是写反了。
STM32CubeMX的存在，让系统时钟配置变得像搭积木一样直观。但你知道吗？哪怕你不主动动SysTick，它也已经在背后悄悄工作了。
创建工程的第一步：选对MCU很重要
打开CubeMX，搜个常见的型号，比如 STM32F407VG —— 这可是当年“神板”STM32F4 Discovery的核心芯片，主频高达168MHz，性能杠杠的。
不同系列的STM32，它们的默认时钟行为也不一样：
| 芯片系列 | 典型主频 | 内核 | RC振荡器频率 |
|---|---|---|---|
| F1 | 72 MHz | M3 | 8MHz |
| F4 | 168 MHz | M4 | 16MHz |
| H7 | 480 MHz | M7 | 64MHz |
| L4 | 80 MHz | M4F | 16MHz |
选完芯片后，别急着点生成代码，先去看看“Clock Configuration”。
时钟树配置：精准延时的地基
很多开发者忽略了一个关键点： SysTick的精度完全取决于你的系统主频是否准确配置 。
默认情况下，系统可能跑在内部HSI上（比如16MHz），但如果你外接了8MHz晶振却不启用HSE，那你算出来的延时值全是错的！
来看一个典型的F407配置流程：
- 设置HSE为“Crystal/Ceramic Resonator”
- 开启PLL，输入源设为HSE
- 配置PLLM=8 → 输入频率变为1MHz
- PLLN=192 → VCO输出192MHz
- PLLP=DIV2 → SYSCLK = 96MHz
- AHB预分频设为2 → 实际CPU主频 = 96MHz
生成的代码长这样：
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 8;
RCC_OscInitStruct.PLL.PLLN = 192;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK |
RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV2;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3);
这套配置下来， SystemCoreClock 变量会被正确设置为 96,000,000 Hz ，后续所有基于此的延时计算才有意义。
那么，SysTick到底用了哪个时钟？
这个问题很关键！在ARM架构中，SysTick可以选择两种时钟源：
-
CTRL[2] = 1→ 使用 HCLK（即SYSCLK） -
CTRL[2] = 0→ 使用 HCLK / 8
而在STM32的HAL库中，默认使用的是 HCLK ，也就是全速运行。
这意味着，在96MHz系统下：
SysTick每tick = 1 / 96MHz ≈ 10.417 ns
实现1ms中断 → LOAD = (96,000,000 / 1000) - 1 = 95,999
下面这张表你可以收藏一下，工作中随时参考👇
| 主频(MHz) | 时钟源 | 1ms重载值 | 1μs对应ticks |
|---|---|---|---|
| 72 | HCLK | 71,999 | 72 |
| 96 | HCLK | 95,999 | 96 |
| 168 | HCLK | 167,999 | 168 |
| 96 | HCLK/8 | 11,999 | 12 |
看到没？如果你用了HCLK/8，那连微秒级延时都难做到，因为每1μs只有12个tick可用，误差太大。
所以结论很明确： 现代项目一律使用HCLK作为SysTick时钟源 。
CubeMX中的SysTick配置玄机
虽然SysTick是内核组件，但在STM32CubeMX里你依然能找到它的身影——就在“System Core”分类下。
点击进去你会发现几个选项：
- ✅ Enable SysTick interrupt（默认开启）
- ✅ Generate IRQ handler
- ✅ Callback function generation
这几个开关决定了你会得到什么样的代码支持。
中断优先级怎么设？
别忘了，SysTick虽然是内核异常（IRQn = -1），但它仍然可以通过NVIC设置优先级。
进入“NVIC Settings”，找到“SysTick timer interrupt”，建议设置为中等偏高优先级，比如抢占优先级=3。
为啥不能太高？因为如果你把它设成最高优先级，一旦频繁触发，其他任务根本抢不到CPU，反而破坏实时性。
也不能太低，否则被DMA或ADC中断打断太久，会导致 HAL_GetTick() 更新不及时，进而影响所有依赖它的函数。
经验法则： 比大多数外设中断略高即可，确保每毫秒都能准时响应 。
回调函数有什么用？
勾选“Callback function generation”后，会自动生成这样一个弱定义函数：
void HAL_SYSTICK_Callback(void);
你可以在 main.c 里重写它，比如做个呼吸灯效果：
void HAL_SYSTICK_Callback(void)
{
static uint32_t cnt = 0;
if (++cnt >= 500) {
cnt = 0;
HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
}
}
瞧，不用进主循环，LED自己就会每隔500ms闪一次💡。这就是事件驱动编程的魅力！
而且更重要的是： 这个回调是在SysTick中断上下文中执行的 ，意味着它可以用于推进RTOS调度、喂狗、心跳检测等关键任务。
HAL库背后的真相：HAL_Init()做了什么？
你以为 HAL_Init(); 只是初始化HAL库？其实它已经帮你把SysTick安排得明明白白。
来看看它的内部实现：
void HAL_Init(void)
{
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
SystemCoreClockUpdate();
// 关键来了👇
HAL_SYSTICK_Config(SystemCoreClock / 1000U);
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
}
注意这里传参是 SystemCoreClock / 1000U ，没有减1！难道错了？
NO！真相藏在底层函数里：
uint32_t HAL_SYSTICK_Config(uint32_t TicksNumb)
{
return SysTick_Config(TicksNumb);
}
// CMSIS头文件中
__STATIC_INLINE uint32_t SysTick_Config(uint32_t ticks)
{
if ((ticks - 1) > SysTick_LOAD_RELOAD_Msk) return (1);
SysTick->LOAD = ticks - 1; // 👈 自动减1！
SysTick->VAL = 0;
SysTick->CTRL = ...;
return (0);
}
原来如此！HAL库的设计者早就考虑到这一点，对外接口直接传“想要多少tick”，内部自动处理-1逻辑。这种设计大大降低了误用风险，也提升了API语义清晰度。
所以记住一句话： 调用HAL_SYSTICK_Config时，传的是理论周期数，不是寄存器原始值 。
手搓一套自己的延时函数：不只是为了装X
虽然 HAL_Delay() 很好用，但它有两个致命缺点：
- 阻塞式 ：调用期间啥也不能干
- 不能在ISR中使用 ：因为它依赖uwTick递增，而uwTick又来自SysTick中断……
所以我们需要封装一套更灵活的延时接口，既能用在主循环，也能塞进中断里跑。
先搞定基础：Delay_Init()
static uint32_t us_ticks;
void Delay_Init(void)
{
us_ticks = SystemCoreClock / 1000000U; // 每微秒多少个tick
}
这个初始化必须在 SystemClock_Config() 之后调用，否则 SystemCoreClock 还没更新，算出来就是错的！
微秒级延时：Delay_us()
来个硬核版本：
void Delay_us(uint32_t us)
{
uint32_t start = SysTick->VAL;
uint32_t wait_ticks = us * us_ticks;
while (wait_ticks > 0) {
uint32_t current = SysTick->VAL;
uint32_t elapsed;
if (current <= start) {
elapsed = start - current;
} else {
elapsed = start + (0xFFFFFFU - current) + 1;
}
if (elapsed >= us_ticks) {
wait_ticks--;
start = current;
}
}
}
这段代码干了三件事：
- 记录起始时刻的
VAL值 - 判断当前值是否小于起始值 → 正常递减 or 发生回绕？
- 累计经过的tick数，达到目标就退出
为什么要这么复杂？因为 VAL 是24位向下计数器，从某个值减到0再跳回LOAD的过程会产生“负跳变”。直接相减会出错，必须加上溢出补偿。
🔍 提示：
(current <= start)成立说明没发生重载；否则说明计数器绕了一圈回来，要用补码方式计算差值。
毫秒级延时：Delay_ms()
有了 Delay_us() ， Delay_ms() 就很简单了：
void Delay_ms(uint32_t ms)
{
for (uint32_t i = 0; i < ms; i++) {
Delay_us(1000);
}
}
虽然效率不高，但对于短时间延时完全够用。若追求极致性能，可以用DWT或硬件定时器替代。
但是！这些延时真的准吗？
别高兴得太早，现实世界远比理想模型复杂得多。
编译器优化：朋友还是敌人？
你有没有试过在-O2模式下编译 Delay_us() ？很可能发现延时变得极短甚至消失！
原因很简单：编译器认为你在做无意义的空转，于是直接优化掉了整个循环。
解决方案也很直接：
__attribute__((optimize("O0")))
void Delay_us(uint32_t us)
{
// 强制以-O0级别编译
...
}
或者全局设置 -Og （调试友好型优化），避免激进优化破坏延时逻辑。
📌 强烈建议 ：任何涉及精确延时的函数，都要加上 optimize("O0") 属性，防止被意外优化。
中断干扰怎么办？
想象一下：你正在执行 Delay_us(10) ，突然来了个高优先级中断，跑了20μs才返回。这时候你的时间早就超了！
这种情况怎么破？
方案一：临时提升优先级
void CriticalDelay_us(uint32_t us)
{
__disable_irq(); // 关闭所有可屏蔽中断
Delay_us(us);
__enable_irq();
}
⚠️ 危险操作！只适用于极短延时（<10μs），否则会影响系统响应能力。
方案二：改用DWT周期计数器（推荐）
某些高端MCU（如F4/F7/H7）支持DWT模块，其中有一个CYCCNT寄存器，记录CPU执行的总周期数，精度达到单cycle！
// 初始化
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
// 延时函数
void Delay_us_dwt(uint32_t us)
{
uint32_t start = DWT->CYCCNT;
uint32_t cycles = us * (SystemCoreClock / 1000000);
while ((DWT->CYCCNT - start) < cycles);
}
优点非常明显：
- 不依赖SysTick状态
- 分辨率等于CPU主频
- 执行路径极短，适合高频调用
缺点嘛……F1系列没这玩意儿😅
在中断里还能不能延时？答案是：最好不要！
新手最容易犯的错误就是在中断服务程序（ISR）里调用 Delay_ms() 。
void EXTI0_IRQHandler(void)
{
HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
Delay_ms(10); // ⚠️ 大忌！
}
这一行代码会让整个系统冻结10ms！期间所有低优先级中断都无法响应，串口缓冲区溢出、定时器丢失、RTOS卡死……问题接踵而至。
正确的做法是什么？
使用标志位 + 主循环轮询
volatile uint32_t target_tick = 0;
volatile uint8_t delay_active = 0;
// 中断中只设置标志
void EXTI0_IRQHandler(void)
{
HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);
target_tick = HAL_GetTick() + 10; // 10ms后触发
delay_active = 1;
}
// 主循环中检测
while (1) {
if (delay_active && HAL_GetTick() >= target_tick) {
// 执行后续动作
HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);
delay_active = 0;
}
}
你看，中断瞬间完成，延时期间系统依旧活跃，这才是嵌入式应有的样子👏
进一步封装，我们可以做一个轻量级软定时器池：
#define MAX_TIMERS 5
typedef struct {
uint32_t timeout;
uint32_t interval;
void (*cb)(void);
uint8_t active;
} soft_timer_t;
soft_timer_t timers[MAX_TIMERS];
void SoftTimer_Start(uint8_t id, uint32_t ms, void(*cb)(void), uint8_t repeat) {
timers[id].timeout = HAL_GetTick() + ms;
timers[id].interval = repeat ? ms : 0;
timers[id].cb = cb;
timers[id].active = 1;
}
void SoftTimer_Process(void) {
for (int i = 0; i < MAX_TIMERS; i++) {
if (timers[i].active && HAL_GetTick() >= timers[i].timeout) {
if (timers[i].cb) timers[i].cb();
if (timers[i].interval) {
timers[i].timeout += timers[i].interval;
} else {
timers[i].active = 0;
}
}
}
}
把这个 SoftTimer_Process() 放进主循环，你就拥有了一个无需RTOS就能运行的多任务调度引擎！
实战验证：拿示波器说话！
理论说得天花乱坠，不如实测一次来得实在。
怎么做？很简单：
- 选一个GPIO引脚，比如PA5
- 在延时前后翻转电平
- 接上示波器，测量脉冲宽度
while (1) {
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, 1);
Delay_us(10);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, 0);
HAL_Delay(1); // 给示波器留出观察时间
}
理想情况应该看到一个 10μs宽 的正脉冲。但你可能会发现：
- 实际是10.5μs → 函数调用开销
- 个别脉冲长达100μs → 被中断打断
- 波形不稳定 → Flash等待周期未关闭
解决办法：
- 使用BSRR/BRR寄存器进行原子操作
- 关闭Flash等待周期（ART加速+预取）
- 在关键区域禁用特定中断
FAST_IO_SET(); // BSRR置位
Delay_us(10);
FAST_IO_RESET(); // BRR清零
这样才能逼近理论极限。
真实项目中的应用案例
说了这么多，回到实战场景。
场景一：驱动DS18B20温度传感器
这家伙用单总线协议，复位脉冲要求480μs低电平 + 70μs等待 + 410μs恢复。
uint8_t DS18B20_Reset(void)
{
OW_OUTPUT_LOW();
Delay_us(480); // 必须精确！
OW_INPUT();
Delay_us(70);
uint8_t presence = OW_READ();
Delay_us(410);
return presence == 0;
}
这种场合下，绝对不能用 HAL_Delay() ，必须用轮询式高精度延时。
场景二：CCS811气体传感器启动流程
启动需要多个阶段延时：
- 上电后等待1s
- 查询状态寄存器
- 启动应用模式
- 再等2s初始化完成
如果用阻塞延时，整个系统就卡住了。聪明的做法是用状态机：
switch(state) {
case WAIT_BOOT:
if (HAL_GetTick() - start >= 1000) state = CHECK_STATUS;
break;
case WAIT_INIT:
if (HAL_GetTick() - start >= 2000) state = READY;
break;
}
非阻塞、不卡顿，完美融入实时系统。
和RTOS共处的艺术：别让两个SysTick打架
当你引入FreeRTOS，事情变得更复杂了。
因为：
-
HAL_Delay()依赖SysTick中断更新uwTick -
osDelay()也依赖SysTick提供节拍
如果不小心，两边都会注册中断处理，导致计数翻倍💥
标准做法是：
void SysTick_Handler(void)
{
HAL_IncTick(); // HAL库用
osSystickHandler(); // FreeRTOS用
}
并且在初始化时不重复调用 HAL_SYSTICK_Config() ，交给RTOS去管理。
或者更彻底一点： 禁用HAL的SysTick绑定 ，全部由RTOS接管。
构建可复用的延时组件：一次编写，到处运行
最后，让我们把这些经验打包成一个通用模块。
头文件定义统一接口
// delay.h
#ifndef _DELAY_H_
#define _DELAY_H_
#include <stdint.h>
void Delay_Init(void);
void Delay_ms(uint32_t ms);
void Delay_us(uint32_t us);
uint32_t GetTickCount(void);
#endif
支持动态频率调整
有些低功耗项目会在运行中切换主频，这时候必须重新计算 us_ticks 。
可以加个API：
void Delay_UpdateClock(uint32_t freq_hz)
{
us_ticks = freq_hz / 1000000U;
}
这样无论你是跑在16MHz还是480MHz，延时都准确无误。
结语：时间系统的终极形态
SysTick看似简单，但它串联起了裸机、HAL、RTOS、中断、电源管理等多个维度。掌握它，不仅仅是学会一个延时函数，更是理解嵌入式系统如何协调资源、调度任务、维持稳定的思维方式。
下次当你写下 Delay_ms(100) 的时候，不妨想想：
- 这100ms背后有多少次SysTick中断？
- uwTick是怎么增长的？
- 如果我在中断里调用它会发生什么？
- 我的代码能不能移植到另一块主频不同的板子上？
这些问题的答案，才是真正的工程师素养所在。
毕竟， 控制时间的人，才能掌控系统 ⏱️✨
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
扫一扫
2830
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
