F407 的 SysTick 用法拆解

深入拆解 STM32F407 的 SysTick：不只是延时，更是时间的“心跳引擎” ⚙️⏱️

你有没有遇到过这种情况——写一个简单的 Delay_ms(10) ，结果发现系统卡死了？或者想做个按键消抖，却发现手头的定时器 TIM2 正在被 PWM 占用？又或者在移植 FreeRTOS 时，莫名其妙任务调度失灵了？

别急，问题很可能出在一个你每天都在用、却从未真正理解的地方： SysTick 。

它看起来像个“小配角”，只有 24 位、最大只能计到 99.86ms，甚至没有独立的时钟门控。但正是这个藏在 Cortex-M 内核深处的小家伙，撑起了整个嵌入式系统的 时间秩序 。从毫秒延时到 RTOS 调度，从超时检测到性能分析，它的影子无处不在。

今天，我们就来彻底掀开它的盖子，看看这颗“系统心跳”到底怎么跳、为什么非它不可，以及如何用得漂亮而不翻车。💥

---

它不是普通定时器，而是内核的一部分 🧠

先打破一个常见误解： SysTick 不是外设 。

你用过的 TIM2、TIM3，都是挂在 APB 总线上的独立模块，需要开启时钟、配置寄存器、设置 NVIC 中断优先级……一套流程走下来，代码动辄几十行。

而 SysTick 呢？它是 ARM 给所有 Cortex-M 系列（M0/M3/M4/M7） 统一内置的标准组件 ，直接集成在处理器内核里，就像 CPU 自带的一个“秒表”。

这意味着什么？

• ✅ 访问速度极快 ：读写寄存器几乎零延迟；
• ✅ 不占外设资源 ：不用去抢 TIMx 的名额；
• ✅ 初始化极其简单 ：几行代码就能跑起来；
• ✅ 跨平台通用性强 ：只要换芯片还是 Cortex-M，这套逻辑基本不变。

在 STM32F407 上，主频高达 168MHz，SysTick 就像是一个精准的脉搏发生器，为整个系统提供稳定的时间基准。RTOS 靠它切换任务，HAL 库靠它实现 HAL_Delay() ，你自己写的延时函数也可以基于它构建。

但它到底是怎么工作的？我们一步步来看。

---

工作机制：一个递减的 24 位计数器 🔁

想象一下：你有一个倒计时器，初始值设为 N，每过一个时钟周期就减 1，直到归零。归零那一刻，触发一次中断，然后自动重新加载 N，继续下一轮倒数。

这就是 SysTick 的核心逻辑。

它有三个关键寄存器：

寄存器	功能
LOAD	设置重装载值（即初值 N）
VAL	当前计数值，随时可读
CTRL	控制寄存器，启停、选择时钟源、使能中断等

工作流程如下：

1. 配置 LOAD = N
2. 启动计数器（设置 CTRL[ENABLE] = 1 ）
3. VAL 开始从 N 递减至 0
4. 到 0 时：
   - 如果使能了中断 → 触发 SysTick_Handler
   - 自动将 LOAD 的值 reload 回 VAL
5. 继续下一轮循环

整个过程完全由硬件自动完成，CPU 只需初始化一次，后续无需干预——这才是真正的“设好就忘”。

---

时钟源选哪个？HCLK 还是 HCLK/8？⚡

SysTick 支持两种时钟源：

• HCLK （即 AHB 总线时钟，通常等于 CPU 主频）
• HCLK / 8

默认情况下，大多数库（包括 HAL 和 FreeRTOS）都使用 HCLK ，因为这样可以获得最高的时间分辨率。

举个例子，在 F407 上，系统主频为 168MHz：

• 若使用 HCLK，则每个 tick 是 1 / 168,000,000 ≈ 5.95ns
• 若使用 HCLK/8，则每个 tick 是 ~47.6ns

要实现 1μs 延时 ，我们需要多少个 ticks？

$$
\text{ticks} = 168\,MHz \times 1\,\mu s = 168
$$

但由于是从 167 递减到 0（共 168 个周期），所以实际设置 LOAD = 167 。

📌 小贴士：所有基于 SysTick 的延时计算都要记得 -1 ！

那是不是永远该用 HCLK？也不一定。

如果你特别在意功耗，比如在低功耗模式下运行，可以选择 HCLK/8 来降低功耗。不过代价是精度下降，微秒级控制会变得困难。

一般建议：
- ✔️ 高精度需求 → 用 HCLK
- ✔️ 极端低功耗场景 → 考虑 HCLK/8

---

最长能定时多久？别被 24 位限制住！🕰️

24 位听起来不多，最大值是 0xFFFFFF = 16,777,215 。

以 168MHz 计算，最长单次定时时间为：

$$
T_{max} = \frac{16,777,216}{168,000,000} \approx 99.86\,ms
$$

也就是说， 最长只能一次性定不到 100ms 。

但这并不意味着你不能做更长的延时。聪明的做法是： 软硬结合 。

比如你想 delay(500)，怎么办？

方案一：用中断方式维护一个全局计数器，每 1ms 加 1，然后等待 500 次即可。

方案二：轮询方式中，多次调用短延时组合。

所以别慌，24 位虽短，够用就行。关键是看你怎么用。

---

实战三连击：三种典型用法全解析 💥

接下来才是重头戏。我见过太多人只会复制粘贴 Delay_us() ，却不知道背后的坑在哪里。下面我们从裸机到 RTOS，层层递进，把每种用法讲透。

---

第一种：裸机轮询 + 精确延时（适合小型项目）

当你不想引入操作系统，也不想开中断，只想简单地 Delay_us(10) 点个灯，这种模式最合适。

核心思路

利用 VAL 寄存器当前值的变化来判断是否过了指定时间。由于它是自由运行的 24 位递减计数器，我们可以记录起始时刻的 VAL ，然后不断轮询差值。

但注意：它是 递减 且 可能溢出 的！所以不能直接相减。

正确的做法是：

#include "stm32f4xx.h"

static uint32_t ticks_per_us;

void SysTick_Init(void) {
    // 动态获取每微秒多少个tick
    ticks_per_us = SystemCoreClock / 1000000UL;  // 如168MHz → 168

    // 启用SysTick：HCLK作为时钟源
    SysTick->LOAD = 0xFFFFFF;           // 设最大值，避免自动中断
    SysTick->VAL  = 0;
    SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk | 
                    SysTick_CTRL_ENABLE_Msk;
}

void Delay_us(uint32_t us) {
    uint32_t start = SysTick->VAL;
    uint32_t wait_ticks = us * ticks_per_us;

    while (wait_ticks > 0) {
        uint32_t current = SysTick->VAL;
        // 处理递减和溢出：高位补24位掩码
        if ((start - current) & 0x00FFFFFF >= wait_ticks) {
            break;
        }
    }
}

void Delay_ms(uint32_t ms) {
    for (uint32_t i = 0; i < ms; i++) {
        Delay_us(1000);
    }
}

关键点剖析 🔍

1. 为何用 (start - current) & 0x00FFFFFF ？

因为 VAL 是 24 位寄存器，高 8 位保留。直接相减可能导致符号扩展错误（尤其是当发生回绕时）。通过按位与屏蔽高字节，确保只比较低 24 位。

2. 为什么不开启中断？

因为我们希望这是一个纯粹的阻塞式延时，中间不允许被打断。适用于对实时性要求不高但逻辑简单的场合。

3. 能有多准？

在 168MHz 下，1μs 对应 168 个 cycle，误差基本在几个 ns 级别，完全可以满足绝大多数传感器驱动、通信协议时序（如 DS18B20、I2C START 延时）等需求。

4. 缺点是什么？

❌ CPU 完全被占用 ，期间无法执行其他任务。
❌ 长时间延时会导致系统“假死”。

👉 所以它最适合用于启动阶段初始化外设时的短暂延时，或极简系统中的基础功能。

---

第二种：中断驱动 + 时间戳系统（前后台架构的灵魂）

当你开始写稍微复杂一点的程序，比如要做多个事件的状态监测、超时判断、非阻塞延时，这时候就得上中断了。

这也是 HAL 库中 HAL_GetTick() 的实现原理。

思路升级：让时间自己“走”

我们不再让 CPU 去“盯着”时间，而是让 SysTick 每隔 1ms “敲一下钟”，告诉系统：“又过去一毫秒啦！”。

然后我们用一个全局变量 g_tick 来记录自开机以来经过了多少毫秒。

#include "stm32f4xx.h"

volatile uint32_t g_tick = 0;

void SysTick_Handler(void) {
    g_tick++;  // 每1ms加1
}

void SysTick_Timestamp_Init(void) {
    uint32_t reload = (SystemCoreClock / 1000) - 1;  // 1ms中断一次

    SysTick->LOAD   = reload;
    SysTick->VAL    = 0;
    SysTick->CTRL   = SysTick_CTRL_CLKSOURCE_Msk | 
                      SysTick_CTRL_TICKINT_Msk |     // 使能中断
                      SysTick_CTRL_ENABLE_Msk;

    NVIC_SetPriority(SysTick_IRQn, 0);  // 推荐设为最高优先级之一
}

uint32_t GetTickCount(void) {
    return g_tick;
}

现在你可以轻松写出这样的代码：

uint32_t start = GetTickCount();
// 执行某些操作...
while ((GetTickCount() - start) < 100) {
    // 等待100ms，期间可以做别的事（如果有任务调度）
}

为什么说这是“前后台系统”的基石？💡

所谓前后台系统（Foreground-Background System），就是主循环处理业务逻辑（后台），中断处理定时、事件响应（前台）。

有了这个 GetTickCount() ，你就可以：

• ✅ 实现非阻塞延时
• ✅ 做超时检测（如 UART 等待数据）
• ✅ 多任务时间片模拟
• ✅ 按键消抖、LED 闪烁分离于主逻辑

而且最重要的是： CPU 不再空转等待 ！

举个真实案例：你在读取一个温湿度传感器，要求发送命令后等待最多 20ms 获取回应。

传统做法：

SendCommand();
Delay_ms(20);  // 卡住CPU 20ms
ReadResponse();  // 可能早就回来了，但你还得等完

改进做法：

SendCommand();
uint32_t timeout = GetTickCount() + 20;
while (!DataReady()) {
    if (GetTickCount() >= timeout) {
        break;  // 超时退出
    }
    // 可以在这里干点别的事，比如刷新显示、看门狗喂狗
}
ReadResponse();

这才是嵌入式编程应有的样子：高效、灵活、可控。

---

⚠️ 时间比较防翻转技巧：别让 32 位溢出毁掉一切！

这里有个超级重要的细节： g_tick 是 uint32_t ，最大值约 4294967295 ms ≈ 49.7 天 。

超过之后会清零重来。如果你这么写：

if (current_time > target_time) { ... }  // 错误！

一旦发生翻转，比如 current_time=1 , target_time=0xFFFFFFFF ，条件就会永远不成立，导致超时失效！

正确做法是使用 无符号整数差值法 ：

if ((current_time - target_time) < 0x80000000) {
    // 已到达目标时间
}

原理很简单：两个时间点之间的差值如果小于半个周期（即 2^31），说明已经到达；否则认为还没到。

这个技巧在 FreeRTOS、LwIP 等大型项目中广泛使用，务必掌握！

---

第三种：配合 FreeRTOS 使用（真正的多任务心脏 ❤️）

当你上了 RTOS，SysTick 的角色就彻底变了——它不再是你的工具，而是系统的“心跳引擎”。

FreeRTOS 默认使用 SysTick 作为 时钟节拍（tick）源 ，负责驱动任务调度、延时、时间队列等核心机制。

它是怎么接管的？

在 FreeRTOSConfig.h 中你会看到：

#define configCPU_CLOCK_HZ      168000000UL
#define configTICK_RATE_HZ      1000       // 每秒1000次tick → 1ms节拍

FreeRTOS 内核会在启动时自动调用 vPortSetupTimerInterrupt() 来配置 SysTick：

• 设置 LOAD = (configCPU_CLOCK_HZ / configTICK_RATE_HZ) - 1
• 使能中断
• 绑定 xPortSysTickHandler 作为 ISR

此时， 你不能再碰 SysTick 寄存器了！

否则会发生什么？

• ❌ HAL_Delay() 失效
• ❌ vTaskDelay() 不准甚至死锁
• ❌ 整个调度系统崩溃

所以记住这条铁律：

🛑 用了 FreeRTOS，就别动 SysTick 寄存器！

那我想获取时间怎么办？

✅ 用 RTOS 提供的接口：

TickType_t now = xTaskGetTickCount();         // 获取当前tick数
vTaskDelay(pdMS_TO_TICKS(100));               // 正确延时方式
xTaskGetTickCountFromISR();                   // 中断中安全调用

这些函数不仅线程安全，还考虑了 tick 溢出等问题，远比自己搞 g_tick++ 可靠得多。

高频节拍要不要设成 1kHz？🤔

虽然 1kHz 能带来更精细的任务调度，但也意味着每秒 1000 次中断！

每次中断都要保存上下文、切换栈、判断调度……这对性能是有损耗的。

建议：

• ✔️ 一般应用 → 100Hz（10ms 节拍）足够
• ✔️ 高实时性需求（如电机控制）→ 1kHz
• ❌ 不要盲目追求高频，评估实际负载

另外，在低功耗模式下，SysTick 默认会停止。如果你想让它继续运行（比如做唤醒定时器），需要额外配置 PWR 和 RCC，这部分属于高级玩法，暂不展开。

---

它在系统中的位置：时间金字塔的底座 🏗️

让我们画一张简化版的时间层级图：

        +------------------+
        |   Application    |
        |  Task Scheduling |
        |   Timeout Logic  |
        +--------+---------+
                 |
        +--------v---------+
        |     RTOS Kernel  |
        |   Tick Generator |
        +--------+---------+
                 |
        +--------v---------+
        |     SysTick      | ← 时间起点
        +--------+---------+
                 |
        +--------v---------+
        |    Clock Source  |
        |     HCLK (168M)  |
        +------------------+

你看， SysTick 是整个时间体系的源头 。上面所有的延时、调度、超时，最终都依赖它的一次次“滴答”。

这也解释了为什么它的优先级必须足够高——如果被某个低效中断长时间阻塞，整个系统的时间感知就会失真。

---

真实应用场景实战演练 🎯

场景一：按键消抖（Debounce）

常见的机械按键按下时会有抖动，持续几毫秒到几十毫秒不等。直接读取可能误判多次点击。

用 SysTick 提供的时间戳，轻松解决：

#define DEBOUNCE_DELAY 20

static uint32_t last_press_time = 0;
static uint8_t key_state = 0;

// 主循环中调用
void CheckKey(void) {
    if (GPIO_ReadKey() == KEY_PRESSED) {
        uint32_t now = GetTickCount();
        if ((now - last_press_time) > DEBOUNCE_DELAY) {
            if (!key_state) {
                key_state = 1;
                OnKeyPressed();  // 触发一次
            }
        }
        last_press_time = now;
    } else {
        key_state = 0;
    }
}

✅ 无阻塞、高响应、资源消耗极低。

---

场景二：测量代码执行时间（Profiling）

想知道某段函数跑了多久？可以用 VAL 寄存器做高精度采样：

uint32_t MeasureTime(void (*func)(void)) {
    uint32_t start = SysTick->VAL;
    func();
    uint32_t end = SysTick->VAL;

    // 注意：递减计数，所以 start >= end
    uint32_t elapsed = (start - end) & 0x00FFFFFF;
    float time_us = (float)elapsed / (SystemCoreClock / 1000000.0f);

    return (uint32_t)time_us;
}

例如测出某个 SPI 发送耗时 12.3μs，比预期慢？那就该优化了。

---

场景三：I2C 超时等待 ACK

很多 I2C 驱动死在等待 ACK 上，就是因为没加超时。

uint32_t timeout = GetTickCount() + 10;  // 最多等10ms
while (I2C_GetFlagStatus(I2C_FLAG_BUSY)) {
    if (GetTickCount() >= timeout) {
        I2C_SoftwareResetCmd(ENABLE);
        return ERROR_TIMEOUT;
    }
    // 可选：加入少量delay避免过度占用总线
}

再也不怕设备掉线导致整个系统卡死。

---

那些年踩过的坑：最佳实践清单 ✅

别以为会用了就万事大吉，下面这些坑我都替你踩过了：

1. 混用 HAL_Delay 和手动 SysTick → 翻车现场

// 错误示范！
HAL_Delay(10);
SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk;  // 手动关闭
// ……后面HAL_Delay()全失效

HAL_Delay 依赖 SysTick 中断，你一关，它就瘫痪了。

✅ 解决方案：要么全用 HAL，要么自己实现一套，不要混！

---

2. 调试时暂停导致时间错乱

JTAG 调试器暂停程序时，SysTick 也会停。当你恢复运行，发现 g_tick 差了好几千……

这在做超时逻辑时非常危险。

✅ 建议：长期计时可用 RTC 辅助；调试时注意观察时间连续性。

---

3. 忘记清除 VAL 寄存器 → 第一次延时不准

有些资料教你只改 LOAD，不清 VAL。结果第一次计数可能是随机值！

✅ 初始化时一定要：

SysTick->VAL = 0;

保证从干净状态开始。

---

4. 在中断里调用 Delay_us → 死循环警告！

void USART_IRQHandler(void) {
    if (error) {
        Delay_us(10);  // NO! 这会让中断永远出不去！
    }
}

Delay_us 是阻塞的，而中断上下文中不能卡住！

✅ 替代方案：记录时间戳 + 轮询标志位，或抛事件给主循环处理。

---

5. 移植到不同主频芯片时忘了改计算方式

有人把 168MHz 的 ticks_per_us = 168 写死成宏，换到 72MHz 的 F103 上照样用，结果延时变成两倍长。

✅ 正确做法：始终使用 SystemCoreClock / 1000000UL 动态计算！

---

结语：掌握它，你就掌握了系统的节奏感 🎶

回到最初的问题：为什么要学 SysTick？

因为它教会你一件事： 时间不是抽象的概念，而是可以精确掌控的资源 。

当你学会用 GetTickCount() 替代 Delay_ms() ，你的代码就开始有了“呼吸感”；
当你理解了 RTOS 如何依赖它进行调度，你就离真正的实时系统更近一步；
当你能在调试中准确测量一段代码的耗时，你就拥有了优化性能的第一手依据。

它很小，但很重要；
它简单，但从不容忽视。

下次你在写 HAL_Delay(1) 的时候，不妨停下来一秒想想：
此刻，那颗 24 位的计数器正在以 168MHz 的频率默默倒数，
为你的每一个“等待”，赋予意义。⏳

---

本文完。没有总结，因为真正的掌握，始于合上屏幕后的第一次动手尝试。🛠️
现在，去改你的 delay 函数吧。