1. 项目缘起：从“轮子不转”到编码器中断的探索

搞嵌入式开发，尤其是玩电机控制或者需要精确测量旋转角度、速度的项目，编码器和定时器中断绝对是绕不开的两个核心模块。我记得刚开始用STM32做一个小型云台项目时，想用旋转编码器来手动微调角度。最开始的思路特别“朴素”：在主循环里不停地去读编码器的A、B相引脚电平，然后根据跳变顺序判断正反转。代码写出来一跑，云台反应迟钝不说，稍微转快一点，计数就乱套，丢脉冲、误判方向是家常便饭。主循环被其他任务（比如刷新显示、处理通信）一耽搁，编码器的状态早就变了不知道多少次了。那感觉就像你想用肉眼去数一个高速旋转风扇的扇叶，根本看不清。

这个问题逼着我必须把“轮询”这种低效且不可靠的方式扔掉，转向“中断”。编码器本质上是一个产生数字脉冲序列的传感器，处理它的最佳拍档就是定时器的编码器接口模式，再配合中断来及时处理计数溢出、方向变化等事件。而定时器中断本身，更是STM32乃至所有MCU编程的基石，从精准延时、PWM生成到周期性的数据采集，无处不在。但很多新手（包括当时的我）对这两者结合的理解是割裂的：知道定时器能配置成编码器模式，也知道定时器能产生中断，但如何让编码器的工作与中断服务程序优雅、高效地协同，中间有很多细节需要厘清。

所以，这篇笔记就围绕“编码器”与“定时器中断”的联姻展开。它不是简单的寄存器配置清单，而是想和你聊聊，当定时器工作在编码器模式下，我们如何通过中断来拓展它的能力边界，处理那些“轮询”搞不定的场景，比如高速计数、长距离位移、多圈绝对位置记录等。我会结合STM32F1和F4系列，用CubeMX配置和HAL库代码作为主线，但更重要的是说清楚背后的原理和那些容易踩进去的坑。无论你是正在做智能车测速、机械臂关节定位，还是任何需要精确检测旋转运动的项目，希望这些内容能帮你把轮子“转”得既快又准。

2. 定时器编码器模式：硬件自动化的计数艺术

在深入中断之前，我们必须先彻底理解STM32定时器的编码器接口模式做了什么。这是整个体系的硬件基础，理解了它，中断的作用和配置才会顺理成章。

2.1 编码器信号与定时器的“对口”连接

常见的增量式旋转编码器输出两路相位差90度的方波信号（A相和B相）。根据旋转方向不同，两路信号的相位领先关系会互换。STM32的通用定时器（如TIM1, TIM2, TIM3, TIM4等）和高级定时器，其内部有两个专用的输入通道（TI1和TI2），可以完美对接这两路信号。

关键点在于，定时器的编码器模式并不是简单地读取某个引脚的电平，而是一个硬件状态机。当你使能了编码器模式，定时器硬件会自动根据TI1和TI2的边沿跳变和相对相位，来更新内部的计数器（CNT）寄存器。这个过程的精髓是“自动”，完全由硬件完成，不占用CPU资源。CPU可以完全不管计数器，直到有“重要事件”发生时才通过中断介入。

配置编码器模式时，通常有几个核心参数：

• 编码器模式（Encoder Mode）：通常选择Encoder Mode TI1 and TI2。这意味着定时器会在TI1和TI2两个通道的所有边沿（上升沿和下降沿）都进行计数。这是分辨率最高的模式，编码器每转动一个最小机械角度（对应一个脉冲周期），定时器会计数4次，这就是常说的“4倍频”。例如，一个100线的编码器，在此模式下转一圈，定时器会计数400次。
• 极性（Polarity）：这里容易混淆。它指的是定时器捕获/比较通道的极性，对于编码器输入，通常保持默认的“不反相”（Rising Edge）。编码器方向的判断依赖于A、B相的相对相位，硬件已经处理好了，我们通常不需要在这里反相。
• 滤波器（Filter）：这是防抖的关键。编码器是机械或光电元件，在电平跳变时可能会产生毛刺。定时器内置了数字滤波器，你可以设置一个采样频率和数字滤波深度。例如，设置滤波器值为6，表示信号需要连续6个时钟周期保持稳定才被认为有效。这个值需要根据你的信号质量和定时器时钟来权衡，太小了防抖效果差，太大了可能滤掉高速的有效信号。

在CubeMX中的配置直观明了：找到你想用的定时器，在Combined Channels中选择Encoder Mode，然后在下方的参数设置中完成上述配置。硬件上，把编码器的A、B相分别接到定时器对应的TI1和TI2引脚即可。

2.2 计数器方向与数值的硬件逻辑

一旦配置好，硬件就开始工作了。定时器硬件会根据TI1和TI2的边沿序列，自动判断旋转方向，并控制计数器CNT是递增还是递减。

• 当编码器正转时，CNT值递增。
• 当编码器反转时，CNT值递减。

这个方向判断是硬件实时完成的，极其可靠且快速，远非软件轮询可比。而且，CNT是一个16位或32位（取决于定时器）的有符号整数。在“4倍频”模式下，一个100线的编码器转一圈，CNT变化±400。如果你想知道当前位置相对于某个零点的“脉冲数”，直接读取CNT寄存器就行。

但这里就引出了第一个核心问题：CNT的计数范围是有限的。对于一个16位定时器，CNT从0计数到65535（如果配置为向上计数）。当正转超过65535时，它会溢出回到0；反转低于0时，它会下溢回到65535。这个溢出/下溢事件，就是我们引入定时器中断的第一个重要理由。

3. 定时器中断的引入：处理边界与扩展能力

单纯使用编码器模式，在低速、短距离测量时可能没问题。但一旦涉及连续旋转、长距离定位或者高速测量，我们就必须主动处理计数器的边界问题，并利用中断来实现更复杂的功能。

3.1 更新中断（UEV）：捕获溢出事件

定时器最基本的中断是“更新中断”（Update Event Interrupt），它由更新事件（UEV）触发。什么情况下会产生更新事件？

1. 计数器溢出（向上计数到ARR）或下溢（向下计数到0）。
2. 软件强制产生更新事件。
3. 在从模式控制下由硬件触发。

对于编码器应用，情况1是我们最关心的。但这里有个关键：在编码器模式下，定时器的自动重装载寄存器（ARR）通常被设置为最大值（例如0xFFFF对于16位定时器）。为什么？因为编码器模式下的计数方向是硬件自动控制的，我们无法预知它会一直加还是一直减。如果我们把ARR设为一个固定值（比如999），期望计数器在0-999之间循环，那么当编码器反转时，计数器从0减到-1，硬件会怎么处理？实际上，它会下溢变成ARR的值（999），这会导致位置计算出现巨大的跳变，是完全错误的。

因此，在纯编码器接口模式下，我们通常不依赖ARR来产生周期性的更新中断，而是让计数器自由地递增或递减，直到达到其数据类型的边界（16位的0xFFFF/0x0000）。当正转超过0xFFFF时，CNT变为0，同时硬件会置位一个“计数器上溢”标志；当反转低于0x0000时，CNT变为0xFFFF，同时置位“计数器下溢”标志。这个溢出事件，同样会触发更新中断（UEV）。

所以，我们的第一个中断策略就是：使能定时器的更新中断。在中断服务程序（ISR）中，我们检查是否是溢出导致的更新，然后通过一个软件变量（比如一个int32_t类型的overflow_count）来记录溢出的次数。

• 正转溢出时，overflow_count++。
• 反转下溢时，overflow_count--。

这样，结合overflow_count和当前的CNT值，我们就可以计算出不受16/32位限制的、连续的“扩展位置”。例如：真实位置 = overflow_count * 65536 + CNT（对于16位定时器）。

3.2 捕获/比较中断：进阶应用的可能性

除了更新中断，定时器在编码器模式下还可以利用其他通道吗？答案是肯定的，但需要一些技巧。定时器的通道1（CH1）和通道2（CH2）已经被编码器信号占用了，但通道3（CH3）和通道4（CH4）通常是空闲的。我们可以把它们配置为输入捕获或者输出比较模式，并开启相应的中断。

场景一：限位中断假设你的旋转机构有物理限位，当转到某个角度时必须停止。你可以在编码器转轴上加一个霍尔传感器或微动开关，将其信号接到TIMx_CH3。将CH3配置为输入捕获模式，上升沿或下降沿触发。当限位开关被触发时，就会产生一个捕获中断。在中断里，你可以立即关闭电机驱动，防止机械损坏。这比在主循环里查询IO口要及时得多。

场景二：软件预设位置中断你希望编码器转到某个特定的“扩展位置”（比如真实位置 = 50000）时，系统能立即做出反应。由于CNT只在0-65535循环，直接比较CNT不行。我们可以利用输出比较模式。虽然不能直接比较“扩展位置”，但我们可以利用更新中断。在更新中断里，我们计算当前的真实位置。当真实位置接近目标位置（比如相差1000个计数）时，我们可以动态地配置一个输出比较通道（比如CH3），将它的比较值（CCR3）设置为一个在未来很短计数内会匹配到的值（例如当前CNT+100）。一旦CNT计数到CCR3，就会触发比较匹配中断，我们在那个中断里执行精确的动作。这是一种“软件引导”的精确位置中断。

这些进阶用法打破了“编码器只用更新中断”的思维定式，展现了“定时器中断”这个工具箱的灵活性。

4. CubeMX配置与代码实战：从零搭建一个带中断的编码器模块

理论说再多，不如一行代码。我们以STM32F407的TIM3为例，使用CubeMX和HAL库，一步步配置一个带更新中断的编码器接口，并实现扩展位置计算。

4.1 CubeMX图形化配置步骤

1. 引脚配置：找到TIM3，确认其CH1和CH2对应的引脚（例如PA6和PA7）。将这两个引脚的功能设置为TIM3_CH1和TIM3_CH2。
2. 定时器参数配置：
   • 在Counter Settings中，Prescaler（预分频器）设为0。编码器模式时，预分频器通常不起作用，时钟直接驱动计数器。
   • Counter Mode会自动变为Encoder Mode，无需手动选择。
   • Period (ARR)设置为65535（对于16位定时器）。这就是最大值，让计数器自由运行。
   • Internal Clock Division和AutoReload Preload保持默认。
3. 编码器模式配置：
   • 在Combined Channels中选择Encoder Mode。
   • 下方参数面板会出现编码器设置。
   • Encoder Mode选择Encoder Mode TI1 and TI2（4倍频）。
   • TI1 Polarity和TI2 Polarity保持Rising Edge。
   • TI1 Filter和TI2 Filter根据你的编码器信号质量设置。如果用手拧的编码器，有点抖动，可以设为6或7。如果是高速电机上的光电编码器，信号干净，可以设为0或1。
4. 中断配置：
   • 最关键的一步：在NVIC Settings选项卡中，找到TIM3 global interrupt，勾选Enabled。
   • 注意：这里使能的是全局中断。对于编码器，我们主要处理更新事件，所以还需要在代码中使能更新中断。
5. 生成代码：配置时钟树等其他必要参数，然后生成代码。

4.2 HAL库代码实现与解析

CubeMX生成的代码搭建了框架，我们还需要添加核心逻辑。

第一步：启动定时器与中断在main.c的初始化部分（/* USER CODE BEGIN 2 */之后），启动定时器并明确使能更新中断。

/* 启动TIM3的编码器接口 */ HAL_TIM_Encoder_Start(&htim3, TIM_CHANNEL_ALL); /* 明确使能TIM3的更新中断 */ __HAL_TIM_ENABLE_IT(&htim3, TIM_IT_UPDATE);

HAL_TIM_Encoder_Start函数会启动定时器的编码器模式。__HAL_TIM_ENABLE_IT是一个宏，用于使能特定的定时器中断。这里我们使能更新中断（TIM_IT_UPDATE）。

第二步：定义全局变量记录溢出在main.c文件顶部，定义全局变量。

/* USER CODE BEGIN PV */ int32_t encoder_overflow_count = 0; // 溢出计数 int32_t encoder_total_count = 0; // 扩展位置 /* USER CODE END PV */

第三步：编写中断回调函数HAL库的中断处理逻辑是：硬件中断发生后，进入TIM3_IRQHandler（由CubeMX生成），它调用HAL_TIM_IRQHandler，后者再根据中断标志位调用对应的回调函数。我们需要重写更新中断的回调函数。 在main.c中，找到/* USER CODE BEGIN 4 */区域，添加：

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM3) { // 判断是上溢还是下溢 uint16_t current_cnt = __HAL_TIM_GET_COUNTER(&htim3); // 获取当前CNT值 // 检查计数方向。在编码器模式下，DIR寄存器位是有效的。 if (__HAL_TIM_GET_DIRECTION(&htim3) == TIM_COUNTERDIR_UP) { // 如果当前方向是向上计数，那么刚刚发生的是从ARR->0的上溢（正转溢出） encoder_overflow_count++; } else { // 方向向下，发生的是从0->ARR的下溢（反转溢出） encoder_overflow_count--; } // （可选）在这里可以计算一次扩展位置，或者在其他地方需要时再计算 // encoder_total_count = encoder_overflow_count * 65536 + current_cnt; } }

注意：这里有一个非常重要的细节。我们不能简单地根据encoder_overflow_count++或--来判断方向，因为中断发生时，CNT已经变成了0或65535。我们通过__HAL_TIM_GET_DIRECTION这个宏来读取定时器内部的计数方向寄存器位，这个位是由硬件根据编码器相位实时设置的，非常可靠。这是判断溢出方向的正统方法。

第四步：获取扩展位置在任何需要知道编码器绝对位置的地方（例如在主循环，或者另一个定时中断里），你可以这样计算：

int32_t get_encoder_total_position(void) { uint16_t current_cnt; int32_t total_pos; // 为了确保读取的原子性，最好暂时关闭中断 __disable_irq(); current_cnt = __HAL_TIM_GET_COUNTER(&htim3); total_pos = encoder_overflow_count * 65536 + (int16_t)current_cnt; // 注意将current_cnt转为有符号数 __enable_irq(); return total_pos; }

将current_cnt转换为int16_t是关键。因为当CNT从32767继续正转一次，硬件上它会变成32768。但如果我们用uint16_t看待它，32768是正数。而转为int16_t后，32768会被解释为-32768，这样与overflow_count结合计算时，才能得到连续的正确位置。例如，overflow_count=0, CNT=32768时，计算为0*65536 + (-32768) = -32768，这表示从0位置反转了32768个计数。

5. 避坑指南与性能优化：来自实战的经验教训

把代码跑起来只是第一步，让它稳定、可靠、高效地运行在真实项目中，才是更大的挑战。下面是我在多个项目中总结的几个关键点和容易踩的坑。

5.1 中断服务程序（ISR）的“瘦身”原则

定时器中断，特别是编码器的更新中断，可能发生在高速计数的场景下（虽然溢出频率不会像计数频率那么高）。我们必须保证ISR的执行时间尽可能短。

• 错误示范：在HAL_TIM_PeriodElapsedCallback中进行复杂的数学运算、调用HAL_Delay、通过串口大量打印调试信息。
• 正确做法：
  1. 只做最必要的事：在溢出中断里，我们只更新encoder_overflow_count这个变量。像计算encoder_total_count这种可以放在主循环或更低优先级的任务中。
  2. 使用标志位：如果需要在溢出时触发某个复杂任务，可以在ISR里设置一个布尔标志位（如uint8_t encoder_updated = 1;），然后在主循环中检查这个标志位并执行相应任务。
  3. 注意变量类型和原子性：encoder_overflow_count是int32_t，在32位ARM上它的读写是原子的（一条指令完成）。但在中断和主程序共享时，如果主程序正在读取encoder_overflow_count和CNT计算总位置时被中断打断，可能会读到不一致的数据（刚读完overflow，中断发生并修改了它，然后读CNT）。这就是为什么在get_encoder_total_position函数中，我建议用__disable_irq()和__enable_irq()来临时关闭中断，实现一个“临界区”，保证读取的原子性。对于更复杂的系统（如RTOS），可能需要使用信号量或互斥锁。

5.2 滤波器配置的权衡：稳定与响应速度

前面提到的数字滤波器（ICx_Filter）是一把双刃剑。

• 值太小（如0或1）：几乎无滤波。编码器信号有轻微抖动（特别是廉价的EC11编码器）时，会导致计数器在某个位置来回跳动几个LSB，读出的位置会有噪声。在低速或静止时，你会看到数值在小范围波动。
• 值太大（如15）：滤波效果强，能有效抑制抖动。但副作用是引入了“延迟”。高速旋转时，边沿跳变很快，滤波器需要连续多个时钟周期确认稳定信号，可能导致脉冲被“吞掉”，表现为高速下计数不准，丢失脉冲。
• 调试建议：
  1. 先用示波器或逻辑分析仪看一下编码器信号的波形，观察抖动情况。
  2. 初始调试时，可以设置一个中等值（如6）。
  3. 编写测试代码：让电机匀速旋转，同时用另一个高精度定时器中断以固定频率（比如1kHz）读取编码器位置，并计算速度。观察在不同滤波器设置下，计算出的速度波动情况。选择一个在静止时稳定、在最高工作转速下仍能准确计数的值。

5.3 多圈绝对位置与断电保存

通过“溢出计数+当前CNT”的方法，我们实现了软件上的多圈绝对位置记录。但这带来两个新问题：

1. 上电初始化位置：系统重启后，encoder_overflow_count变量清零，CNT寄存器会从上次停止的位置开始（因为GPIO状态可能保持）。这时计算出的“绝对位置”是错的。因此，编码器系统必须有一个“归零”或“寻参考点”的过程。常见做法是：
   • 限位开关：设备上电后，自动向一个方向运动直到触发限位开关，将此点设为位置零点。
   • Z相信号：很多编码器除了A、B相还有Z相（零位信号），每转一圈产生一个脉冲。上电后，可以低速旋转寻找Z相信号，找到后结合圈数计算绝对位置。这需要将Z相信号接到另一个定时器通道或外部中断引脚。
   • 绝对式编码器：如果项目要求严格，应考虑使用串行通信的绝对式编码器（如SPI、SSI接口），它上电就能直接读出绝对角度，无需归零。
2. 断电保存：如果设备需要记忆断电前的位置，那么encoder_overflow_count这个变量必须保存在非易失存储器中（如Flash、EEPROM）。注意，不能频繁保存，会损坏存储器。通常只在收到停机命令、进入休眠模式或断电预警（如有后备电池电容）时保存。恢复时，从存储器读出overflow_count，并将CNT寄存器也设置为保存时的值（使用__HAL_TIM_SET_COUNTER），以保证位置连续性。

5.4 应对极端速度与中断风暴

在极高转速下，编码器脉冲频率可能接近甚至超过定时器计数时钟。此时，不仅要考虑计数器溢出中断的频率，还要考虑MCU处理中断的能力。

• 计算中断频率：假设编码器100线，4倍频后每转400计数。电机额定转速3000转/分（50转/秒）。那么每秒脉冲数 = 50 * 400 = 20000 Hz。对于16位定时器（65536计数），溢出频率 = 20000 / 65536 ≈ 0.305 Hz。这个频率很低，中断压力不大。
• 但如果使用32位定时器（如STM32F4的TIM2/TIM5），计数范围高达42亿。在上述转速下，可能几个小时才溢出一次，几乎不需要溢出中断。此时，你可以完全依赖读取CNT来获取相对位置，结合Z相信号或外部事件来校正圈数。
• 中断风暴：如果编码器信号受到严重干扰，可能会产生非正常的快速跳变，导致定时器错误地频繁触发更新或其他中断，甚至让MCU卡死在中断里。除了硬件上做好滤波和屏蔽，软件上可以在中断入口处增加“看门狗”机制，比如记录最近一次中断的时间戳，如果两次中断间隔异常短（例如小于一个正常脉冲周期的最小时间），则判定为干扰，忽略此次中断并复位相关标志。

编码器和定时器中断的结合，是STM32把一个简单外设玩出花来的经典案例。它把最耗时、最要求实时性的脉冲计数和方向判断交给了硬件，让CPU得以解放出来处理更复杂的逻辑，只在关键的“溢出”时刻通过中断介入。这种硬件加速与软件控制的分工，正是嵌入式系统设计的精髓。从配置好第一个编码器中断，看着它稳定地记录下成千上万的脉冲而不再丢失那一刻起，你才算真正开始驾驭STM32的定时器模块。