1. 从一次跑偏的 LED 闪烁说起定时器到底在“数”什么很多刚接触 STM32 的同学都有过这种经历照着教程配好了定时器算好了分频系数和自动重装载值满心以为能精确到微秒级结果示波器一端上去——闪烁周期差了十万八千里甚至干脆不工作。这时候资料里翻来翻去都是“TIMx 的时钟来自 APBx”但到底怎么来的、为什么 F1 和 F4 算出来不一样、那个诡异的“×2”又是从哪冒出来的没人给你掰开揉碎讲清楚。我自己刚入行那会儿也被这个坑绊过。记得第一次做 1ms 定时中断用的 STM32F103按照网上的模板抄了一段代码PSC 配 71ARR 配 999心想 72MHz 主频除下来不就是 1ms 吗可实际量出来的波形偏偏不是那么回事。从那时起我就意识到一个核心问题定时器本身没有“时间”概念它只会数脉冲所谓的毫秒、微秒全靠“一个脉冲代表多长时间”这个基准来换算。而这个基准就是标题里问的“时间基准”。换句话说你配置定时器时写的所有数字本质都是在给它设定“数到多少算一轮”以及“每数一下花多久”。前者是 ARR 和 CNT 的事后者才是时间基准的事。这个基准从哪来、中间经过了哪些环节、为什么不同系列芯片算出来的结果不一样就是这篇文章要一次性讲透的东西。这篇文章适合三类人正准备用定时器做延时、PWM、输入捕获的新手已经会用 CubeMX 生成代码但遇到“定时不准”问题的开发者以及想彻底搞懂 STM32 时钟树不再靠试错调参的老手。读完之后你会明白为什么有些代码换颗芯片就要重新算分频也会掌握一套自己推导定时时间的完整方法。2. 时间基准的真正源头时钟树里的那一串“分频-倍频”链路先说结论STM32 定时器的“时间基准”本质上就是一个脉冲方波定时器数这个方波的边沿来推进计数。这个方波从哪来一路追溯上去源头是芯片内部的振荡器或者外部晶振中间经过 PLL 倍频、AHB 预分频、APB 预分频最后才送到定时器模块。链路里的每一级都在改变频率任何一级理解错了你算出来的定时时间就不可能对。2.1 源头选择HSI、HSE 还是 PLLSTM32 的时钟源主要有三个HSI高速内部振荡器芯片内置上电就能用但精度一般。F1 系列是 8MHzF4 系列也是 16MHz温度漂移比晶振大。拿它当定时器基准做要求不高的功能凑合做精确时序就危险。HSE高速外部振荡器外接晶振常见 8MHz、25MHz。精度高、稳定是工业产品和追求时序精度的项目的首选。用示波器测 PWM 频率时偏差基本来自晶振本身的误差。PLL锁相环把 HSI 或 HSE 倍频上去得到系统主频 SYSCLK。F103 最高 72MHzF407 能到 168MHzF429 能到 180MHz。PLL 是绝大多数应用的最终主频来源。有人会问为什么不直接用 HSI 当主频省得配 PLL因为 HSI 频率低、漂移大而且 PLL 可以输出更高的系统时钟让 CPU 跑得更快。但高主频不意味着定时器一定准——PLL 的输出要经历后面那一串分频链路任何一个分频配置改变了送到定时器的频率就跟着变。2.2 AHB 与 APB 预分频定时器时钟的“命运分水岭”系统主频 SYSCLK 确定后会先经过 AHB 预分频器得到 HCLK再经过 APB1/APB2 预分频器得到 PCLK1/PCLK2。这里就是新手最容易懵的地方。关键规则是定时器时钟 TIMxCLK 不等于 APB 总线时钟 PCLKx。当 APB 预分频系数为 1 时TIMxCLK 等于 PCLKx当 APB 预分频系数大于 1 时TIMxCLK 等于 PCLKx 的 2 倍。这个“大于 1 就翻倍”的规则是 STM32 设计上为了保证定时器能拿到足够高的工作频率而特意做的。绝大多数默认工程里APB1 预分频都不止 1所以定时器时钟几乎总是 APB 总线的两倍。很多人抄代码只照抄了 APB 配置没意识到这条规则算出来的分频系数自然全错。我拿 F103 举个具体例子。系统主频 72MHzAHB 分频 1所以 HCLK 也是 72MHz。APB1 预分频设为 2则 PCLK1 36MHz按规则 TIM2~TIM7 这些挂在 APB1 上的定时器时钟是 PCLK1 的 2 倍也就是 72MHz。APB2 预分频设为 1则 PCLK2 72MHzTIM1、TIM8 这些挂在 APB2 上的高级定时器时钟直接就是 72MHz。这个案例的关键点在于APB1 反而成了“定时器时钟最高的地方”。哪怕 PCLK1 总线频率只有 36MHz定时器照样能拿到 72MHz——这就是翻倍规则的威力。2.3 一条链路算到底从 8MHz 晶振到定时器时钟的完整推导把上面这些串起来完整推导一遍。假设 F103 外部接了 8MHz 晶振PLL 倍频 9 倍得到 72MHz SYSCLKAHB 分频 1APB1 分频 2APB2 分频 1环节频率计算依据HSE8 MHz外部晶振SYSCLK72 MHz8 × PLL 倍频系数 9HCLK72 MHzAHB 预分频 1PCLK136 MHzAPB1 预分频 2挂 APB1 的 TIMxCLK72 MHzAPB1 分频 1翻倍PCLK272 MHzAPB2 预分频 1挂 APB2 的 TIMxCLK72 MHzAPB2 分频 1不翻倍看到没同样是 72MHz 主频挂在 APB1 上的 PCLK1 只有 36MHz但定时器时钟反而恢复到 72MHz。如果你在代码里拿 PCLK1 当定时器时钟去算结果就对不上。这种细节就是“看起来一样的代码别人跑得准你跑不准”的根源。F4 系列同理但数值不同比如 F407 主频 168MHz 时APB1 预分频 4 得到 42MHz PCLK1翻倍后挂 APB1 的定时器时钟变成 84MHzAPB2 预分频 2 得到 84MHz PCLK2翻倍后挂 APB2 的定时器时钟变成 168MHz。规律没变数值全换了这就是为什么同一套算分频的思路在不同芯片上要重新走一遍。3. 从 TIMxCLK 到 CNT 计数PSC、ARR、CNT 三兄弟的分工逻辑时钟源搞清楚之后还得把定时器内部的工作机制吃透。定时器内部的“时间”是由三个寄存器一起决定的PSC预分频、ARR自动重装载、CNT计数器。它们的配合关系是理解一切定时器应用的核心。3.1 PSC 怎么“磨碎”时钟一个脉冲到底代表多久PSC 的作用是把 TIMxCLK 再进行一次分频得到一个低频的计数时钟 CK_CNT。这个频率的计算公式是CK_CNT TIMxCLK / (PSC 1)为什么是 PSC1 而不是 PSC因为 PSC 寄存器值是从 0 开始编号的写 0 表示不分频写 71 表示 72 分频。这个“1”是所有的坑里最容易踩的。拿 F103 的 72MHz 来说PSC 0CK_CNT 72MHz一个计数脉冲约 13.9nsPSC 71CK_CNT 1MHz一个计数脉冲正好 1μsPSC 7199CK_CNT 10kHz一个计数脉冲 100μs这里有个很重要的直觉PSC 决定了定时器的“分辨率”。PSC 越小单个脉冲时间越短定时精度相对越高但计数器计满一轮需要的脉冲数也越多ARR 就得配大PSC 越大分辨率下降但 ARR 可以配小。实际工程里通常先定 PSC 让 CK_CNT 落到一个整数频率比如 1MHz再用 ARR 决定定时时长这样代码可读性最好也方便换算。3.2 ARR 和 CNT 的配合方式向上计数模式全流程演示ARR 是自动重装载值CNT 是当前计数值。向上计数模式下CNT 从 0 开始每个 CK_CNT 脉冲加 1加到 ARR 后触发更新事件CNT 归零重新开始。一次完整的“0 → ARR → 溢出 → 0”就是一轮定时。定时周期的公式是定时时间 (ARR 1) × (PSC 1) / TIMxCLK同样有 ARR1 的问题。因为 CNT 是数到 ARR 才清零从 0 到 ARR 一共经过了 ARR1 个脉冲。想定时 1ms、TIMxCLK 为 72MHz、PSC 设为 71CK_CNT 1MHz那么 ARR 999因为 (9991) / 1MHz 1ms。写代码的时候 ARR 寄存器的值就是 999不是 1000。我把这个公式拆开用表格列一下不同定时时长的典型配比TIMxCLK 72MHz目标时间PSCARRCK_CNT实际时间1μs7111MHz2μs不对1μs07172MHz1μs1ms719991MHz1ms100ms719999910kHz100ms1s7199999910kHz1s注意第一行那个陷阱PSC71、ARR1 算出来是 2μs 而不是 1μs。因为公式是 (11) × (711) / 72MHz 2μs。PSC 和 ARR 的任何配比问题最终都会落到“别忘了 1”这个点上。3.3 更新事件和更新中断你写的回调函数是在响应什么CNT 溢出归零的同时定时器会产生一个更新事件Update Event这个事件可以触发中断也可以触发 DMA还可以触发其他外设联动。中断服务函数里你做的操作——翻转 LED、喂狗、采样传感器——全部是在响应这个“数满一轮”的信号。在实际编程中有一个容易忽略的点更新事件产生时如果开了预装载PreloadPSC 和 ARR 的新值不会立刻生效而是要等下一个更新事件才装载。这就导致一个现象你在中断里改了 ARR但当前这一轮的周期仍然是旧值要下一轮才是新值。这在做动态调频 PWM 或者软件定时器数量动态变化时特别容易造成“第一拍异常”。预装载机制的本意是防止计数过程中 ARR 突然变化导致波形毛刺属于一个保护设计。理解它的存在之后写动态定时器时心里就有数了不要指望“改完立刻生效”要在时序设计上留出过渡。4. 不同系列芯片的时间基准差异从 F1 到 F4、L0 的配置对照前面讲的是通用原理但实际选型时别忽略一个残酷事实不同系列的时钟树结构有细微差异定时器频率上限也不一样。同一个“定时 1ms”的需求F103 上 PSC71、ARR999 能跑到了 F407 上还是这套配比时间就完全不对。4.1 为什么 F407 不能直接抄 F103 的分频配置F407 的主频普遍跑 168MHzAPB1 预分频通常设 4PCLK1 42MHz定时器时钟翻倍到 84MHz。如果按 F103 的习惯把 PSC 设为 71CK_CNT 84MHz / 72 1.1667MHz一个脉冲约 0.857μsARR 配 999 时一轮就是 857μs和 1ms 差了不是一点点。正确做法是先明确 TIMxCLK 到底是 84MHz 还是 168MHz然后让 PSC 把 CK_CNT 归到整数频率。我自己的习惯是F103 上做 1msPSC 71CK_CNT 1MHzARR 999F407 上做 1msTIM 挂 APB1PSC 83CK_CNT 1MHzARR 999因为 84MHz / 84 1MHzF407 上做 1msTIM 挂 APB2PSC 167CK_CNT 1MHzARR 999因为 168MHz / 168 1MHz每个数字背后都是 TIMxCLK 除以想要的 CK_CNT 再减 1。推一遍就知道根本不需要背参数。这也是我为什么一直强调要先会推导、再记参数——芯片年年出新参数表背不完方法能管一辈子。4.2 L0/L4 系列低功耗场景下“低速时钟”的特殊地位到了 L0、L4 这些低功耗系列情况又多了一层除了来自 PLL 的高速时钟还有 LSI约 32kHz和 LSE32.768kHz 外部低速晶振这类低速时钟源。某些定时器比如 LPTIM低功耗定时器在停机模式下仍然可以工作依靠的就是这些低速时钟。这时候的“时间基准”选择逻辑完全不同高速时钟精度高但费电停机时直接停摆低速时钟省电但分辨率低。做低功耗产品时要分清哪些定时任务可以在睡眠期间保持运行、哪些必须在唤醒后靠高速时钟补算。比如用 LPTIM 做 RTC 唤醒之外的秒级定时就完全够用但要在睡眠期间做高精度 PWM那就不现实。这块我自己的建议是先把高速时钟链路的推导练熟再去看低功耗系列的时钟树。高速链路是地基低速时钟只是多了一个分支。地基不稳分支学得再多也容易乱。4.3 定时器时基的“极限参考”预分频最大值与 16 位/32 位计数器还有一个容易被忽视的约束F1 系列的通用定时器大多是 16 位计数器ARR 最大只能写到 65535。想要一次定时很长的时间光靠增大 ARR 不够必须加大 PSC 来降低 CK_CNT。但 PSC 最大也只能到 65535所以存在一个最大定时时长的物理上限。以 72MHz 为例PSC 最大 65535CK_CNT 最低约为 1098.6HzARR 最大 65535一轮最长约 59.6 秒。如果想要 1 分钟以上的定时一个 16 位通用定时器就不够用了得改用 32 位定时器比如 TIM2、TIM5 在部分系列上是 32 位或者用定时器级联、软件计数扩展。这个“物理上限”意识特别重要很多项目做长定时失败了不是代码写错是根本没意识到定时器位数不够。5. 让时间基准“现出原形”四种实测校验时间基准的方法讲完了理论必须上实操。这里分享我在项目里用过的四种校验时间基准的方法从简单到复杂都有保证你在任何调试阶段都能找到合适的手段。5.1 方法一调试器里直接看 RCC 时钟配置最直接的验证方式是打开调试器在 Peripherals 菜单里查看 RCC 相关的时钟树状态。Keil、IAR、STM32CubeIDE 都提供了寄存器查看窗口可以直接看到 SYSCLK、HCLK、PCLK1、PCLK2 的实际值。这个方法适合确认“静态配置对不对”但看不到定时器实际跑起来的表现。第二层的验证得靠输出波形。5.2 方法二GPIO 翻转 PWM 输出用逻辑分析仪/示波器量频率把某个定时器的通道配置成 PWM 输出模式占空比设 50%让定时器以你要验证的周期溢出。然后用逻辑分析仪或者示波器抓波形数一下实际频率。举例来说你算出来应该输出 1kHz 的 PWM抓到的频率是 999.8Hz说明基准基本没问题抓到 800Hz回到第 3、4 节重新查 TIMxCLK 和 PSC/ARR。这个方法能一次性暴露所有分频链路的错误是我最推荐的基准验证手段。5.3 方法三用 GPIO 翻转中断观察“两点之间的真实时长”不想折腾 PWM 通道时可以直接在定时器更新中断里翻转一个 GPIO然后逻辑分析仪抓这个 GPIO 的波形测量高电平持续时间和低电平持续时间。每个电平持续时间就是一轮定时周期。这种方法的好处是可以顺带验证中断响应延迟对周期的影响——如果中断服务函数执行时间太长会拉长整个周期这个现象在做精确时序时必须心里有数。中断里只做“翻转 GPIO”这个极简操作时量到的周期才是定时器自身的真实周期。5.4 方法四PWM 输入捕获互测用另一个定时器来量这个定时器这是我自己压箱底的校验技巧用一个定时器的输入捕获模式去捕获另一个定时器输出的 PWM把捕获到的频率和理论值对比。两个定时器共用同一个时钟源互相验证能发现单个定时器配置错误导致的偏差。这种方法适合没有示波器、只有两块开发板的场景。输入捕获测频率的原理是测量两个相邻上升沿之间的时间差然后用 1 除以时间差得到频率。STM32 的输入捕获配合 DMA 可以做到多通道连续采样测出来的频率精度相当可观。网上搜“stm32定时器捕获测频率”能找到大量案例核心思路都是一样的。6. 常见时间基准错误的排查链路从现象反推根因最后照着真实项目里的踩坑经验列几个高频问题并给出一条完整的排查链路。这些坑我几乎全踩过每一个都能对应到前面讲的某个原理。6.1 现象一定时中断周期是理论值的两倍或一半如果实测周期正好是理论值的 2 倍大概率是TIMxCLK 算低了。典型场景PCLK1 36MHz你以为定时器时钟也是 36MHz但 APB1 预分频不为 1实际定时器时钟是 72MHz。结果 PSC/ARR 按 36MHz 设计实际数得更快溢出更快周期反而短了。如果实测周期正好是理论值的一半那就是TIMxCLK 算高了。典型场景没注意 APB2 的分频状态以为翻了倍实际并没有翻倍。排查链路先查 RCC 寄存器里的 APB1/APB2 分频系数确认是否大于 1再查芯片对应的定时器时钟是挂 APB1 还是 APB2最后用示波器实测 PWM 频率反推 TIMxCLK。6.2 现象二LED 闪烁肉眼可见地“忽快忽慢”这往往是PSC 和 ARR 修改的时机不对导致的。如果允许在运行时修改 ARR而预装载位没有打开新值可能在一个计数周期中途被装载导致这一轮的周期异常。打开预装载后新值统一在下一轮更新事件生效周期就稳定了。另一个常见原因是中断服务函数里做了太多事导致更新中断的实际响应时间抖动很大。中断里只设置标志位、把耗时的计算和 IO 操作放到主循环是稳定周期的基本功。6.3 现象二延时函数卡死、定时器根本不触发这类问题在 F103 上非常经典。很多人的延时函数是基于 SysTick滴答定时器实现的如果 SysTick 的时钟源配置和系统时钟不一致或者中断优先级配置失误延时就会卡死。同时CubeMX 生成的代码如果初始化顺序有问题也可能在启动阶段就堵住了中断。排查顺序先确认 SysTick 是不是正常在递减调试器里打断点看 SysTick-VAL 是否变化再看 NVIC 里定时器中断有没有使能、优先级有没有被屏蔽最后检查时钟树配置尤其是 HSE 起振失败后系统自动切到 HSI 的情况。HSE 失效是巨大的隐形坑——芯片可能程序还能跑但主频从 72MHz 掉到 8MHz所有定时器周期全部变成理论的 9 倍慢。6.4 现象四动态改变 ARR 后第一拍波形异常做可调频率 PWM 时第一拍异常几乎可以断定是预装载缓冲没开。预装载缓冲的作用前面说过是为了防止计数过程中 ARR 变化导致波形撕裂。开了预装载之后ARR 寄存器的写入只更新影子寄存器等到更新事件才真正生效。配置时记得把 TIM_CR1 的 ARPE 位置 1或者用 HAL 库的__HAL_TIM_SET_AUTORELOAD时确认预装载已启用。7. 最后说点实在的我调定时器时的一些个人习惯把上面这些经历过一遍之后我现在配置定时器已经形成了一套固定流程分享给大家。第一永远先推导再写代码。拿到任何一颗芯片先查清楚两个问题定时器挂哪个总线分频系数是多少TIMxCLK 等于多少。推导出 PSC 和 ARR 之后再去看寄存器基本不会出错。第二用“整数频率”当锚点。我习惯先把 CK_CNT 设成 1MHz 或者 100kHz这样 ARR 的数值直接和时间对应——ARR999 就是 1msARR9999 就是 10ms换算不用动脑子代码可读性也高。除非有特殊的分辨率需求否则不轻易用非整数的 CK_CNT。第三每个定时器的用途在初始化时就固定下来。项目里定时器一多最大的风险不是单个定时器配错而是定时器之间的中断互相干扰。我会先列一张表写清楚每个 TIM 的时钟源、PSC、ARR、用途和中断优先级再动手写代码。别看这一步不起眼它能省下后面联调时大量的排查时间。最后把示波器或逻辑分析仪当作第二双眼睛。所有理论推导最终都要经过一次真实波形校验才算数。跑了这么多年项目我越来越觉得定时器的“时间基准”就像房子的地基——平时看不见它但每一层墙歪没歪所有人都能感受到。把这条从晶振到 CNT 的链路彻底吃透不只是学会了一个外设而是真正建立起对“时间”这个维度的掌控感。
STM32定时器时间基准详解：从时钟树到PSC/ARR配置一次讲透
1. 从一次跑偏的 LED 闪烁说起定时器到底在“数”什么很多刚接触 STM32 的同学都有过这种经历照着教程配好了定时器算好了分频系数和自动重装载值满心以为能精确到微秒级结果示波器一端上去——闪烁周期差了十万八千里甚至干脆不工作。这时候资料里翻来翻去都是“TIMx 的时钟来自 APBx”但到底怎么来的、为什么 F1 和 F4 算出来不一样、那个诡异的“×2”又是从哪冒出来的没人给你掰开揉碎讲清楚。我自己刚入行那会儿也被这个坑绊过。记得第一次做 1ms 定时中断用的 STM32F103按照网上的模板抄了一段代码PSC 配 71ARR 配 999心想 72MHz 主频除下来不就是 1ms 吗可实际量出来的波形偏偏不是那么回事。从那时起我就意识到一个核心问题定时器本身没有“时间”概念它只会数脉冲所谓的毫秒、微秒全靠“一个脉冲代表多长时间”这个基准来换算。而这个基准就是标题里问的“时间基准”。换句话说你配置定时器时写的所有数字本质都是在给它设定“数到多少算一轮”以及“每数一下花多久”。前者是 ARR 和 CNT 的事后者才是时间基准的事。这个基准从哪来、中间经过了哪些环节、为什么不同系列芯片算出来的结果不一样就是这篇文章要一次性讲透的东西。这篇文章适合三类人正准备用定时器做延时、PWM、输入捕获的新手已经会用 CubeMX 生成代码但遇到“定时不准”问题的开发者以及想彻底搞懂 STM32 时钟树不再靠试错调参的老手。读完之后你会明白为什么有些代码换颗芯片就要重新算分频也会掌握一套自己推导定时时间的完整方法。2. 时间基准的真正源头时钟树里的那一串“分频-倍频”链路先说结论STM32 定时器的“时间基准”本质上就是一个脉冲方波定时器数这个方波的边沿来推进计数。这个方波从哪来一路追溯上去源头是芯片内部的振荡器或者外部晶振中间经过 PLL 倍频、AHB 预分频、APB 预分频最后才送到定时器模块。链路里的每一级都在改变频率任何一级理解错了你算出来的定时时间就不可能对。2.1 源头选择HSI、HSE 还是 PLLSTM32 的时钟源主要有三个HSI高速内部振荡器芯片内置上电就能用但精度一般。F1 系列是 8MHzF4 系列也是 16MHz温度漂移比晶振大。拿它当定时器基准做要求不高的功能凑合做精确时序就危险。HSE高速外部振荡器外接晶振常见 8MHz、25MHz。精度高、稳定是工业产品和追求时序精度的项目的首选。用示波器测 PWM 频率时偏差基本来自晶振本身的误差。PLL锁相环把 HSI 或 HSE 倍频上去得到系统主频 SYSCLK。F103 最高 72MHzF407 能到 168MHzF429 能到 180MHz。PLL 是绝大多数应用的最终主频来源。有人会问为什么不直接用 HSI 当主频省得配 PLL因为 HSI 频率低、漂移大而且 PLL 可以输出更高的系统时钟让 CPU 跑得更快。但高主频不意味着定时器一定准——PLL 的输出要经历后面那一串分频链路任何一个分频配置改变了送到定时器的频率就跟着变。2.2 AHB 与 APB 预分频定时器时钟的“命运分水岭”系统主频 SYSCLK 确定后会先经过 AHB 预分频器得到 HCLK再经过 APB1/APB2 预分频器得到 PCLK1/PCLK2。这里就是新手最容易懵的地方。关键规则是定时器时钟 TIMxCLK 不等于 APB 总线时钟 PCLKx。当 APB 预分频系数为 1 时TIMxCLK 等于 PCLKx当 APB 预分频系数大于 1 时TIMxCLK 等于 PCLKx 的 2 倍。这个“大于 1 就翻倍”的规则是 STM32 设计上为了保证定时器能拿到足够高的工作频率而特意做的。绝大多数默认工程里APB1 预分频都不止 1所以定时器时钟几乎总是 APB 总线的两倍。很多人抄代码只照抄了 APB 配置没意识到这条规则算出来的分频系数自然全错。我拿 F103 举个具体例子。系统主频 72MHzAHB 分频 1所以 HCLK 也是 72MHz。APB1 预分频设为 2则 PCLK1 36MHz按规则 TIM2~TIM7 这些挂在 APB1 上的定时器时钟是 PCLK1 的 2 倍也就是 72MHz。APB2 预分频设为 1则 PCLK2 72MHzTIM1、TIM8 这些挂在 APB2 上的高级定时器时钟直接就是 72MHz。这个案例的关键点在于APB1 反而成了“定时器时钟最高的地方”。哪怕 PCLK1 总线频率只有 36MHz定时器照样能拿到 72MHz——这就是翻倍规则的威力。2.3 一条链路算到底从 8MHz 晶振到定时器时钟的完整推导把上面这些串起来完整推导一遍。假设 F103 外部接了 8MHz 晶振PLL 倍频 9 倍得到 72MHz SYSCLKAHB 分频 1APB1 分频 2APB2 分频 1环节频率计算依据HSE8 MHz外部晶振SYSCLK72 MHz8 × PLL 倍频系数 9HCLK72 MHzAHB 预分频 1PCLK136 MHzAPB1 预分频 2挂 APB1 的 TIMxCLK72 MHzAPB1 分频 1翻倍PCLK272 MHzAPB2 预分频 1挂 APB2 的 TIMxCLK72 MHzAPB2 分频 1不翻倍看到没同样是 72MHz 主频挂在 APB1 上的 PCLK1 只有 36MHz但定时器时钟反而恢复到 72MHz。如果你在代码里拿 PCLK1 当定时器时钟去算结果就对不上。这种细节就是“看起来一样的代码别人跑得准你跑不准”的根源。F4 系列同理但数值不同比如 F407 主频 168MHz 时APB1 预分频 4 得到 42MHz PCLK1翻倍后挂 APB1 的定时器时钟变成 84MHzAPB2 预分频 2 得到 84MHz PCLK2翻倍后挂 APB2 的定时器时钟变成 168MHz。规律没变数值全换了这就是为什么同一套算分频的思路在不同芯片上要重新走一遍。3. 从 TIMxCLK 到 CNT 计数PSC、ARR、CNT 三兄弟的分工逻辑时钟源搞清楚之后还得把定时器内部的工作机制吃透。定时器内部的“时间”是由三个寄存器一起决定的PSC预分频、ARR自动重装载、CNT计数器。它们的配合关系是理解一切定时器应用的核心。3.1 PSC 怎么“磨碎”时钟一个脉冲到底代表多久PSC 的作用是把 TIMxCLK 再进行一次分频得到一个低频的计数时钟 CK_CNT。这个频率的计算公式是CK_CNT TIMxCLK / (PSC 1)为什么是 PSC1 而不是 PSC因为 PSC 寄存器值是从 0 开始编号的写 0 表示不分频写 71 表示 72 分频。这个“1”是所有的坑里最容易踩的。拿 F103 的 72MHz 来说PSC 0CK_CNT 72MHz一个计数脉冲约 13.9nsPSC 71CK_CNT 1MHz一个计数脉冲正好 1μsPSC 7199CK_CNT 10kHz一个计数脉冲 100μs这里有个很重要的直觉PSC 决定了定时器的“分辨率”。PSC 越小单个脉冲时间越短定时精度相对越高但计数器计满一轮需要的脉冲数也越多ARR 就得配大PSC 越大分辨率下降但 ARR 可以配小。实际工程里通常先定 PSC 让 CK_CNT 落到一个整数频率比如 1MHz再用 ARR 决定定时时长这样代码可读性最好也方便换算。3.2 ARR 和 CNT 的配合方式向上计数模式全流程演示ARR 是自动重装载值CNT 是当前计数值。向上计数模式下CNT 从 0 开始每个 CK_CNT 脉冲加 1加到 ARR 后触发更新事件CNT 归零重新开始。一次完整的“0 → ARR → 溢出 → 0”就是一轮定时。定时周期的公式是定时时间 (ARR 1) × (PSC 1) / TIMxCLK同样有 ARR1 的问题。因为 CNT 是数到 ARR 才清零从 0 到 ARR 一共经过了 ARR1 个脉冲。想定时 1ms、TIMxCLK 为 72MHz、PSC 设为 71CK_CNT 1MHz那么 ARR 999因为 (9991) / 1MHz 1ms。写代码的时候 ARR 寄存器的值就是 999不是 1000。我把这个公式拆开用表格列一下不同定时时长的典型配比TIMxCLK 72MHz目标时间PSCARRCK_CNT实际时间1μs7111MHz2μs不对1μs07172MHz1μs1ms719991MHz1ms100ms719999910kHz100ms1s7199999910kHz1s注意第一行那个陷阱PSC71、ARR1 算出来是 2μs 而不是 1μs。因为公式是 (11) × (711) / 72MHz 2μs。PSC 和 ARR 的任何配比问题最终都会落到“别忘了 1”这个点上。3.3 更新事件和更新中断你写的回调函数是在响应什么CNT 溢出归零的同时定时器会产生一个更新事件Update Event这个事件可以触发中断也可以触发 DMA还可以触发其他外设联动。中断服务函数里你做的操作——翻转 LED、喂狗、采样传感器——全部是在响应这个“数满一轮”的信号。在实际编程中有一个容易忽略的点更新事件产生时如果开了预装载PreloadPSC 和 ARR 的新值不会立刻生效而是要等下一个更新事件才装载。这就导致一个现象你在中断里改了 ARR但当前这一轮的周期仍然是旧值要下一轮才是新值。这在做动态调频 PWM 或者软件定时器数量动态变化时特别容易造成“第一拍异常”。预装载机制的本意是防止计数过程中 ARR 突然变化导致波形毛刺属于一个保护设计。理解它的存在之后写动态定时器时心里就有数了不要指望“改完立刻生效”要在时序设计上留出过渡。4. 不同系列芯片的时间基准差异从 F1 到 F4、L0 的配置对照前面讲的是通用原理但实际选型时别忽略一个残酷事实不同系列的时钟树结构有细微差异定时器频率上限也不一样。同一个“定时 1ms”的需求F103 上 PSC71、ARR999 能跑到了 F407 上还是这套配比时间就完全不对。4.1 为什么 F407 不能直接抄 F103 的分频配置F407 的主频普遍跑 168MHzAPB1 预分频通常设 4PCLK1 42MHz定时器时钟翻倍到 84MHz。如果按 F103 的习惯把 PSC 设为 71CK_CNT 84MHz / 72 1.1667MHz一个脉冲约 0.857μsARR 配 999 时一轮就是 857μs和 1ms 差了不是一点点。正确做法是先明确 TIMxCLK 到底是 84MHz 还是 168MHz然后让 PSC 把 CK_CNT 归到整数频率。我自己的习惯是F103 上做 1msPSC 71CK_CNT 1MHzARR 999F407 上做 1msTIM 挂 APB1PSC 83CK_CNT 1MHzARR 999因为 84MHz / 84 1MHzF407 上做 1msTIM 挂 APB2PSC 167CK_CNT 1MHzARR 999因为 168MHz / 168 1MHz每个数字背后都是 TIMxCLK 除以想要的 CK_CNT 再减 1。推一遍就知道根本不需要背参数。这也是我为什么一直强调要先会推导、再记参数——芯片年年出新参数表背不完方法能管一辈子。4.2 L0/L4 系列低功耗场景下“低速时钟”的特殊地位到了 L0、L4 这些低功耗系列情况又多了一层除了来自 PLL 的高速时钟还有 LSI约 32kHz和 LSE32.768kHz 外部低速晶振这类低速时钟源。某些定时器比如 LPTIM低功耗定时器在停机模式下仍然可以工作依靠的就是这些低速时钟。这时候的“时间基准”选择逻辑完全不同高速时钟精度高但费电停机时直接停摆低速时钟省电但分辨率低。做低功耗产品时要分清哪些定时任务可以在睡眠期间保持运行、哪些必须在唤醒后靠高速时钟补算。比如用 LPTIM 做 RTC 唤醒之外的秒级定时就完全够用但要在睡眠期间做高精度 PWM那就不现实。这块我自己的建议是先把高速时钟链路的推导练熟再去看低功耗系列的时钟树。高速链路是地基低速时钟只是多了一个分支。地基不稳分支学得再多也容易乱。4.3 定时器时基的“极限参考”预分频最大值与 16 位/32 位计数器还有一个容易被忽视的约束F1 系列的通用定时器大多是 16 位计数器ARR 最大只能写到 65535。想要一次定时很长的时间光靠增大 ARR 不够必须加大 PSC 来降低 CK_CNT。但 PSC 最大也只能到 65535所以存在一个最大定时时长的物理上限。以 72MHz 为例PSC 最大 65535CK_CNT 最低约为 1098.6HzARR 最大 65535一轮最长约 59.6 秒。如果想要 1 分钟以上的定时一个 16 位通用定时器就不够用了得改用 32 位定时器比如 TIM2、TIM5 在部分系列上是 32 位或者用定时器级联、软件计数扩展。这个“物理上限”意识特别重要很多项目做长定时失败了不是代码写错是根本没意识到定时器位数不够。5. 让时间基准“现出原形”四种实测校验时间基准的方法讲完了理论必须上实操。这里分享我在项目里用过的四种校验时间基准的方法从简单到复杂都有保证你在任何调试阶段都能找到合适的手段。5.1 方法一调试器里直接看 RCC 时钟配置最直接的验证方式是打开调试器在 Peripherals 菜单里查看 RCC 相关的时钟树状态。Keil、IAR、STM32CubeIDE 都提供了寄存器查看窗口可以直接看到 SYSCLK、HCLK、PCLK1、PCLK2 的实际值。这个方法适合确认“静态配置对不对”但看不到定时器实际跑起来的表现。第二层的验证得靠输出波形。5.2 方法二GPIO 翻转 PWM 输出用逻辑分析仪/示波器量频率把某个定时器的通道配置成 PWM 输出模式占空比设 50%让定时器以你要验证的周期溢出。然后用逻辑分析仪或者示波器抓波形数一下实际频率。举例来说你算出来应该输出 1kHz 的 PWM抓到的频率是 999.8Hz说明基准基本没问题抓到 800Hz回到第 3、4 节重新查 TIMxCLK 和 PSC/ARR。这个方法能一次性暴露所有分频链路的错误是我最推荐的基准验证手段。5.3 方法三用 GPIO 翻转中断观察“两点之间的真实时长”不想折腾 PWM 通道时可以直接在定时器更新中断里翻转一个 GPIO然后逻辑分析仪抓这个 GPIO 的波形测量高电平持续时间和低电平持续时间。每个电平持续时间就是一轮定时周期。这种方法的好处是可以顺带验证中断响应延迟对周期的影响——如果中断服务函数执行时间太长会拉长整个周期这个现象在做精确时序时必须心里有数。中断里只做“翻转 GPIO”这个极简操作时量到的周期才是定时器自身的真实周期。5.4 方法四PWM 输入捕获互测用另一个定时器来量这个定时器这是我自己压箱底的校验技巧用一个定时器的输入捕获模式去捕获另一个定时器输出的 PWM把捕获到的频率和理论值对比。两个定时器共用同一个时钟源互相验证能发现单个定时器配置错误导致的偏差。这种方法适合没有示波器、只有两块开发板的场景。输入捕获测频率的原理是测量两个相邻上升沿之间的时间差然后用 1 除以时间差得到频率。STM32 的输入捕获配合 DMA 可以做到多通道连续采样测出来的频率精度相当可观。网上搜“stm32定时器捕获测频率”能找到大量案例核心思路都是一样的。6. 常见时间基准错误的排查链路从现象反推根因最后照着真实项目里的踩坑经验列几个高频问题并给出一条完整的排查链路。这些坑我几乎全踩过每一个都能对应到前面讲的某个原理。6.1 现象一定时中断周期是理论值的两倍或一半如果实测周期正好是理论值的 2 倍大概率是TIMxCLK 算低了。典型场景PCLK1 36MHz你以为定时器时钟也是 36MHz但 APB1 预分频不为 1实际定时器时钟是 72MHz。结果 PSC/ARR 按 36MHz 设计实际数得更快溢出更快周期反而短了。如果实测周期正好是理论值的一半那就是TIMxCLK 算高了。典型场景没注意 APB2 的分频状态以为翻了倍实际并没有翻倍。排查链路先查 RCC 寄存器里的 APB1/APB2 分频系数确认是否大于 1再查芯片对应的定时器时钟是挂 APB1 还是 APB2最后用示波器实测 PWM 频率反推 TIMxCLK。6.2 现象二LED 闪烁肉眼可见地“忽快忽慢”这往往是PSC 和 ARR 修改的时机不对导致的。如果允许在运行时修改 ARR而预装载位没有打开新值可能在一个计数周期中途被装载导致这一轮的周期异常。打开预装载后新值统一在下一轮更新事件生效周期就稳定了。另一个常见原因是中断服务函数里做了太多事导致更新中断的实际响应时间抖动很大。中断里只设置标志位、把耗时的计算和 IO 操作放到主循环是稳定周期的基本功。6.3 现象二延时函数卡死、定时器根本不触发这类问题在 F103 上非常经典。很多人的延时函数是基于 SysTick滴答定时器实现的如果 SysTick 的时钟源配置和系统时钟不一致或者中断优先级配置失误延时就会卡死。同时CubeMX 生成的代码如果初始化顺序有问题也可能在启动阶段就堵住了中断。排查顺序先确认 SysTick 是不是正常在递减调试器里打断点看 SysTick-VAL 是否变化再看 NVIC 里定时器中断有没有使能、优先级有没有被屏蔽最后检查时钟树配置尤其是 HSE 起振失败后系统自动切到 HSI 的情况。HSE 失效是巨大的隐形坑——芯片可能程序还能跑但主频从 72MHz 掉到 8MHz所有定时器周期全部变成理论的 9 倍慢。6.4 现象四动态改变 ARR 后第一拍波形异常做可调频率 PWM 时第一拍异常几乎可以断定是预装载缓冲没开。预装载缓冲的作用前面说过是为了防止计数过程中 ARR 变化导致波形撕裂。开了预装载之后ARR 寄存器的写入只更新影子寄存器等到更新事件才真正生效。配置时记得把 TIM_CR1 的 ARPE 位置 1或者用 HAL 库的__HAL_TIM_SET_AUTORELOAD时确认预装载已启用。7. 最后说点实在的我调定时器时的一些个人习惯把上面这些经历过一遍之后我现在配置定时器已经形成了一套固定流程分享给大家。第一永远先推导再写代码。拿到任何一颗芯片先查清楚两个问题定时器挂哪个总线分频系数是多少TIMxCLK 等于多少。推导出 PSC 和 ARR 之后再去看寄存器基本不会出错。第二用“整数频率”当锚点。我习惯先把 CK_CNT 设成 1MHz 或者 100kHz这样 ARR 的数值直接和时间对应——ARR999 就是 1msARR9999 就是 10ms换算不用动脑子代码可读性也高。除非有特殊的分辨率需求否则不轻易用非整数的 CK_CNT。第三每个定时器的用途在初始化时就固定下来。项目里定时器一多最大的风险不是单个定时器配错而是定时器之间的中断互相干扰。我会先列一张表写清楚每个 TIM 的时钟源、PSC、ARR、用途和中断优先级再动手写代码。别看这一步不起眼它能省下后面联调时大量的排查时间。最后把示波器或逻辑分析仪当作第二双眼睛。所有理论推导最终都要经过一次真实波形校验才算数。跑了这么多年项目我越来越觉得定时器的“时间基准”就像房子的地基——平时看不见它但每一层墙歪没歪所有人都能感受到。把这条从晶振到 CNT 的链路彻底吃透不只是学会了一个外设而是真正建立起对“时间”这个维度的掌控感。
