簡介一套面向嵌入式入門與進階的STM32驅(qū)動EC11編碼器程序源碼工程用于測量旋轉(zhuǎn)角度、速度與方向并通過串口將數(shù)據(jù)上傳至上位機。資源壓縮包共120個文件、約2.23MB以C語言源文件、頭文件、Keil工程配置文件和可執(zhí)行文件為主同時包含腳本輔助文件工程結(jié)構(gòu)按初始化、中斷服務、數(shù)據(jù)計算和串口通信等模塊劃分便于直接查看和復用。目前該資源已被4139人瀏覽學習特別適合想掌握編碼器信號處理、STM32中斷系統(tǒng)、定時器捕獲模式以及USART串口通信的開發(fā)者。通過這套源碼可以學習EC11編碼器A、B兩路相位差90度脈沖的采集與判斷方法以及從定時器捕獲到數(shù)據(jù)封裝的完整實現(xiàn)。配合調(diào)試器與示波器進行信號驗證還能理解底層外設驅(qū)動與上位機數(shù)據(jù)交互的完整鏈路對嵌入式項目開發(fā)有直接的參考價值。 做儀器面板時我最常用的輸入設備不是觸摸屏而是旋鈕。調(diào)音臺的音量推子、示波器的菜單滾輪、3D打印機的微調(diào)旋鈕背后十有八九都是同一顆料——EC11編碼器。這顆幾塊錢的旋轉(zhuǎn)編碼器配上一塊STM32幾乎能解決所有“需要人手轉(zhuǎn)一下”的人機交互場景。這篇文章不聊空泛的概念直接圍繞EC11編碼器基于STM32程序源碼展開講清楚硬件怎么接、程序怎么寫、抖動怎么消、高速旋轉(zhuǎn)為什么丟步以及最后怎么落成一個能用的交互組件。不管是做畢業(yè)設計、個人項目還是產(chǎn)品原型這套東西都能直接抄作業(yè)。1. 為什么旋鈕類產(chǎn)品都在用EC11看懂A/B相波形再談接線1.1 EC11引腳定義與內(nèi)部結(jié)構(gòu)EC11雖然是機械旋轉(zhuǎn)編碼器但它的核心不是“電位器式的電阻變化”而是兩個觸點開關按固定節(jié)奏通斷。常見的EC11有五個引腳其中三個是旋轉(zhuǎn)檢測用的A、B、C公共端另外兩個是編碼器自帶的按鍵開關引腳。也有不帶按鍵的型號面板上只需要旋鈕的話就選五腳版本需要按壓確認就選帶開關的版本。按下旋鈕時按鍵引腳之間會導通這個邏輯和普通輕觸按鍵完全一樣所以電路和程序都可以復用按鍵處理的思路。旋轉(zhuǎn)的時候旋鈕內(nèi)部一個帶彈片的轉(zhuǎn)盤依次與固定觸點接觸A相和B相會交替導通和斷開產(chǎn)生兩路相位差剛好為90度的方波信號。1.2 波形特征與應用價值相位差90度是理解整個編碼器的鑰匙。正轉(zhuǎn)時A相跳變沿領先B相90度反轉(zhuǎn)時B相領先A相90度MCU只需要檢測誰領先誰就能判斷旋轉(zhuǎn)方向。更妙的是這種“相位差”檢測方式比單純數(shù)脈沖更可靠即使旋鈕在某個位置輕微抖動只要不跨越完整的相位狀態(tài)方向判定的結(jié)果也不會亂跳。EC11常見規(guī)格是一圈30個定位檔位也就是旋鈕轉(zhuǎn)一圈會發(fā)出30組A/B脈沖周期。實測時用示波器看A/B兩腳任意一腳都有明顯邊沿兩路信號存在穩(wěn)定的相位差這就說明編碼器本身工作正常問題大概率出在后級電路或軟件上。如果是用邏輯分析儀看更能清楚看到正轉(zhuǎn)時A相上升沿對應B相是高還是低反轉(zhuǎn)時對應關系正好反過來這正是后面軟件判向的基礎。2. 硬件抗干擾設計上拉電阻與濾波電容的參數(shù)選擇2.1 上拉方式選擇EC11的A/B輸出是開漏式的機械觸點必須配合上拉電阻才能輸出穩(wěn)定的高電平。選擇上拉電阻主要看兩個因素MCU供電電壓和信號頻率。3.3V供電的STM32一般推薦用10kΩ上拉到3.3V既保證觸點導通時電流不至于過大又能讓信號邊沿足夠陡峭。如果直接把EC11接到已經(jīng)配置了內(nèi)部上拉的GPIO上跑通Demo是可以的但抗干擾能力差得多。機械觸點導通瞬間的接觸電阻不穩(wěn)定內(nèi)部上拉太弱STM32內(nèi)部上拉通常在30kΩ~50kΩ信號會像一條拉不直的繩子邊沿變緩稍微有點外部干擾就誤觸發(fā)。我建議外部上拉電阻串聯(lián)在編碼器附近的PCB上而不是只依賴MCU內(nèi)部上拉。用內(nèi)部上拉做快速驗證沒問題但產(chǎn)品級設計必須加外部上拉。2.2 濾波電容的取舍A/B線對地各加一個濾波電容是抑制機械抖動和空間電磁干擾最直接的手段。電容值的選取有個容易走極端的坑太小起不到濾波作用太大把邊沿拉得太緩STM32的GPIO可能直接識別不出有效的電平跳變。我做過一組對比測試在F103開發(fā)板上分別接10nF、47nF、100nF的電容高速旋轉(zhuǎn)時觀察中斷計數(shù)10nF幾乎沒有明顯濾波效果波形上仍能看到毛刺47nF對一般轉(zhuǎn)速每秒10圈以內(nèi)表現(xiàn)最佳毛刺基本消失100nF在高速旋轉(zhuǎn)時上升沿變緩偶爾會丟脈沖所以一般建議取10nF到47nF之間如果編碼器離MCU很近、環(huán)境干擾不嚴重甚至可以不加電容靠軟件消抖來解決。轉(zhuǎn)速要求高的場景寧可用軟件消抖也不要加大電容。3. 三種讀取方案對比輪詢、外部中斷與定時器編碼器模式3.1 方案速覽讀取EC11的方式有三種工程中到底選哪種取決于主控的負載情況和旋轉(zhuǎn)速度要求。把三種方案放在一起看優(yōu)劣非常明顯。方案CPU開銷實時性代碼復雜度適用場景主循環(huán)輪詢高差低Demo驗證、低速旋鈕外部中斷低好中大多數(shù)產(chǎn)品場景定時器編碼器模式極低硬件處理極好中配置稍繁瑣高速旋轉(zhuǎn)、多組編碼器輪詢最大的問題不是“讀不出來”而是主循環(huán)里一旦有延時、刷屏、通信這類阻塞操作編碼器脈沖就會堆積丟步概率直線上升。所以只要項目稍微有點復雜度我都不推薦主循環(huán)輪詢方案。3.2 定時器編碼器模式的配置STM32的通用定時器和高級定時器幾乎都帶編碼器接口官方手冊里叫Encoder Mode本質(zhì)上是一個硬件正交解碼器。它直接同時監(jiān)測A/B兩相把脈沖數(shù)和方向解算成計數(shù)器的增減程序只需要讀計數(shù)器值就能知道轉(zhuǎn)了多少格。CubeMX里的配置非常簡單將定時器的CH1和CH2分別映射到A相和B相引腳選擇Encoder Mode根據(jù)需要的計數(shù)方向配置TI1和TI2的極性設置計數(shù)器上限比如開成16位自動重裝或者改成32位計數(shù)模式關鍵一步Slave Mode選Encoder ModeInput Capture預分頻設為不分頻使能定時器之后硬件就會自動根據(jù)A/B相順序加減計數(shù)器。正轉(zhuǎn)一圈計數(shù)增加N反轉(zhuǎn)一圈減少N這個N就是單圈脈沖數(shù)的四倍頻結(jié)果。EC11本身30個脈沖周期四倍頻后一圈120個計數(shù)步進手感細膩很多。這個方案我強烈推薦它不用寫中斷處理函數(shù)不用手動管理消抖狀態(tài)CPU占用接近零轉(zhuǎn)速上限遠高于GPIO中斷方式。唯一的門檻是CubeMX配置時要稍微理解正交解碼的含義但配置過一次之后你會覺得這才是STM32對EC11最優(yōu)雅的解法。4. 狀態(tài)機消抖與方向判定核心源碼逐段解析4.1 狀態(tài)機方向判定思路如果不用定時器編碼器模式而是用GPIO外部中斷那狀態(tài)機消抖和方向判定就必須自己實現(xiàn)。很多人第一反應是檢測A相上升沿此時讀B相電平高就是正轉(zhuǎn)低就是反轉(zhuǎn)。這個方法能工作但高速旋轉(zhuǎn)時抖動會讓邊沿重復觸發(fā)方向判定容易出錯。更可靠的做法是把A/B兩相合成一個2位狀態(tài)值每一位對應一相信號然后維護一個“上一次狀態(tài)當前狀態(tài)”的轉(zhuǎn)移表。正轉(zhuǎn)時狀態(tài)按00→01→11→10→00循環(huán)反轉(zhuǎn)時按00→10→11→01→00循環(huán)。任何不屬于這兩個循環(huán)的跳變都視為抖動直接忽略。這種狀態(tài)機天然抗抖因為它要求信號必須按合法順序切換才算有效步進。4.2 具體代碼實現(xiàn)以HAL庫為例A相接PA0B相接PA1兩個引腳都配置為外部中斷。中斷回調(diào)里調(diào)用狀態(tài)機函數(shù)#define EC11_A_PIN GPIO_PIN_0 #define EC11_B_PIN GPIO_PIN_1 #define EC11_PORT GPIOA static uint8_t ec11_last_state 0; volatile int16_t ec11_count 0; void EC11_Process(void) { uint8_t a HAL_GPIO_ReadPin(EC11_PORT, EC11_A_PIN); uint8_t b HAL_GPIO_ReadPin(EC11_PORT, EC11_B_PIN); uint8_t cur_state (a 1) | b; uint8_t trans (ec11_last_state 2) | cur_state; ec11_last_state cur_state; switch (trans) { case 0x01: // 00 - 01 case 0x07: // 01 - 11 case 0x0E: // 11 - 10 case 0x08: // 10 - 00 ec11_count; break; case 0x02: // 00 - 10 case 0x04: // 01 - 00 case 0x0B: // 10 - 11 case 0x0D: // 11 - 01 ec11_count--; break; default: break; // 抖動或非法跳變忽略 } } void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if ((GPIO_Pin EC11_A_PIN) || (GPIO_Pin EC11_B_PIN)) { EC11_Process(); } }這段代碼的關鍵在于避免在中斷里做任何耗時的操作。EC11_Process里只有讀引腳、拼狀態(tài)、查表增減計數(shù)全程沒有延時、沒有printf、沒有除法中斷里執(zhí)行時間在微秒級別完全可控。4.3 為什么不用簡單的邊沿電平判斷只檢測A相邊沿再讀B相在低速時表現(xiàn)很好但高速旋轉(zhuǎn)時問題很隱蔽邊沿處B相可能正處于抖動毛刺區(qū)讀到的高或低是不穩(wěn)定的方向就會間歇性誤判。狀態(tài)機轉(zhuǎn)移表要求完整的“四步走”序列任何一步?jīng)]走完都不計數(shù)等于把四分之一周期內(nèi)的所有抖動都吸收掉了抗干擾能力完全不在一個級別。實測一種工況手捏旋鈕快速來回搓動邊沿電平方案會出現(xiàn)次數(shù)計數(shù)原地反彈而狀態(tài)機方案計數(shù)基本保持在很小的范圍內(nèi)波動。這就是為什么產(chǎn)品里幾乎都用狀態(tài)機或者硬件編碼器模式而不是“檢測上升沿讀另一個腳”這種入門方案。5. 我踩過的高速丟步與誤觸發(fā)問題完整排查鏈路5.1 問題現(xiàn)象與復現(xiàn)條件有一次用GPIO中斷做音量旋鈕低速旋轉(zhuǎn)完全正常但快速擰的時候計數(shù)不是線性增加而是偶爾少記一格甚至方向反一下。這個現(xiàn)象用示波器看波形A/B相位關系其實是正確的問題不出在編碼器本體。復現(xiàn)條件很有意思手擰速度非?？?、中斷函數(shù)里恰好在處理別的標志位、主循環(huán)再調(diào)用一次HAL_Delay導致中斷響應被拉長。三個條件湊齊丟步就會穩(wěn)定復現(xiàn)。5.2 排查過程第一步先看中斷是否丟失。在中斷回調(diào)里加一個計數(shù)器和主循環(huán)里的另一路獨立計數(shù)對比發(fā)現(xiàn)中斷發(fā)生次數(shù)明顯少于邏輯分析儀抓到的脈沖數(shù)說明中斷本身就有丟失。第二步查中斷優(yōu)先級。默認配置下GPIO中斷優(yōu)先級可能和其他外設沖突F103這類Cortex-M3內(nèi)核如果中斷里調(diào)用了HAL_Delay這種依賴SysTick的阻塞函數(shù)SysTick優(yōu)先級低于外部中斷時就會死等等效于關閉了中斷響應。這就是很多新手中斷卡死的原因。第三步看GPIO濾波相關配置。CubeMX里GPIO可以配置施密特觸發(fā)器輸入內(nèi)部還會有模擬濾波這些默認配置一般不用動但如果之前為了省電把引腳配成了模擬模式那就完全讀不到數(shù)字電平了。5.3 最終修復修復措施分三個層次把EC11兩個引腳的中斷優(yōu)先級設為盡可能高且其中不要調(diào)用任何阻塞函數(shù)或HAL_Delay中斷回調(diào)里只做狀態(tài)機更新和計數(shù)增減所有后續(xù)處理放到主循環(huán)查詢標志位改用定時器編碼器模式從根源上消除中斷丟失問題修復后同一測試場景連續(xù)快速正反旋轉(zhuǎn)計數(shù)完全線性不再出現(xiàn)丟步和反轉(zhuǎn)。這里要特別提醒如果你的項目里已經(jīng)用了FreeRTOS這類RTOS中斷和任務之間的數(shù)據(jù)交互要注意加臨界區(qū)保護或者關中斷訪問共享變量否則高優(yōu)先級任務搶占時同樣會出現(xiàn)偶發(fā)計數(shù)錯誤。6. 進階把編碼器變成產(chǎn)品級交互組件6.1 音量調(diào)節(jié)與加速算法拿到干凈的計數(shù)后不能直接把計數(shù)值映射成音量還得加“加速”邏輯。慢速旋轉(zhuǎn)時一格一格調(diào)適合精細調(diào)節(jié)快速旋轉(zhuǎn)時一次跳多格適合從0拉到滿。這是很多產(chǎn)品音量旋鈕的手感來源。實現(xiàn)思路很簡單static uint32_t last_tick 0; static uint32_t last_count 0; uint16_t get_volume_step(void) { uint32_t now HAL_GetTick(); uint32_t dt now - last_tick; int16_t delta ec11_count - last_count; last_tick now; last_count ec11_count; if (dt 200) return delta; // 慢轉(zhuǎn)一格算一格 if (dt 50) return delta * 4; // 中等速度加速4倍 return delta * 10; // 快速加速10倍 }實際上就是把時間間隔和計數(shù)增量做一個線性映射時間越短振幅越大。這個算法實測手感很自然比固定步進的方案好用太多。要注意返回值用有符號數(shù)反轉(zhuǎn)時才能正確減小音量。6.2 菜單翻頁與按鍵復用EC11自帶按鍵和旋轉(zhuǎn)兩路輸入組合起來可以覆蓋很多交互場景。一個經(jīng)典應用是“旋轉(zhuǎn)選擇菜單按下確認長按返回”。按鍵邏輯單獨復用一組狀態(tài)機短按觸發(fā)確認事件長按超過1秒觸發(fā)返回事件松開時清零計時。這里有個容易踩坑的地方長按和短按的判定不能放在同一個中斷回調(diào)里延時判斷否則旋鈕旋轉(zhuǎn)的響應會被卡住。正確的做法是中斷里只記錄按鍵按下和松開的時間戳主循環(huán)里用非阻塞方式判斷時間差。6.3 PID參數(shù)調(diào)節(jié)與多參數(shù)設置做電機控制或者溫控項目時用EC11調(diào)PID參數(shù)是非常順手的方案。比如三個參數(shù)P、I、D分別由三頁菜單承載旋轉(zhuǎn)編碼器選中一個參數(shù)按下切換到編輯模式再旋轉(zhuǎn)調(diào)整數(shù)值。得益于定時器編碼器模式的精確計數(shù)參數(shù)調(diào)節(jié)能做到每次旋轉(zhuǎn)僅增減一個最小步進配合加速算法還能快速跨越量程。我實際測試過用EC11配合串口打印PID參數(shù)調(diào)到目標值后再寫入Flash保存整個過程不需要接電腦改代碼重新燒錄調(diào)試效率比改宏定義再編譯高出太多。如果你的項目里有多個參數(shù)要現(xiàn)場整定強烈建議把EC11做成通用參數(shù)調(diào)節(jié)組件。關于EC11還有一個容易被忽略的點它的機械壽命標稱通常在三萬次旋轉(zhuǎn)循環(huán)左右聽起來很多但產(chǎn)品設計時如果旋鈕被用戶無意識反復搓動壽命消耗比想象中快。所以結(jié)構(gòu)設計上可以考慮加阻尼或防誤觸結(jié)構(gòu)程序上也盡量用邊沿計數(shù)而不是輪詢減少無意義的中斷喚醒。寫到這里EC11從硬件到軟件到產(chǎn)品集成的完整鏈路基本都過了一遍。我個人實際項目中用得最多的組合是定時器編碼器模式加狀態(tài)機按鍵整個交互模塊只有兩個引腳加一個按鍵引腳代碼量精簡又不占用CPU后續(xù)無論接LCD菜單、藍牙調(diào)參還是USB聲卡音量旋鈕都能直接復用這套底層邏輯。如果你的項目還在用輪詢和邊沿檢測不妨花一晚上換成這套方案手感提升是立竿見影的。本文還有配套的精品資源點擊獲取