树莓派Pico定时器采样消抖：旋转编码器稳定读取方案

做旋钮类的小项目，最烦的事情不是画板子、不是写逻辑，而是旋转编码器读数乱蹦。明明拧了一下，串口打印出来“+1 -1 +1 -1”来回跳，仿佛编码器有自己的脾气。这个问题困了我挺久，试过硬件RC滤波、试过轮询延时、也试过在中断里做软件消抖，最后在树莓派Pico上用MicroPython的定时器采样方案把问题彻底解决了。

这篇文章就把我完整踩过一遍的方案讲清楚：旋转编码器的抖动到底是怎么来的，为什么我最后选定时器而不是中断，Pico上怎么接、Timer怎么配，以及完整可抄的MicroPython代码和参数调整经验。适合正在做旋钮输入、菜单选择、音量调节这类项目的朋友参考，也适合那些被编码器消抖折磨到想砸键盘的开发者。

1. 旋转编码器的工作原理与抖动是从哪来的

1.1 AB相输出不是两个独立的开关

很多人第一次拿到旋转编码器，看到CLK和DT两个引脚就以为这是两个普通按键触点，转一格它们分别动作一次。这个理解是错的，但错得很常见，因为它不至于影响最基本的读数。

旋转编码器内部是两组机械触点，转动时CLK和DT输出的是两路存在相位差的方法信号。以最常见的增量式编码器为例，每转一格，CLK和DT的电平组合会按照特定顺序变化。比如某个型号顺时针旋转时状态序列是：00 -> 01 -> 11 -> 10 -> 00，逆时针则是：00 -> 10 -> 11 -> 01 -> 00。两路电平组合在一起，既包含了步数信息，也包含了旋转方向信息，这个设计叫正交编码。

打个生活化的比方：想象两排在门口轮流喊号的人，A先喊了B才喊，说明队伍往右走；B先喊了A才喊，说明队伍往左走。单独听任何一个人的声音都判断不了队伍方向，但两边的喊声顺序一对比，方向就清楚了。编码器的AB相就是那两个喊号的人。

1.2 机械抖动为什么非治不可

编码器本质上就是一排金属弹片，旋钮转动时拨片在金属齿上滑动，触点完成闭合和断开。问题就出在这个“完成”上——机械结构的接触不是一瞬间就能稳定下来的。

旋钮每转一格，触点会在几百微秒到十几毫秒的时间内反复颤动，信号表现为高频的“毛刺”和电平来回跳变。如果在程序里用边沿触发中断读引脚，一次实际旋转会被记成好几次脉冲，更麻烦的是抖动可能让A相B相的状态顺序被打乱，方向和步数一起错乱。

打个比方：手动快速连点一个机械按键，程序会收到很多次按下事件，但你真的只想让它执行一次。旋转编码器的抖动本质是一样的，只是问题更隐蔽——它不是独立的两次点击，而是一堆无规律的状态翻转。

所以消抖的本质只有一个目标：把“真实的状态变化”和“抖动造成的伪变化”区分开。明确了这一点，后面的所有方案选择都是为了解决这一个问题。

2. 定时器消抖方案的选择逻辑与优缺点分析

2.1 硬件RC滤波方案怎么取舍

最常见的硬件消抖方案是在CLK和DT引脚上各接一个RC低通滤波器，用电阻和电容把高频抖动信号“压平”。一个10kΩ电阻串联到引脚，再接一个0.1μF电容到地，就可以把几十kHz以上的高频毛刺滤掉，让单片机读到一个平滑的脉冲沿。

这个方案的优点很突出：实时性好，不占CPU，不会延迟读取，纯硬件解决，适合批量量产的产品。我之前在一个批量项目里就用这种方式，稳定性和一致性都不错。

但它的缺点也很明确：一是增加器件和PCB面积，开发阶段频繁改版会很烦；二是RC参数必须和编码器输出频率匹配，电容选大一点快速转动手感会变“黏”，旋转脉冲被拉成三角波导致丢步，电容选小了又滤不干净。调试RC参数本身就是一个反复试错的过程。

所以RC滤波适合最终定型产品，不适合开发初期快速验证逻辑。这也是我后来改用软件方案的核心原因。

2.2 阻塞延时消抖的坑有多深

网上很多教程处理旋转编码器用的是最简单粗暴的方式：检测到引脚变化后，用time.sleep_ms(10)等抖动过去，再读一次确定最终电平。逻辑确实简单，几行代码就能跑起来。

但实际用起来会被恶心到。time.sleep_ms会阻塞整个程序，MCU在这个时间段内什么都干不了。如果你的项目里还有OLED刷新、舵机控制、按键扫描，或者任何一个需要及时响应的任务，一次阻塞10ms可能还能忍，但编码器转动时每次变化都要阻塞，整个系统就會变得很“肉”，旋钮转起来明显感觉响应迟钝。

另外一个隐藏问题：在MicroPython这种解释型语言里，time.sleep_ms的阻塞会让定时器回调、外设中断的响应都跟着延迟，严重时甚至造成看门狗超时。我第一次在带OLED显示的项目里用阻塞消抖，就发现画面刷新和旋钮响应互相拖累，后来果断放弃了这种方案。

2.3 定时器周期采样方案的优势

定时器方案的核心思路是：不依赖边沿触发，而是每隔固定时间周期性地去读一次引脚电平，把“事件驱动”变成“采样驱动”。

这样做的好处有三个。第一，主循环完全不被阻塞，定时器回调在中断上下文执行，读引脚和简单判断都很快，业务逻辑照常跑；第二，抖动会被拉长成多次采样，程序通过“连续多次采样一致才确认变化”来过滤毛刺，逻辑上天然具有抗抖能力；第三，代码结构清晰，阈值可调，遇到不同质量的编码器只需要改一个参数，不用改硬件。

树莓派Pico的machine.Timer在MicroPython环境下，定时精度的颗粒度大约是微秒级到毫秒级，做5ms量级的周期采样完全够用。手动旋转编码器时脉冲宽度通常在毫秒级，最短也会在1ms以上，所以5ms采样不会漏掉真实的旋转脉冲。

这就解决了定时器能不能用的核心疑虑：Pico不是STM32，MicroPython的定时器精度也到不了纳秒级，但做旋转编码器的消抖，它的精度和响应速度都绰绰有余。

3. 硬件接线与MicroPython定时器配置要点

3.1 引脚选型与接线表

树莓派Pico的GPIO引脚资源比较丰富，GP0到GP28都可以用作普通输入。但选择引脚时要注意避开已经占用的外设复用脚，比如I2C和UART。

我习惯把编码器接在GPIO10和GPIO11上，这两个引脚不算热门外设复用脚，不容易和I2C（GP0/GP1、GP4/GP5）、UART（GP0/GP1、GP4/GP5、GP8/GP9、GP12/GP13）冲突，后续如果加OLED或者传感器也方便排线。

接线表如下：

注意Pico的3.3V供电能力有限，编码器模块本身功耗很低，直接从3V3引脚取电没问题，不用额外接外部电源。

3.2 上拉电阻是必须的

编码器输出通常是开漏结构，引脚浮空时电平不确定，读数会乱跳。解决方法是给CLK和DT接上拉电阻。很多成品编码器模块（比如带PCB小板的那种）已经集成了上拉电阻，直接用就行。但如果你用的是裸编码器，务必在代码里启用Pico的内部上拉。

MicroPython里的写法很简单：

from machine import Pin clk = Pin(10, Pin.IN, Pin.PULL_UP) dt = Pin(11, Pin.IN, Pin.PULL_UP)

用Pin.PULL_UP参数启用内部上拉。Pico的内部上拉阻值大约50kΩ，配合输入引脚的高阻抗，已经能稳定读取电平。如果信号线比较长或者环境电磁干扰明显，可以在外部并联一个10kΩ上拉电阻到3.3V，效果更稳。

3.3 MicroPython定时器初始化

Pico的定时器在MicroPython里用machine.Timer模块创建和启动。创建一个周期为5ms的定时器只需要两行：

from machine import Timer timer = Timer() timer.init(period=5, mode=Timer.PERIODIC, callback=enc_cb)

period的单位是毫秒，mode用Timer.PERIODIC表示周期重复模式，callback指向每次定时中断时执行的函数。

这里有一个非常重要的坑：回调函数里不要写太重的代码。MicroPython运行在虚拟机之上，Python代码的执行速度比C慢得多，如果在回调里做print、字符串拼接、列表操作这类耗时动作，回调的执行时间可能超过定时周期本身。轻则导致定时不准，重则丢失下一次中断触发，逻辑错乱。

回调里最安全的操作就是：读引脚状态、整数运算、全局变量赋值。需要观察数据的话，在回调里置一个标志位，主循环检测到标志位之后再打印。

4. 核心实现：定时器采样消抖与状态机方向判断

4.1 消抖算法的数据流

定时器消抖方案里，每一轮定时中断都要处理这么几个变量：

• raw_previous：上一轮采样的原始AB组合值
• stable_count：与上一次相同的连续采样次数
• last_stable：上一次确认的稳定状态值

每次进回调，先读取当前AB两脚的电平组合，记为raw。如果raw和raw_previous相同，说明这次采样和上次一致，stable_count加1；如果不同，说明有变化发生，更新raw_previous并把stable_count归零。

只有当stable_count达到预设阈值（比如3次，也就是连续3次采样都相同，代表电平已经稳定了至少2个周期）且raw与last_stable不同的时候，才认为发生了一次有效的状态变化。这时更新last_stable，并把新状态交给方向判断逻辑。

这个逻辑用文字说有点绕，代码实现反而清晰：

def enc_cb(timer): global last_stable, raw_previous, stable_count, position raw = (clk.value() << 1) | dt.value() if raw == raw_previous: stable_count += 1 else: raw_previous = raw stable_count = 0 if stable_count < STABLE_CNT_THRESHOLD: return if raw == last_stable: return d = direction(last_stable, raw) if d != 0: position += d last_stable = raw

核心思想就是把“变化”和“确认”分开。raw_previous记录的是原始采样轨迹，last_stable记录的是确认过的稳定状态，两者之间有明显的语义区分。

4.2 方向判断状态机的实现

旋转编码器的方向判断，说到底就是在状态转移表里查方向。我们需要知道当前状态是从哪里来的、到了哪里去，才知道旋转方向。

前面提过，顺时针状态序列是 00 -> 01 -> 11 -> 10，逆时针是 00 -> 10 -> 11 -> 01。把二进制状态转成十进制就是：顺时针 0 -> 1 -> 3 -> 2，逆时针 0 -> 2 -> 3 -> 1。

查表实现方向判断：

def direction(prev, curr): # 顺时针转移：0->1->3->2->0 if (prev, curr) in ((0, 1), (1, 3), (3, 2), (2, 0)): return 1 # 逆时针转移：0->2->3->1->0 if (prev, curr) in ((0, 2), (2, 3), (3, 1), (1, 0)): return -1 # 非相邻状态：漏采样或抖动干扰，忽略 return 0

这里有三个细节需要说明。

第一，表里只写“相邻状态”的合法转移。如果出现从0直接跳到3的状态，说明中间状态被漏采了，这种时候返回0选择忽略，而不是强行猜测方向。在定时器采样方案里，只要采样周期设置合理，漏采率很低，偶尔出现一次漏采直接丢弃比猜错方向危害小得多。

第二，方向判断的时机点很重要。整个逻辑中，direction函数只会在raw != last_stable且状态已稳定的情况下被调用。也就是说，它判断的永远是“上一次稳定状态”和“当前稳定状态”的转移，而不是“上一次采样”和“当前采样”的转移。这个区别让抖动期间的所有毛刺都被预先过滤掉。

第三，如果发现方向反了，有两种处理方式。最直接的是交换CLK和DT接线，物理层面的修正；如果不想动线，也可以把direction函数中返回1和-1的地方对调。二选一，别都做，否则又反过来了。

4.3 完整可用的MicroPython代码

把上面所有逻辑串起来，加上必要的初始化，就是一个完整的消抖读取程序：

from machine import Pin, Timer import time # 接线定义 CLK_PIN = 10 DT_PIN = 11 # 配置输入引脚，启用内部上拉 clk = Pin(CLK_PIN, Pin.IN, Pin.PULL_UP) dt = Pin(DT_PIN, Pin.IN, Pin.PULL_UP) # 消抖参数 STABLE_CNT_THRESHOLD = 3 # 连续采样一致次数 SAMPLE_PERIOD_MS = 5 # 定时器采样周期 # 全局变量 last_stable = (clk.value() << 1) | dt.value() raw_previous = last_stable stable_count = 0 position = 0 def direction(prev, curr): # 顺时针转移：0 -> 1 -> 3 -> 2 -> 0 if (prev, curr) in ((0, 1), (1, 3), (3, 2), (2, 0)): return 1 # 逆时针转移：0 -> 2 -> 3 -> 1 -> 0 if (prev, curr) in ((0, 2), (2, 3), (3, 1), (1, 0)): return -1 return 0 def enc_cb(timer): global last_stable, raw_previous, stable_count, position raw = (clk.value() << 1) | dt.value() if raw == raw_previous: stable_count += 1 else: raw_previous = raw stable_count = 0 if stable_count < STABLE_CNT_THRESHOLD: return if raw == last_stable: return d = direction(last_stable, raw) if d != 0: position += d last_stable = raw # 初始化定时器，5ms周期采样 timer = Timer() timer.init(period=SAMPLE_PERIOD_MS, mode=Timer.PERIODIC, callback=enc_cb) # 主循环：读位置值并显示 while True: print("position:", position) time.sleep_ms(100)

这个代码里我特别处理了一个初始化细节：last_stable和raw_previous在定时器启动前就先读取一次编码器的当前状态，避免上电瞬间状态未知造成误判。

主循环里每100ms打印一次position，在实际项目中替换成你自己的业务逻辑就行，比如在这个位置增加范围限制、配合SW按键做菜单确认、控制舵机角度等。

5. 参数调优与实测经验记录

5.1 采样周期怎么选

采样周期的选择是消抖方案里最核心的权衡。选太短，抖动还没稳定就采样，消抖效果差；选太长，快速旋转时会漏掉真实脉冲，表现为“转快就丢步”。

实际调试时我总结了下面的参考区间：

我自己的经验是，手动拧编码器时最短的有效脉冲宽度通常在1ms到5ms之间，所以5ms采样周期配合连续3次一致（也就是至少10ms的稳定时间）就能滤掉绝大多数抖动。如果你用的编码器质量一般，抖动比较久，可以把STABLE_CNT_THRESHOLD从3改成5，稳定时间拉长到20ms，消抖效果立刻变好，代价是快速旋转时响应稍微变慢。

这里要理解一个原理：采样周期决定的是“多久看一次信号”，阈值决定的是“连续看到几次相同才算稳”。两个参数互相配合，比如保持总稳定时间不变，采样周期变小，阈值就得调大；采样周期变大，阈值可以调小。总稳定时间估算公式是：(STABLE_CNT_THRESHOLD - 1) * SAMPLE_PERIOD_MS。

5.2 硬件层面的补强细节

如果信号线比较长，或者应用环境有电机、电源等干扰源，光靠软件消抖有时候不够。这时候可以给CLK和DT各加一个对地电容，形成简单的低通滤波，把高频噪声在硬件上先滤一道。

电容值建议从0.1μF开始试。太小了滤波效果不明显，太大了会把脉冲沿拉缓，快速旋转时信号变形导致丢步。在明纬的干扰环境下，0.1μF配合10kΩ上拉是比较稳妥的组合。

另外一个容易被忽略的细节是接地。Pico的GND和编码器GND必须在同一根线上连好，接法要短、粗、直接。如果编码器供电来自3V3、Pico也用自己的3V3，但两者GND有电压差，读数就会不稳定。我在一次调试中遇到过类似问题，后来把共地线重焊了一遍就恢复正常了。

5.3 实测效果记录

我用一个报价十来块的国产旋转编码器做了实测，旋钮模拟音量调节，快速旋转450步然后反方向转回0点。

5ms采样、阈值3次的配置下，快速旋转时串口打印的position数值递进非常均匀，没有跳变，反转450步后能准确回到0点，说明正反方向都没有丢步也没有多步。慢速旋转时一格一格地微调，读数稳定，不会出现转一格跳好几下的情况。

换一个性能较差的裸编码器测试，抖动明显更严重，5ms/3次出现了偶尔的上下反复跳变。把阈值调到5次之后，情况明显好转，代价是快速旋转时偶尔会漏掉一两步。这个结果说明一个问题：编码器本身的机械质量对消抖难度影响非常大，软件只能缓解，不能根治。

6. 常见问题与排查思路

6.1 读数乱跳或方向来回翻转

如果你设置好定时器后，position数值来回跳，优先排查三个地方。

先看接线和上拉。确认CLK和DT有没有接反，确认Pin.PULL_UP有没有启用。很多模块板上自带下拉电阻，这时再启用内部上拉会形成分压导致电平异常；反之如果模块没有上拉，内部上拉没启用，引脚浮空就会乱跳。两种情况的排查方法一样：把模块拉高或者拉低，用万用表量一下引脚电平是不是在正确区间。

再看阈值。把STABLE_CNT_THRESHOLD从3逐步调大到5、8，观察串口读数变化。如果阈值增大后跳动明显减少，说明原来的稳定时间不够长，抖动穿透了采样窗口。

最后确认回调里没有打印输出。我在调试初期习惯把raw直接打印到串口，结果发现回调执行时间过长，定时器节奏全乱，读数反而更差。调了好久才发现是print太耗时，改成标志位在主线打印后就正常了。

6.2 快速旋转丢步严重

如果慢速旋转正常、快速旋转丢步，基本可以断定是采样频率跟不上实际脉冲频率。解决思路有两个方向。

第一个方向：减小SAMPLE_PERIOD_MS，把5ms改成3ms甚至1ms，让采样更密集。但要注意阈值要相应调整，否则稳定时间又不够了。第二个方向：检查回调里有没有多余的计算。MicroPython回调里尽量只做整数比较和赋值，避免调用子函数、创建对象，这些都会增加执行时间。

另外要提醒的是，丢步还可能和编码器的机械性能有关。劣质编码器快速旋转时触点的弹跳极其剧烈，软件很大程度上已经尽力了，剩下的是硬件选型问题。预算允许的情况下换一个质量好一点的模块，效果立竿见影。

6.3 上电瞬间position跳动一下

上电时如果引脚电平还没稳定，last_stable的初始值可能不对，导致第一次稳定状态更新时误动一下。

处理方法我已经写在代码里了：在初始化定时器之前就读取一次clk.value()和dt.value()，把初始状态存入last_stable和raw_previous。只要定时器启动前读取完成，上电瞬间的电平毛刺就不会影响后续判断。

如果还是出现上电跳动，可以在初始化之前加一个短暂的time.sleep_ms(50)，让编码器内部触点在上电后完全稳定再采样。这种方法虽然用了阻塞延时，但在初始化阶段用一次是可接受的。

6.4 定时器回调拖慢整个程序

MicroPython的定时器回调运行在中断上下文里，如果回调内执行了过重的操作，不仅影响定时精度，还可能让主线程序卡顿。典型的重操作包括：print、字符串格式化、列表/字典操作、阻塞式的延时函数。

一个好的编码器回调用心法是这样的：

• 只允许整数运算和比较
• 只允许给全局变量赋值
• 不允许调用time.sleep_ms
• 不允许分配新的对象

需要和外部交互时，在回调里设置标志位或者累加变量，主循环里轮询处理。比如要打印position，就定义一个data_ready标志，回调里置1，主循环检测到后打印；或者像示例代码那样，主循环定时打印position的值，不回传回调内数据。

6.5 方向判断偶尔出错但步数对

步数对、方向偶错，这种情况通常是采样序列中出现了非法的状态跳转，direction函数对非相邻转移返回0忽略了。

仔细查一下direction函数里的状态编码顺序是否和你的编码器实际输出一致。不同品牌、不同型号的编码器，顺时针对应的状态序列可能有差异，甚至有的编码器一个周期内会跳过一个中间态（比如直接从00到11）。这种情况下，方向判断表需要根据实际波形定制，不能死套模板。

最简单的方法是先用示波器或者逻辑分析仪抓一下CLK和DT在慢速旋转时的波形，确认状态序列后再写查表逻辑。没有仪器的话，也可以用GPIO上拉，在串口打印每次raw的变化轨迹，人工记录状态顺序，再填入direction函数。

7. 延伸应用的几个方向

代码跑通之后，你会发现这个定时器消抖方案可以复用到很多场景。我简单说几个我自己试过的方向，给读者参考。

如果把direction函数判断出的方向换成音量值，position映射到0-100范围，配合Pico的DAC或者PWM输出，就是一个完整的数字音量旋钮。如果把position数值通过串口发出去，接一个上位机程序，就能做成电脑端的多媒体控制器，旋钮调音量、按SW键暂停播放。如果再接一个舵机，position映射到舵机角度范围，这就是一个手动调节舵机角度的旋钮控制方案。

这些扩展的核心复用点都在于：定时器负责消抖，状态机负责方向，position负责记录步数，三者解耦之后改起来非常顺手。不管上层接什么业务逻辑，消抖和方向判断这一层完全不需要动。

我自己后来在另一个项目里用同样的方案驱动了带按钮的旋转编码器，做菜单选择界面。旋钮切换菜单项，按压SW键进入子菜单，整个交互流畅度比我原先用阻塞延时方案做的版本强了很多，这也算是对这个方案的一个实际验证。