Encoder Mode 是 STM32 定时器硬件内置的正交解码功能，直接解析 A/B 相边沿组合并自动判向计数，不依赖 CPU 中断；而普通 GPIO 中断需软件判向，高速易丢脉冲。
Encoder Mode 是什么，和普通 GPIO 中断有什么区别
Encoder Mode 不是软件模拟的计数逻辑，而是 MCU 硬件定时器（如 STM32 的 TIMx）内置的编码器接口功能。它直接解析 A/B 相正交信号的边沿组合，自动完成方向判断和计数增减，不依赖 CPU 响应中断——这意味着即使高速旋转（比如 10k RPM），也不会丢脉冲；而用 GPIO 中断 + 软件判向，稍快就容易漏边沿、计错数。
关键点在于：必须用支持编码器接口的定时器通道（如 STM32F4 的 TIM1/TIM2/TIM3/TIM4/TIM5/TIM8），且 A/B 相必须接在该定时器指定的两个通道引脚上（例如 TIM2_CH1 和 TIM2_CH2），不能随意换脚。
-
TIMx_EncoderInterfaceConfig()是初始化核心，不是HAL_TIM_Encoder_Start()单独调用就能工作的 - A/B 相物理接入顺序影响计数方向：交换 A/B 接线，
DIR位会反，但计数值仍有效；若需固定方向，应在硬件或配置中统一相序 - 计数范围由
ARR（自动重装载值）决定，默认是 0xFFFF，溢出后自动回绕，读CNT寄存器即可，无需手动清零
STM32 HAL 库下启用 Encoder Mode 的三步硬要求
HAL 库封装了底层寄存器操作，但很多开发者卡在“调了函数却读不到变化”，根本原因是没满足硬件约束条件。
- 必须用
MX_TIMx_Init()生成的初始化结构体中，将Mode设为TIM_MODE_ENCODER，且CounterMode必须为TIM_COUNTERMODE_UP（HAL 强制要求，实际方向由硬件自动控制） - A/B 相引脚必须配置为
AF_PP（复用推挽），且Pull建议设为PULLUP（光电编码器通常开漏输出，需上拉） - 调用
HAL_TIM_Encoder_Start(&htimx, TIM_CHANNEL_ALL)后，**必须确保定时器时钟已使能**（HAL 自动生成代码里有__HAL_TIM_ENABLE(&htimx)，但若手动改过初始化流程，可能漏掉）
常见错误现象：__HAL_TIM_GET_COUNTER(&htimx) 始终返回 0 —— 多半是引脚复用没配对、定时器时钟未开启，或编码器本身未供电/断线。
立即学习“C++免费学习笔记（深入）”；
读取计数值时为什么不能直接用 HAL_TIM_GetCounter()？
HAL_TIM_GetCounter() 确实能读，但它只是简单返回当前 CNT 寄存器值。问题在于：正交解码是实时更新的，如果在计数过程中读，可能遇到“撕裂读取”（比如高字节刚更新、低字节还没变），尤其在 32 位计数器且高频计数时。
- 更安全的做法是先触发一次更新事件（UEV），再读：
__HAL_TIM_SET_COUNTER(&htimx, 0)不推荐；应使用__HAL_TIM_ENABLE_IT(&htimx, TIM_IT_UPDATE)+ 在中断里读，或用__HAL_TIM_GENERATE_EVENT(&htimx, TIM_EVENTSOURCE_UPDATE)强制同步 - 若只需相对位移，建议每次读完后记录上次值，做差分：
int32_t delta = current - last; last = current;，避免绝对计数溢出带来的符号误判 - 注意
CNT是有符号扩展的 16 位寄存器（STM32 大部分 encoder 模式只用 CNT[15:0]），读出来是 uint32_t 类型，但高位全为符号位复制，需强制转为 int16_t 再扩展，否则方向反转时显示巨大正数
实际部署时最容易被忽略的硬件细节
软件跑通不代表电机一转就准——90% 的现场误差来自这几点：
- 光电编码器的 A/B 相输出是集电极开路（OC）还是推挽（PP）？OC 型必须外接上拉电阻（通常 4.7kΩ），否则信号边沿无力，TIM 输入无法识别；HAL 配置里的
Pull只控制 MCU 内部上下拉，对外部 OC 输出无效 - 长线传输时未加磁珠或 RC 滤波，导致 A/B 相边沿振铃，被硬件误判为多次翻转；建议在编码器输出端就近加 100Ω 串联电阻 + MCU 引脚处并联 10nF 对地电容
- 机械安装偏心或轴向窜动，造成 A/B 相相位差偏离 90°，严重时硬件解码器会进入“不确定态”，计数值随机跳变；此时需用示波器抓两相信号，确认相位和占空比
别急着写闭环控制——先用逻辑分析仪看 A/B 波形是否干净、相位是否稳定，再信软件读出来的数字。
