简介面向STM32开发者的延时函数实现资源内容围绕STM32F1与STM32F4两款常见芯片展开解决开发中精确控制执行流程与定时操作的需求。资源将DELAY封装为独立延时库共2个文件1个C源文件与1个头文件压缩包仅848B轻量易移植C文件包含循环计数与硬件定时器相关实现头文件提供函数原型与宏定义便于直接加入工程调用。延时范围覆盖毫秒到微秒级上限分别达到477218ms与477218588us适合需要分段延时或高低速场景兼顾的开发者参考。目前已有3004人学习/下载说明该实现方案具备一定可复用性。通过学习可了解SysTick、通用定时器及高级定时器在延时设计中的差异也能快速套用现成延时接口减少重复编写底层代码的工作量。 搞嵌入式开发的人尤其是从STM32F1入门、后来跳到STM32F4的朋友几乎都会碰上一件看似谁都会、但细究起来坑不少的事——写延时函数。Stm32的延时函数随便搜一下就是一堆代码但为什么同一个delay放在F1上好好的搬到F4上就卡死或者时间不对为什么有人用HAL_Delay反而出问题这篇东西就是把F1和F4在延时函数上的底层逻辑、标准库与HAL库的差异、实际工程里最常见的坑一口气讲清楚适合刚把标准库用熟、准备上手F4的人也适合把delay用出阴影的调试老手随便翻翻。1. 先搞清楚F1和F4在延时这件事上到底哪里不一样1.1 内核不同延时底子不同延时函数最核心的硬件依赖是SysTick定时器也就是系统滴答。F1用的是Cortex-M3内核F4用的是Cortex-M4F内核这两个内核都有SysTick但时钟挂载关系不完全一样。F1系统时钟最高72MHzSysTick的时钟源通常是系统时钟的8分频也就是9MHzF4系统时钟最高168MHz或180MHzSysTick可以配置成使用系统时钟也可以使用系统时钟的8分频。这种差异直接导致一个问题如果你在F1上写的延时函数里硬编码了SysTick的频率是9MHz拿到F4上又不改延时时间就会完全不对。更常见的是很多人直接把F1的delay代码粘到F4工程里编译过、但延时时间只有理论值的几分之一根本没法用。这不是代码逻辑问题是内核时钟树导致的“水土不服”。1.2 系统时钟树的影响F1和F4的时钟树布局差别很大。F1的APB1最高36MHzAPB2最高72MHzSysTick挂在系统时钟或系统时钟/8上具体由SysTick控制寄存器的CLKSOURCE位决定。F4的APB1最高42MHz部分型号45MHz或50MHzAPB2最高84MHz或90MHz、100MHzAHB最高168MHzSysTick同样可以通过CLKSOURCE位选择时钟源。很多人没注意F4的SysTick时钟源如果选择8分频而系统时钟是168MHz那SysTick频率就是21MHz如果系统时钟是180MHz就是22.5MHz。延时1ms需要的重装载值分别是21000和22500。如果代码里写死72000F1在9MHz下延时8ms那整体延时时间就会漂移到8ms左右让你以为系统卡顿或中断异常。所以谈延时函数先说清楚时钟树是很有必要的。2. 动手实现前必须懂的SysTick原理2.1 SysTick是个啥SysTick是一个24位的向下递减计数器。它从你设置的重装载值LOAD寄存器开始每个SysTick时钟周期减1减到0时会触发一次中断如果使能了TICKINT同时把COUNTFLAG位置1然后自动从重装载值重新开始取决于配置。简单理解就像一个厨房定时器拧到指定刻度每秒滴答一次到底了就叫一声。延时函数本质上就是利用这个“到底了”的机制来测量时间。你要延时N毫秒就设置重装载值为“N毫秒对应的SysTick时钟周期数”然后等它从N跳变回0确认时间到。SysTick寄存器只有四个CTRL、LOAD、VAL、CALIB操作并不复杂。2.2 延时公式是怎么来的SysTick一个时钟周期的时间是1/SysTick_CLK。如果SysTick时钟频率是fHz重装载值为reload那么从reload减到0经历的时间就是reload * (1/f) 秒。反过来想要延时t秒重装载值就是t * f。举例F1系统时钟72MHzSysTick取系统时钟/8即9MHz。延时1msreload 0.001 * 9000000 9000。很多标准库例程里用的是SystemCoreClock / 8再除以1000就是这个来源。F4在168MHz下SysTick若取系统时钟源reload 0.001 * 168000000 168000若取8分频则是21000。这个公式是整个延时函数的核心务必自己推一遍不要死记。不同板子可能改了外部晶振或PLL配置SystemCoreClock值不同一旦重装载值算错所有延时全部报废。3. 标准库与HAL库延时函数详解3.1 经典标准库delay实现长啥样大家最熟悉的可能是正点原子或野火的delay函数思路大致是static u8 fac_us 0; static u16 fac_ms 0; void delay_init() { // 假设SystemCoreClock已经正确配置 SysTick_CLKSourceConfig(SysTick_CLKSource_HCLK_Div8); fac_us SystemCoreClock / 8 / 1000000; // 1us需要的计数次数 fac_ms (u16)fac_us * 1000; // 1ms需要的计数次数 } void delay_us(u32 nus) { u32 temp; SysTick-LOAD nus * fac_us; SysTick-VAL 0x00; SysTick-CTRL | SysTick_CTRL_ENABLE_Msk; do { temp SysTick-CTRL; } while((temp SysTick_CTRL_ENABLE_Msk) !(temp SysTick_CTRL_COUNTFLAG_Msk)); SysTick-CTRL ~SysTick_CTRL_ENABLE_Msk; SysTick-VAL 0x00; }看起来逻辑清晰实际用起来有几个隐藏问题。第一nus * fac_us这个乘法在传大数时可能溢出LOAD寄存器只有24位所以延时最大值是有限的。第二do while循环里没有关闭SysTick中断如果中断服务函数里也调用了延时会出现重入问题。第三读取CTRL的COUNTFLAG位这种方式在一个紧循环里是能用的但如果被更高优先级中断打断时间偏差会累积。3.2 HAL库HAL_Delay的实现与坑HAL库的做法和标准库不一样。HAL_Delay依赖一个全局变量uwTick这个变量由SysTick中断服务函数SysTick_Handler里调用HAL_IncTick()每1ms加1。HAL_Delay(ms)的实现大致是__weak void HAL_Delay(uint32_t Delay) { uint32_t tickstart HAL_GetTick(); uint32_t wait Delay; if (wait HAL_MAX_DELAY) { wait (uint32_t)(uwTickFreq); } while ((HAL_GetTick() - tickstart) wait) { } }注意这里的关键HAL_Delay的死循环只通过读取uwTick来判断时间如果在SysTick中断被屏蔽或者中断没触发的情况下uwTick不会更新HAL_Delay就会死等表现为卡死。这就是很多人F1裸机没问题、上了FreeRTOS或者关闭中断后调用HAL_Delay就卡住的根本原因。另外HAL_Delay是不安全的在中断服务函数里调用它要特别小心因为它的优先级比当前中断高或相同的时候SysTick中断无法抢占uwTick不增长直接卡死。老手一般会在中断里用HAL_GetTick()做非阻塞延时而不是直接调用HAL_Delay。3.3 F1和F4移植时最容易忽视的时钟宏无论是标准库还是HAL库延时函数都依赖SystemCoreClock这个全局变量。F1的SystemCoreClock在system_stm32f1xx.c里根据宏定义计算F4的在system_stm32f4xx.c里计算。如果你从F1工程迁移到F4工程光改芯片型号不更新时钟初始化代码SystemCoreClock可能还是按72MHz算但实际系统已经跑到168MHz了延时函数就严重不准。我在实际项目里见过有人把F1的定时器延时代码直接搬进F4导致串口波特率、PWM频率整体错乱。排查到最后发现是SystemCoreClock的值没更新而所有基于它的底层模块全部跟着错。所以移植后第一件事打印或者调试看SystemCoreClock是不是和目标主频一致这个习惯能省一大半的时间。4. 实战一个兼容F1和F4的延时模块怎么写4.1 用宏把时钟差异包起来与其维护两套delay代码不如做一个统一的延时模块用条件编译把F1和F4的时钟差异包起来。核心思路是让底层获取SysTick时钟频率而不是写死。以标准库为例可以这么做#if defined(STM32F10X_HD) || defined(STM32F10X_MD) #define SYSTICK_CLK (SystemCoreClock / 8) #elif defined(STM32F40_41xxx) || defined(STM32F427_437xx) #define SYSTICK_CLK SystemCoreClock #endif具体选择SystemCoreClock还是8分频取决于你用SysTick_CTRL_CLKSOURCE_Msk怎么配置。F4的SysTick可以吃系统时钟F1建议用8分频因为F1的SysTick如果吃72MHz的HCLK重装载值挺大但还能接受只是功耗和中断频率会高一点。F4用168MHz也没问题24位计数器够用。重装载值计算函数如下void delay_init(void) { SysTick_CLKSourceConfig(SYSTICK_CLK_SOURCE); g_fac_us SYSTICK_CLK / 1000000; g_fac_ms g_fac_us * 1000; }这样在F1和F4上就只需要改宏定义不用动延时函数体。4.2 防重入和临界区保护裸机环境下延时函数最怕的是被中断打断后出现不可重入。比如定时器中断里调用了delay_us然后主循环里也调用了delay_us两个调用同时操作SysTick的LOAD和VAL就会互相覆盖导致某一方延时时间错误甚至死循环。解决办法是进入延时前关中断退出前恢复中断状态。标准做法void delay_us(u32 nus) { u32 temp; __disable_irq(); SysTick-LOAD nus * g_fac_us; SysTick-VAL 0; SysTick-CTRL | SysTick_CTRL_ENABLE_Msk; do { temp SysTick-CTRL; } while((temp SysTick_CTRL_ENABLE_Msk) !(temp SysTick_CTRL_COUNTFLAG_Msk)); SysTick-CTRL ~SysTick_CTRL_ENABLE_Msk; SysTick-VAL 0; __enable_irq(); }但这样会带来新的问题如果延时时间长比如10ms关中断期间所有其他中断都无法响应比如串口接收中断可能丢数据。所以这种暴力保护方式只适用于短延时长延时最好使用基于中断计数的方案或者干脆用定时器做多组延时。4.3 在RTOS下延时函数的变化如果你上了FreeRTOS情况又不一样。FreeRTOS自带vTaskDelay它根据系统tick来挂起任务让出CPU给更高优先级任务或空闲任务。此时如果用裸机delay函数做阻塞延时会浪费CPU而且SysTick中断被FreeRTOS接管了裸机的SysTick配置会被覆盖delay_init之后SysTick可能又被FreeRTOS重新初始化了。正确的做法是应用代码里尽量不要使用裸机延时尤其是长延时改用它提供的vTaskDelay或vTaskDelayUntil。短延时微秒级偶尔可以用但要确保SysTick没被FreeRTOS改配置。如果必须在FreeRTOS下做微秒延时建议用DWT循环计数器或者开启另一个定时器避免和SysTick冲突。5. 常见问题排查实录5.1 delay卡死的几大元凶遇到“delay卡死”最优先检查的就是SysTick中断有没有正常触发。在HAL库工程里如果你重写了SysTick_Handler却忘了调用HAL_IncTickHAL_Delay会永久死循环这是新手最容易踩的坑。标准库工程里如果你把SysTick配置成了中断模式却在中断服务函数里加了过多耗时操作也会导致主循环读取COUNTFLAG时已经错过了信号程序看起来就像卡住了。第二常见的原因是中断优先级配置。SysTick中断优先级如果被设置成比某个正在执行的中断优先级还低而你又在该中断里调用HAL_Delay那SysTick中断永远执行不了uwTick不更新直接卡死。所以HAL库的UART、SPI、I2C回调函数里不要随便调用HAL_Delay。第三是编译优化级别的问题。有些延时循环依赖代码执行时间如果开-O2或-O3优化原本的循环可能被编译器优化掉导致延时时间骤减或行为异常。SysTick方案虽然不依赖指令周期但如果使用do while读取CTRL寄存器编译器也可能做出意外优化建议把寄存器变量声明为volatile或者查看反汇编确认循环没被干掉。5.2 用逻辑分析仪校准延时函数写完延时函数之后不要凭感觉说延时准最好用逻辑分析仪或示波器实测。最简单的方法让一个GPIO翻转延时一段时间再翻转然后用逻辑分析仪抓取波形频率或脉宽。我常用的是把一个IO口拉高delay_ms(1)再拉低delay_ms(1)循环。测量波形高电平时间如果是1.000ms说明延时准。如果不准先看SystemCoreClock再看SysTick的时钟源选择。曾经我遇到一个奇怪问题F1延时实测总是偏大5%查了半天发现外部晶振不是标称的8MHz而是7.68MHz的定制晶振导致整个时钟频偏。这种硬件引起的误差软件怎么改都没用只能用库里的时钟校准功能或换晶振。5.3 实测数据与建议下面是我在实际调试中用逻辑分析仪测过的几种延时方式环境分别是F103ZET672MHz、F407ZET6168MHz测试延时100ms方案F1实测F4实测备注标准库原理延时读COUNTFLAG99.996ms99.984ms误差极小受中断影响小标准库SysTick中断计数变量100.02ms100.03ms受中断响应延迟影响略有波动HAL_Delay默认Systick中断100.00ms100.00ms但中断里调用容易卡死纯软件循环for循环NOP不稳定不稳定优化等级不同差异极大从表格能看出基于SysTick的延时精度绝对够用。延时不准的问题90%出在时钟配置而不是延时实现本身。6. 我实际用下来觉得最顺手的几个小技巧写延时函数时有个小技巧不要只提供一个阻塞延时再封装一个非阻塞的delay_until或者“时间片轮询”版本。比如你想让一个LED以1s闪烁同时又要响应按键直接在主循环里阻塞delay 1s按键灵敏度就废了。用uwTick或自己的tick变量做判断每轮主循环检查差值就能实现异步延时这比整天调中断舒服得多。还有如果你在两个型号之间频繁移植建议把延时文件单独成模块不要和主逻辑混在一起。我用的是bsp_delay.c里面只放延时相关代码工程换芯片时只需要改头文件里的时钟宏。另外在调试器里单步执行时延时函数会由于被调试器强行暂停而变长这是正常现象别以为是程序卡住了。特别是使用ST-Link单步调试带HAL_Delay的代码很多人会误以为进了死循环其实只要连续运行就恢复正常。用SysTick做延时还要注意一个细节读COUNTFLAG标志位后必须手动清除或者在读取前清VAL寄存器。不清理的话下一次循环可能立刻读到旧标志造成延时时间变成0。标准库的delay版本通常会在每次进入函数时清VAL这个操作不要省。最后再说个大家容易忽略的点如果你的固件里开了很多中断尤其是有快中断嵌套延时函数时间会略微变长因为SysTick的无效时钟周期变多了。对普通LED闪烁、按键消抖来说无所谓但如果在做一些对时序敏感的协议模拟比如单总线时序最好用关中断的微秒延时并且测量实际波形来修正参数。我自己吃过大亏用F407模拟DHT11时序一开始用SysTick延时结果DHT11死活读不到数据后来换成关中断延时就稳定了。所以说延时函数没有万能方案理解原理才能根据场景选对实现。本文还有配套的精品资源点击获取