1. 项目概述：从一行代码窥探STM32精准延时的核心

在STM32的裸机开发中，delay.c文件几乎是每个工程里都会出现的“老朋友”。很多初学者第一次看到fac_us = SystemCoreClock / 8000000;这行代码时，可能会感到困惑：这个8000000是怎么来的？为什么不是别的值？这个fac_us又扮演着什么角色？今天，我们就来彻底拆解这行看似简单、实则蕴含了STM32时钟系统与SysTick定时器核心原理的代码。理解它，不仅能让你写出更精准的延时函数，更能让你对STM32的时钟管理和定时器工作机制有更深刻的认识。无论你是刚接触STM32的新手，还是想巩固底层知识的老鸟，这篇深度解析都将为你提供清晰的思路和可直接复用的理解框架。

2. 核心原理：SysTick定时器与微秒延时的关系

要理解fac_us，我们必须先认识STM32中的SysTick定时器。SysTick是一个集成在Cortex-M内核中的24位递减计数器，它独立于外设定时器（如TIM1-TIM14），主要用途是为操作系统（如FreeRTOS）提供“心跳”（系统节拍），或者为我们提供精准的延时。它的时钟源可以是内核时钟（HCLK）或HCLK/8，具体由配置决定。

2.1 SysTick的工作机制与计数逻辑

SysTick定时器的工作流程非常直接：我们给它一个初始值（重装载值LOAD），它便从这个值开始递减计数，每经过一个时钟周期，计数值减1。当计数值减到0时，会触发一个中断（如果使能了的话），并且计数器会自动从LOAD值重新开始下一轮递减。这个“从LOAD减到0”所花费的时间，就是我们能控制的一个“节拍”周期。

那么，如何用这个节拍来实现微秒（µs）级的延时呢？关键在于建立“时钟周期数”与“时间”的换算关系。我们知道，时间 = 计数次数 / 时钟频率。如果SysTick的时钟频率是SysClkHz（即每秒SysClk个时钟周期），那么产生1微秒（10^-6秒）的延时所需要的时钟周期数就是：SysClk / 1000000。这个计算出来的数值，就是我们要的“微秒因子”，也就是fac_us。它表示：SysTick的时钟每跳动fac_us次，时间就过去了1微秒。

2.2 标准库中8000000的由来与常见误区

现在回到那行关键的代码：fac_us = SystemCoreClock / 8000000;。这里的SystemCoreClock通常就是系统核心时钟SYSCLK，对于STM32F1系列，常见值为72MHz（72,000,000 Hz）。如果直接套用公式fac_us = SYSCLK / 1000000，那么对于72MHz系统，fac_us应该是72。但代码里除以的是8000000，结果是9（72M / 8M = 9）。为什么？

核心原因在于：正点原子提供的标准库例程中，默认将SysTick的时钟源配置为HCLK/8，而不是HCLK。

在STM32标准外设库的misc.c文件中，SysTick_Config(uint32_t ticks)函数内部，默认会选择AHB时钟（即HCLK）的8分频作为SysTick的时钟源。这是一种非常常见的配置，原因有二：

1. 降低功耗与噪声：使用分频后的较低频率时钟，可以减少内核高频时钟带来的噪声和功耗。
2. 扩大定时范围：SysTick是24位计数器，最大重装载值为0xFFFFFF（约1677万）。如果使用72MHz时钟，最长定时只有16777216 / 72e6 ≈ 0.233秒。而使用72MHz/8=9MHz时钟后，最长定时可达16777216 / 9e6 ≈ 1.86秒，范围更广。

因此，当SystemCoreClock = 72MHz时，SysTick的实际工作时钟频率是72MHz / 8 = 9MHz。那么，产生1微秒所需的时钟周期数就是：9MHz / 1,000,000 = 9。这个“9”正是通过72,000,000 / 8,000,000计算得来的。这里的8,000,000，本质上就是1,000,000 * 8，即“将微秒换算系数1,000,000乘以时钟分频系数8”。

注意：这是一个非常容易混淆的点。fac_us的本质是“SysTick实际时钟频率除以1,000,000”。而代码中的SystemCoreClock/8000000，是“系统核心时钟除以**（1,000,000 * 分频系数）**”的合并写法。理解时一定要区分“系统时钟”和“SysTick工作时钟”。

3. 代码深度解析与不同场景下的计算

让我们深入到delay.c文件的典型实现中，看看fac_us是如何被使用的，并探讨在不同时钟配置下该如何计算这个值。

3.1 典型delay_us()函数实现剖析

一个基于SysTick查询方式的delay_us(uint32_t nus)函数通常如下步骤实现：

1. 计算所需的总计数次数：temp = nus * fac_us;。例如，要延时10µs，且fac_us=9，则temp=90。这意味着我们需要让SysTick累计计数90个时钟周期。
2. 配置SysTick：将SysTick的重装载值LOAD设置为temp-1（因为从N减到0需要N+1个时钟周期？这里需要小心，标准库的SysTick_Config函数认为从LOAD减到0需要LOAD+1个周期，所以我们的计算要与之匹配），并启动计数器。
3. 等待计数完成：在一个循环中不断读取SysTick的当前值VAL，直到它变为0。当VAL==0时，说明从LOAD到0的计数过程已经完成，预定的延时时间已到。
4. 关闭SysTick：延时结束后，关闭SysTick定时器以节省功耗。

这里的关键是第1步的乘法。fac_us在这里充当了一个“比例系数”，将“微秒”这个时间单位，转换成了“SysTick时钟周期数”这个机器可以理解并计数的单位。

3.2 不同时钟配置下的fac_us计算表

你的项目时钟配置可能不是72MHz，SysTick的时钟源也可能不同。下表列出了几种常见情况下的fac_us计算方法：

如何确定你的SysTick时钟源？查看你的工程初始化代码，通常在main()函数之前调用的SystemInit()函数会设置系统时钟。然后，检查你调用SysTick_Config()或delay_init()的地方。在标准库中，SysTick_Config()函数内部有一行代码：SysTick->CTRL &= ~SysTick_CTRL_CLKSOURCE_Msk;，这行代码清除了时钟源选择位，即选择了AHB/8。如果你在调用SysTick_Config()之前，执行了SysTick->CTRL |= SysTick_CTRL_CLKSOURCE_Msk;，那么就是选择了AHB（即HCLK）作为时钟源。

3.3 HAL库与LL库中的差异处理

如果你使用的是STM32CubeMX生成的HAL库或LL库工程，情况略有不同。HAL库提供了一个通用的HAL_Delay()函数，它通常也是基于SysTick实现的。在CubeMX的时钟配置中，有一个关键参数叫“Timebase Source”，默认就是SysTick。HAL库会通过HAL_Init()函数，自动根据你配置的HCLK频率来初始化SysTick，并设置一个1ms的中断（即uwTick每毫秒加1）。

在HAL库环境下，如果你想自己实现一个delay_us函数，逻辑是相同的，但获取时钟频率的方式更规范。你应该使用HAL_RCC_GetHCLKFreq()或HAL_RCC_GetSysClockFreq()来获取准确的时钟频率，然后根据你的SysTick时钟源选择（查看SysTick->CTRL寄存器的CLKSOURCE位）来计算fac_us。

// HAL库环境下的一种计算思路 uint32_t sysclk_freq = HAL_RCC_GetSysClockFreq(); // 获取系统时钟频率 uint32_t systick_clk_source = (SysTick->CTRL & SysTick_CTRL_CLKSOURCE_Msk); uint32_t fac_us; if(systick_clk_source == SysTick_CTRL_CLKSOURCE_Msk) { // 时钟源 = HCLK fac_us = sysclk_freq / 1000000; } else { // 时钟源 = HCLK / 8 fac_us = sysclk_freq / 8000000; }

4. 精准延时实现与高级应用技巧

理解了原理和计算，我们来看看如何实现一个稳健、精准的延时函数，并探讨一些高级应用和常见陷阱。

4.1 一个健壮的delay_us函数实现示例

下面是一个结合了前面原理的、相对健壮的delay_us函数实现（基于查询方式，非中断）：

static uint32_t fac_us = 0; // 微秒延时基数 void delay_init(uint8_t sysclk_source) { /* 假设系统时钟已配置好，例如72MHz */ uint32_t system_core_clock = 72000000; // 应替换为实际获取时钟的函数，如 SystemCoreClock /* 根据SysTick时钟源配置计算fac_us */ // 检查SysTick控制寄存器，确定时钟源是HCLK还是HCLK/8 // 标准库默认配置为HCLK/8，以下代码按此默认处理 // 如果你修改了时钟源，需要同步修改这里 fac_us = system_core_clock / 8000000; /* 可选：初始化一个1ms的SysTick中断，用于delay_ms */ // SysTick_Config(system_core_clock / 1000); // 注意：此处的重装载值是基于系统时钟的，用于产生1ms中断 // 但fac_us的计算仍需基于SysTick的实际工作时钟（HCLK/8） } void delay_us(uint32_t nus) { uint32_t ticks; uint32_t told, tnow, tcnt = 0; uint32_t reload = SysTick->LOAD; // 获取SysTick重装载值（24位最大值） /* 计算需要等待的SysTick时钟周期总数 */ ticks = nus * fac_us; /* 防止要求的延时时间超过SysTick单次最大定时范围 */ if(ticks > reload) { // 对于超长延时，可以分段处理或使用delay_ms组合，这里简单处理为最大延时 ticks = reload; } told = SysTick->VAL; // 读取进入函数时的当前计数值 while(1) { tnow = SysTick->VAL; /* 判断是否发生了一次重装载（VAL从0跳变到LOAD）*/ if(tnow != told) { /* 如果当前值小于上次值，说明在正常递减 */ if(tnow < told) { tcnt += told - tnow; } /* 如果当前值大于上次值，说明发生了重装载（从0回到了LOAD）*/ else { tcnt += told + (reload - tnow); } told = tnow; /* 累计的时钟周期数已经达到或超过要求值，则延时结束 */ if(tcnt >= ticks) { break; } } } }

这个实现的关键在于while循环中的时间累计逻辑。它考虑了SysTick计数器在延时期间可能发生的重装载（即从0跳回LOAD值），通过累加tcnt来准确统计总共流逝的SysTick时钟周期数，从而提高了在SysTick中断使能环境下（如RTOS运行时）的延时准确性。

4.2 提高延时精度的关键因素与校准

虽然SysTick是内核定时器，精度很高，但延时精度仍受以下因素影响：

1. 系统时钟精度：如果使用外部晶振（HSE），精度较高（通常±10~50ppm）。如果使用内部RC振荡器（HSI），精度较差（典型±1%），会导致延时有偏差。
2. 函数调用开销：进入和退出函数、读取寄存器等操作本身消耗CPU周期，这会在短延时（如几个微秒）中引入显著误差。对于极短延时（<5µs），通常建议使用简单的__NOP()指令空循环或直接操作寄存器来实现。
3. 中断干扰：如果使能了SysTick中断或其他高优先级中断，会打断delay_us函数的查询循环，导致延时变长。在要求严苛的场合，需要在延时前关闭中断，延时后再开启。

简易校准方法：如果需要非常精确的延时，可以借助一个高精度示波器或逻辑分析仪。编写一个程序，让一个GPIO引脚在延时前后翻转。测量实际产生的脉冲宽度，与理论延时时间对比，计算出一个校准系数，在计算ticks时乘以或除以这个系数。

4.3 在RTOS与中断环境下的使用注意事项

在实时操作系统（如FreeRTOS）中，SysTick通常被系统用作时基（xPortSysTickHandler）。此时，绝对不能再使用上面那种查询方式的delay_us函数，因为SysTick的中断会不断发生，其VAL寄存器会被系统重置，导致你的延时计算完全混乱。

在RTOS中的解决方案：

1. 使用RTOS提供的延时API：如FreeRTOS的vTaskDelay()或vTaskDelayUntil()。这些是毫秒级延时。
2. 使用其他通用定时器：如果需要微秒级延时，可以启用一个未被使用的硬件定时器（如TIM2、TIM3等），配置为单次触发模式，来实现精准延时。这是RTOS下最可靠的做法。
3. 使用CPU指令延时：对于纳秒到几微秒级的极短延时，可以使用汇编指令（如DMB,DSB,ISB）或编译器内置的__NOP()循环。但这种方法与CPU频率强相关，移植性差。

在中断服务程序中的使用： 在中断服务程序（ISR）中，应避免使用任何可能引起阻塞的延时函数，尤其是基于查询的长延时。这会严重破坏系统的实时性。ISR中的延时需求，应通过设置标志位，在主循环或任务中处理，或者使用定时器的硬件自动触发功能。

5. 常见问题排查与调试技巧实录

在实际开发中，关于delay函数的问题层出不穷。下面我整理了几个最典型的问题和排查思路，这些都是从实际项目中踩坑总结出来的经验。

5.1 延时函数卡死或时间严重不准

现象：调用delay_us(100)后，程序似乎卡住了，或者实际延时远大于100微秒。排查步骤：

1. 检查fac_us计算是否正确：这是最常见的原因。首先确认你的SystemCoreClock值是否与实际的系统时钟频率一致。在SystemInit()之后，打印或调试查看SystemCoreClock全局变量的值。然后，确认你的delay_init函数中fac_us的计算公式是否与SysTick的时钟源匹配（HCLK还是HCLK/8）。
2. 检查SysTick是否被意外关闭或修改：有些库函数或中间件可能会重新配置甚至关闭SysTick。确保在你的delay_us函数执行期间，没有其他代码操作SysTick->CTRL寄存器。可以在delay_us函数开头和结尾读取该寄存器，比较是否发生变化。
3. 检查中断干扰：如果使能了SysTick中断或其他高优先级中断，你的查询循环会被打断。尝试在delay_us函数内部临时关闭全局中断（__disable_irq()），延时后再打开（__enable_irq()），看是否恢复正常。注意：这种方法会破坏系统实时性，仅用于调试。
4. 检查LOAD重装载值：在delay_us函数中，我们读取SysTick->LOAD作为最大值。如果其他地方修改了LOAD（例如RTOS初始化），会导致我们的计算基准错误。确保SysTick的配置是稳定的。

5.2 短延时（<10us）误差巨大

现象：延时1微秒，实际可能达到好几微秒甚至十几微秒。原因分析：对于极短的延时，函数调用开销、循环判断开销占据了主要时间。delay_us(1)需要执行的指令周期数可能已经超过了1微秒对应的CPU周期数。解决方案：

• 使用NOP循环：对于固定的、极短的延时，直接使用内联汇编或__NOP()指令构建一个精确的循环。你需要根据CPU频率计算每个循环的耗时。

  // 粗略实现，需根据实际CPU频率校准 #define DELAY_US_1() do { \ __NOP(); __NOP(); __NOP(); __NOP(); __NOP(); \ __NOP(); __NOP(); __NOP(); __NOP(); __NOP(); \ } while(0)

• 使用DWT时钟周期计数器：Cortex-M3/M4/M7等内核包含一个数据观察点与跟踪（DWT）单元，其中有一个32位的时钟周期计数器（CYCCNT）。启用后，它可以自由运行，提供高精度的时钟周期计数，非常适合做高精度延时和性能分析。这是实现纳秒/微秒级延时最精准的方法。

  // 初始化DWT void DWT_Init(void) { CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; // 使能跟踪 DWT->CYCCNT = 0; // 清零计数器 DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; // 使能计数器 } // 基于DWT的微秒延时 void delay_us_dwt(uint32_t us) { uint32_t start_tick = DWT->CYCCNT; uint32_t delay_ticks = us * (SystemCoreClock / 1000000); // 注意这里用的是系统时钟，不是分频后的 while((DWT->CYCCNT - start_tick) < delay_ticks); }

5.3 与RTOS或其它任务/中断冲突

现象：在RTOS中加入了delay_us后，系统运行不稳定，任务调度异常。根本原因：如前所述，查询式delay_us会独占CPU，在延时期间阻止了其他低优先级任务运行，甚至可能阻止了SysTick中断（如果关了中断），导致RTOS的心跳丢失，任务无法调度。黄金法则：在RTOS中，永远不要使用基于查询的忙等待延时函数。如果需要，使用硬件定时器。

5.4 延时函数在不同优化等级下行为不一致

现象：在调试模式（-O0）下延时正常，切换到发布模式（-O2, -Os）后，延时时间变短或程序出错。原因分析：编译器优化可能会重排或删除它认为“无效”的代码。例如，在查询SysTick->VAL的循环中，如果编译器认为该值没有被其他代码修改，可能会将其优化成只读取一次，导致死循环。解决方案：将用于循环判断的变量声明为volatile类型，告诉编译器这个变量可能被硬件或其他线程意外改变，禁止对其进行优化。

volatile uint32_t *systick_val = (volatile uint32_t *)&SysTick->VAL; told = *systick_val; while(1) { tnow = *systick_val; // ... 其余逻辑 }

在delay_us函数中，SysTick->VAL、told、tnow、tcnt这些与硬件寄存器或循环判断紧密相关的变量，最好都使用volatile修饰，或者确保它们被当作volatile来处理（如通过指针强制转换）。

理解fac_us = SystemCoreClock / 8000000这行代码，是打开STM32精准定时世界的一把钥匙。它串联起了系统时钟、内核外设、软件设计三个层面。在实际项目中，我个人的习惯是：对于裸机简单应用，使用标准库的查询式延时并注意时钟源配置；对于复杂应用或RTOS，坚决使用硬件定时器来实现所需精度的延时；对于极短延时（开关传感器、通信协议时序），则使用DWT或校准后的NOP循环。最关键的是，永远清楚你使用的延时函数背后的时钟源和可能带来的阻塞影响，这样才能写出既稳定又高效的嵌入式代码。