1. 定时器时钟源头：先搞清楚定时器到底跑多快
1.1 从RCC开始：定时器时钟不是随便能用的
拿到STM32先别急着初始化TIMx，第一步应该回答一个问题：定时器挂在哪条总线上，它的输入时钟到底是多少。很多人调定时器时间不对，罪魁祸首就是这里。以最常见的F1系列为例，APB1最大36MHz，APB2最大72MHz，定时器TIM2~TIM7都挂在APB1上。如果APB1预分频被配置成了2，那么挂在APB1上的定时器实际输入时钟不是36MHz，而是36乘以2等于72MHz。原因是芯片内部有专门的倍频器，当APB1预分频大于1时，定时器时钟会自动乘2，补偿总线频率损失。APB2没有这套补偿，因为它的时钟直接就是72MHz。
F4和F7系列的规则类似，但预分频系数不同，APB1为4分频时定时器时钟同样会乘2。具体要查对应型号参考手册里的时钟树框图，不要靠经验硬套。实际工程里最典型的错误是：直接复制某个F1例程到F4上，PLL和APB1/APB2的系数没改，定时器中断周期从预期的1ms变成了2ms甚至4ms，示波器一抓波形才发现问题。
这里有个判断技巧：看配置代码里SystemClock_Config函数中RCC_APB1PeriphClockCmd或HAL库的RCC_ClkInitStruct配置。只要APB1或APB2的预分频不是1，就必须先算一遍定时器倍频后的时钟，再往后推导PSC和ARR。否则后面每一步计算都会错位。
1.2 预分频和自动重装载：两个寄存器的配合逻辑
定时器内部核心是一个计数器，每个定时器时钟沿让计数器加1。PSC预分频器负责把定时器时钟分频后再送给计数器，ARR是计数上限。计数器从0数到ARR，归零并产生更新事件。溢出频率公式：
f_update = f_timer_clock / ((PSC + 1) * (ARR + 1))为什么这里都要加1？因为PSC和ARR这些寄存器存储的是N-1对应的值，写0就代表系数1，写71代表系数72。举个例子，定时器时钟72MHz，PSC=71，ARR=999，算出溢出频率1000Hz，正好1ms中断一次。如果图省事写成PSC=72，ARR=1000，得到约989Hz，和你想要的1ms就差一线。做普通延时这种误差无伤大雅，但做精准时间基准、采样率对齐的时候就非常致命。
还有一点容易被忽略：PSC和ARR都存在预装载机制，写入的值要等更新事件发生后才真正生效。HAL库里AutoReloadPreload开启预装载后，修改htim->Init.Period不会立刻改变周期，要等当前计数周期结束。这个机制在动态调整PWM频率或定时周期时很有用，能避免中间态。使用寄存器编程时，要留意控制器手册里对应位的预装载说明，确认新值是立即生效还是等待更新事件。
1.3 常见时钟配置错误：实测排查思路
我整理了几类出现频率最高的定时器时钟问题，供参考。
第一种是倍频器忘记加。某项目使用TIM3做10ms调度，逻辑分析仪抓到20ms周期，排查半天发现RCC->CFGR里APB1预分频被配置为2，定时器时钟实际只有36MHz而不是72MHz，但代码里按照72MHz去计算PSC和ARR，周期直接翻倍。
第二种是使能了TIM时钟，却漏了GPIO复用时钟。PWM输出时引脚没有信号，本质原因经常是AFIO或GPIO时钟没有开启，GPIO处于浮空状态。这时示波器看引脚没有任何波形，但寄存器里CCR值又是对的，容易让人误判定时器坏了。
第三种是改了时钟树后，所有定时器中断周期成比例偏移。比如PLL倍频系数调低后，忘记了乘2规则，导致溢出频率整体偏差。用调试器读RCC->CFGR的值，再拿公式反推，基本能锁定问题。
提示：改完时钟树后，建议先用示波器配合GPIO翻转测试一段已知延时的波形，确认实际频率，再往下做复杂功能。这个习惯能省下大量排错时间。
2. 定时器家族选型：基本、通用、高级定时器各干哪些活
2.1 基本定时器TIM6/TIM7：最简单的时基发生器
基本定时器在F1系列里主要是TIM6和TIM7，它们没有通道引脚，不能输出PWM，也不能做输入捕获，只能做基础定时和触发DAC。但正因为简单，它们非常适合做系统时基、周期性唤醒、喂看门狗这类任务。配置代码很短，占用的中断资源也少，不容易出幺蛾子。
有些项目会纠结“用SysTick还是用TIM6做系统tick”。SysTick是内核定时器，几乎所有嵌入式工程师都熟悉，但它会被调试器暂停，有些低功耗模式下也会停掉。TIM6作为外设定时器，行为更独立，适合需要严格周期或者不希望调试影响时序的场景。如果只是简单延时，SysTick完全够用；如果要做长时间运行的调度器，独立外设定时器更稳。
基本定时器因为没有输入输出引脚，往往被新人忽略，但在产品里它很实用。比如低功耗待机时定时唤醒、ADC定时触发采样、DAC输出周期信号，都用得上。选型时不要看不起这几个“没什么功能”的定时器，它们的简洁本身就是价值。
2.2 通用定时器TIM2~TIM5、TIM9~TIM14：项目里的多面手
通用定时器是项目里最常用的，几乎能覆盖大部分外设需求：PWM输出、输入捕获、输出比较、编码器模式、外部脉冲计数等。它们通常有4个独立通道，每个通道可以单独映射到不同的GPIO引脚。选择哪个定时器，首先要看引脚复用关系，其次看总线时钟，然后看计数器位数。
以F1为例，TIM2和TIM5是32位计数器，TIM3和TIM4是16位计数器。32位和16位的最大区别在于溢出时间上限。在72MHz时钟下，16位定时器即使PSC拉到65535，ARR也拉到65535，最大溢出周期大约59.6秒；32位定时器则是这个数值再乘上65536，可以达到几十小时级别。做长时间计时、低频信号测量，优先选用32位定时器，能减少软件计数溢出处理的工作量。
通用定时器还支持编码器接口模式，把正交编码器的A/B相直接接入定时器通道，硬件自动判断方向和计数值。用外部中断加GPIO判断也能测，但定时器模式不占CPU，方向判断也不会丢步，电机测速首选。
2.3 高级定时器TIM1/TIM8：那些“多余”的功能其实很关键
高级定时器和通用定时器的最大区别在于：多了互补输出、死区插入、刹车输入和重复计数功能。这些功能专门为电机控制、逆变器、全桥驱动这类场景设计。
互补输出就是同一个PWM信号输出两路反相波形，一路接上桥臂，一路接下桥臂。死区插入则保证上下桥臂不会同时导通，避免直通短路。刹车输入可以在外部故障信号到来时硬件级关断PWM输出，不需要CPU干预。想象一下电机堵转或过流瞬间，靠软件中断去关断是有延迟的，硬件刹车则快得多。
但高级定时器的配置项也更复杂。新手用TIM1做普通PWM时，常见问题是通道没有输出，折腾一圈发现主输出使能位没开。在寄存器编程里，需要设置BDTR寄存器的MOE位；HAL库的HAL_TIM_PWM_Start通常会自动处理，但如果你手动操作状态寄存器，很容易漏掉这一步。选型时如果只需要普通PWM，用通用定时器就够了；如果做电机全桥，才动用高级定时器。
3. 定时中断实践：从1ms延时到系统时间基准
3.1 配置一个1ms定时中断的完整步骤
定时器最基础的应用就是产生周期中断。用HAL库实现一个1ms的中断，核心代码如下：
TIM_HandleTypeDef htim3; void MX_TIM3_Init(void) { __HAL_RCC_TIM3_CLK_ENABLE(); htim3.Instance = TIM3; htim3.Init.Prescaler = 72 - 1; // 72MHz / 72 = 1MHz htim3.Init.CounterMode = TIM_COUNTERMODE_UP; htim3.Init.Period = 1000 - 1; // 1MHz / 1000 = 1kHz htim3.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim3.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_ENABLE; HAL_TIM_Base_Init(&htim3); }假设定时器时钟是72MHz，PSC设为71，计数频率变成1MHz，也就是1us计一个数。ARR设为999，计数器从0数到999再归零，总共耗时1000us，正好1ms。然后启动中断：
HAL_NVIC_SetPriority(TIM3_IRQn, 1, 0); HAL_NVIC_EnableIRQ(TIM3_IRQn); HAL_TIM_Base_Start_IT(&htim3, TIM_CHANNEL_ALL);在中断回调里处理自己的逻辑：
volatile uint32_t system_tick = 0; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM3) { system_tick++; } }system_tick必须加volatile，否则开O2优化后编译器可能把它优化进寄存器，主循环读到的永远是旧值。这个坑我见过不止一次。
3.2 中断服务函数里到底能不能放业务代码
很多人觉得中断里代码越多越高效，其实恰恰相反。定时器中断通常周期很短，1ms一次，如果中断服务函数里跑一个耗时50us的浮点运算，就会占用5%的CPU时间；如果耗时300us，主循环就已经很难受了。更糟的是，如果中断里调用了HAL_Delay这种基于SysTick的延时函数，而SysTick优先级比当前定时器中断低，系统会直接死锁。
正确的做法是：中断里只做两件事，置标志位和搬运数据。业务逻辑放到主循环或独立任务中去处理。比如：
volatile uint8_t led_toggle_flag = 0; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM3) { led_toggle_flag = 1; } }主循环里检查标志位再翻转LED。这样可以保证中断周期稳定，不会因为业务代码的长短而抖动。
中断优先级也需要仔细考虑。如果项目里既有UART接收中断，又有定时器中断，UART中断优先级高于定时器中断，那么定时器回调可能被延迟；反过来，定时器中断占用太长时间，又会饿死UART接收。合理做法是：短周期定时器优先级给高一些，长周期或低实时性任务优先级给低一些。
3.3 时间基准与主循环的配合：一个轻量调度思路
有了1ms的system_tick，就可以实现简单的时间片调度。比如每10ms翻转一次LED，每500ms采集一次传感器：
if (system_tick % 10 == 0) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); } if (system_tick % 500 == 0) { sensor_sample_flag = 1; }这相当于一个基于tick取模的调度器。注意取模操作本身耗时很少，但如果你在system_tick % 500 == 0分支里做完整的传感器采集，整个主循环在这段时间会卡住，其他任务会被延后。更好的做法是像上面那样只置标志位，主循环末尾统一处理。
这种结构写起来简单，维护成本低，适合裸机项目。如果任务变多，也可以升级成“时间片表”或者使用状态机。但核心思想不变：硬件只负责精确的tick，业务逻辑全部放在主循环里。
4. PWM输出：占空比背后的硬件细节
4.1 通道引脚与复用配置：为什么引脚没有波形
PWM的本质是定时器硬件根据比较值自动翻转GPIO电平，不需要CPU持续干预。但GPIO需要配置成复用推挽输出模式，并且要选择正确的复用功能编号。
HAL库的MSP回调里通常长这样：
void HAL_TIM_PWM_MspInit(TIM_HandleTypeDef *htim) { GPIO_InitTypeDef GPIO_InitStruct = {0}; if (htim->Instance == TIM3) { __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin = GPIO_PIN_6; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; GPIO_InitStruct.Alternate = GPIO_AF2_TIM3; // 必须对应型号复用表 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); } }Tim3_CH1和PA6是常见映射，但不同封装、不同型号的复用表可能不一样。手动配置时一定要查数据手册里的“Alternate function mapping”表，确认通道和引脚对应关系。选错引脚或者AF编号，代码不会报错，但引脚就是没有波形。
4.2 呼吸灯实验的真正意义：理解频率与分辨率的关系
呼吸灯是测试PWM最直观的实验。配置好PWM后，循环修改比较寄存器值，就能看到LED亮度逐渐变化。但呼吸灯背后有一个容易被忽略的点：PWM频率和占空比分辨率是相互制约的。
如果定时器时钟72MHz，PSC=71，计数频率1MHz。要得到1kHz PWM，ARR=999，占空比步进是1/1000，分辨率约10位。如果要得到100Hz PWM，ARR=9999，占空比步进是1/10000，分辨率约13位。如果要用20kHz PWM，ARR=3599，分辨率约12位。当遇到“占空比调节不平滑”或者“PWM频率上不去”之类的问题，要意识到根源是计数频率限制了分辨率，单纯改PSC或ARR只能二选一。
调占空比时，HAL库用：
__HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, pulse_value);pulse_value的范围是0到ARR。改变太快会有明显阶梯感，呼吸灯场景通常用延时控制渐变速度。实际项目中如果动态调整PWM频率，建议先暂停输出，修改ARR和PSC，再重新启动，避免中间状态导致占空比瞬间跳变。
4.3 舵机控制中50Hz PWM的配置
舵机是PWM应用里的经典案例。普通航模舵机期望的PWM周期通常是20ms，也就是频率50Hz，脉宽在500us到2500us之间对应0到180度。配置方法：
定时器时钟72MHz，PSC=71后计数频率1MHz，ARR=19999得到20ms周期。脉宽1500us时，比较寄存器值为1500。代码如下：
htim3.Init.Prescaler = 72 - 1; htim3.Init.Period = 19999; HAL_TIM_Base_Init(&htim3); HAL_TIM_PWM_Init(&htim3); __HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, 1500); // 1.5ms 中位 HAL_TIM_PWM_Start(&htim3, TIM_CHANNEL_1);改变角度就改__HAL_TIM_SET_COMPARE的第三个参数。我们经常说的“占空比”在舵机场景里其实不太准确，舵机关注的是高电平持续时间，不是百分比。PWM频率太靠近甚至低于20Hz，舵机可能开始抖动；频率太高，有些舵机反而反应迟钝，因为内部信号处理跟不上。
4.4 高级定时器的死区、互补输出和刹车功能
用TIM1或者TIM8输出PWM做电机驱动时，会用到互补输出。普通PWM只有一个输出引脚，互补输出则同时输出反相信号。全桥电路里，上桥臂和下桥臂如果同时导通，电源直接短路。死区时间的作用就是让上桥臂关断后等一小段时间，再打开下桥臂，这个时间通常设置在几百纳秒到几微秒之间。
HAL库配置高级定时器比通用定时器多了HAL_TIMEx_ConfigBreakDeadTime这类接口。除了死区，还有MOE主输出使能位，寄存器编程时漏掉它会让高级定时器无声无息地没有输出。刹车输入则是硬件故障保护机制，外部电路把过流信号拉到刹车引脚，定时器立即停止PWM输出，避免炸管。
之前帮朋友排查过一个电机驱动器，现象是程序跑起来后PWM输出非常不稳定，偶尔还会出现一次大电流。最后发现是死区时间设得太短，功率器件关断速度和死区不匹配。这类问题用万用表量不出来，必须用示波器看上下桥臂波形，确认死区窗口是否足够。高级定时器功能多，但也要求对硬件时序有更深入的了解。
5. 输入捕获与外部脉冲测量：定时器不只是“数数”
5.1 输入捕获原理：边沿一来，瞬间锁存计数值
定时器的输入捕获功能，本质是把当前计数器的值在特定边沿瞬间锁存到捕获寄存器里。比如通道检测到上升沿时，硬件立刻把CNT值复制到CCRn寄存器，不需要CPU介入。这样就能测量外部信号两个相邻上升沿之间的时间差。
用输入捕获测量一个频率为F的信号周期，方法是先配置通道检测上升沿，第一次捕获得到计数值c1，第二次捕获得到c2，那么信号周期对应的计数个数就是c2减去c1，频率等于定时器计数频率除以这个差值。
实际使用中要处理溢出问题。如果两次捕获之间16位计数器溢出了一次，直接减出来的差就是负数。一个简单做法是记录溢出次数，把捕获差值加上溢出次数乘以65536。另一个技巧是初始化时把计数器清0，令第一次捕获后立即清零CNT，这样第二次捕获值直接就是周期计数值，省去溢出判断。但如果信号周期很长，仍然需要处理溢出。
5.2 频率测量两种流派：测周期法和测频率法怎么选
测量外部信号频率，工程上有两种经典思路，每种都有适用场景。
第一种是测周期法：捕获相邻两个上升沿，算出周期再转频率。这种方法适合低频信号，比如几十Hz到几千Hz。信号频率越低，周期越长，测出来的相对误差越小。但如果信号是2MHz，周期只有500ns，计数器时钟可能都跟不上，就需要换方案。
第二种是测频率法：固定一个闸门时间，比如1秒，统计在这段时间内来了多少个上升沿。频率越高，闸门时间内脉冲数越多，精度越高，适合高频信号。实现时可以借用另一个定时器产生1s中断，在中断里读取捕获计数器差值，再乘以系数。
实际项目中测编码器转速经常用M/T法：低频时以测周期为主，高频时以测频率为主，两种方法结合。STM32定时器的编码器接口模式就是在硬件层面做一个接近M/T法的基础实现，自动根据速度切换加减速计数。
5.3 编码器接口模式：A/B相接入后，方向计数自动完成
编码器接口是通用定时器的一个隐藏技能。把正交编码器的A相和B相分别接到定时器的两个通道，定时器会自动根据A、B相位的先后顺序判断正反转，并在每个边沿更新计数器。这种模式不需要外部中断，不需要软件解码，CPU只需要定期读取CNT值，就能得到位置变化量。
配置时需要把定时器设为Encoder Mode，通道1和通道2的极性也要正确设置。一个常见的坑是编码器相位接反了，定时器计数值在正转时反而减少。遇到这个问题，可以先看旋转方向与预期是否一致，不对就把A、B两相对调，或者翻转计数方向配置。
由于编码器模式下计数器是16位（除非用32位定时器），长时间运行后可能溢出。处理方式是定期读取CNT并把累计值保存在软件变量里，同时保存上一次CNT值，差值作为增量。如果应用旋转速度极快，还要考虑边沿密度超过定时器计数能力的问题，这时候需要适当调高定时器时钟频率。
6. 实操中容易翻车的定时器细节
6.1 更新事件与更新中断的区别：为什么中断比想象中来得更频繁
很多人会把“更新事件”和“更新中断”混为一谈。更新事件是定时器内部硬件信号，比如计数器溢出、软件触发、外部触发等；更新中断只是这个信号使能了NVIC后的中断请求。关键点是，即使你没有主动调用更新中断使能，更新事件本身依然在硬件层面发生。
比如同时使用PWM输出和更新中断，计数器每次溢出都会产生更新事件，如果更新中断使能了，就会频繁进中断。PWM输出本身不需要CPU干预，但更新中断如果处理不当，反而会干扰主逻辑。解决方法是：如果不需要更新中断，确认TIM_DIER寄存器里的UIE位为0；或者配置TIM_CR1里的UDIS位，禁止更新事件产生，这样能减少被动触发。
还有一类问题是软件清除标志的时机。HAL库中，时序正常的更新中断会自动清除标志位，但如果用寄存器方式编程，读取标志后忘记清除，下一次中断永远不会触发。检查这类问题最快的方式是调试器里看SR寄存器的值，如果UIF一直为1，说明中断标志没有清掉。
6.2 16位定时器溢出边界与自动重装载的值域
16位定时器的ARR最大值是65535，PSC最大值也是65535。在72MHz时钟下，最大溢出周期是多少？计数频率最低是72MHz除以65536，约1098.6Hz；每个计数周期约910us；再乘上65536个计数，约59.6秒。这就是16位定时器在不靠软件计数情况下的最长单次溢出时间。
有些应用偏偏需要几分钟甚至几小时的超时计时。这时候有两种思路：一是改用32位定时器TIM2或TIM5，单次溢出时间可以拉长到小时级；二是依然用16位定时器，但每次溢出中断里让软件计数器加1，中断周期设为1秒比较好算。要注意软件计数溢出本身也有处理成本，中断频率不能太高，否则主程序就卡住了。
自动重装载值还有一个边界问题：当你把ARR从一个小值改成大值时，计数器可能已经走过了新ARR，需要等一个完整周期才稳定。动态修改PSC或ARR时，建议先关定时器，改完再开，可以避免意外触发。
6.3 HAL库回调与标志位清理：三个容易踩的小细节
HAL库的中断处理流程是：中断向量调用HAL_TIM_IRQHandler，函数内部判断中断来源并调用弱回调函数HAL_TIM_PeriodElapsedCallback。你重新实现这个弱函数时，要注意它是个全局函数，如果有多个定时器共用这一份回调，必须用htim->Instance区分来源，否则所有定时器中断都在做同样的事。
在回调函数里不要调用HAL_Delay。前面提到过，HAL_Delay依赖SysTick，如果SysTick的优先级低于当前定时器，就会死锁；如果优先级相同，也会让定时器周期变得不稳定。需要短延时就用for循环或者__NOP()空指令，尽管不如HAL_Delay精确，但至少不会卡死。
如果使用寄存器方式清除标志，要记住“先读标志，再清标志”的顺序。一个我见过很多次的错误写法是：进入中断后直接TIMx->SR = ~TIM_SR_UIF，但此时真正的UIF还没有被硬件置位到最高优先级，导致清除不干净。规范做法是先用if (TIMx->SR & TIM_SR_UIF)判断，再写标志位清除。
6.4 调试定时器的个人习惯与最终建议
我在实际调试中惯用的流程是：第一步，先用GPIO翻转法确认定时器实际中断频率。比如配置1ms中断，在回调里翻转一个GPIO，用示波器量到2ms周期，立刻能发现问题在时钟配置还是定时器参数上。第二步，验证PWM输出时先不接负载，直接测引脚波形，确认频率和占空比无误后再接外围电路。第三步，输入捕获和编码器模式下，先用手动信号源或手转转编码器测试计数值是否线性变化，再接到真实设备上。
定时器是STM32外设中功能最多、最容易出错也最值得花时间搞懂的一个模块。时钟树和时基计算是根，定时器选型是枝，中断、PWM、输入捕获是叶。把根和枝搞明白，后面做项目遇到问题才能快速定位。
最后再分享一个建议：不要死记硬背任何定时器代码，而是记住三条公式，一个是溢出频率公式，一个是PWM频率和占空比公式，一个是输入捕获周期换算公式。其余都是这些公式在不同场景下的应用题。把公式吃透，再复杂的定时器用法都能拆解出清晰的逻辑。
