一定位一脈沖的EC11旋轉(zhuǎn)編碼器最簡潔的單片機驅(qū)動代碼

ID:433219 · 發(fā)表于 2023-9-22 19:34

一般方法：先判斷跳變（同時觸發(fā)抖動計時連續(xù)判斷），再判斷另一個io的高低，

ID:965189 · 發(fā)表于 2023-9-22 23:34

我用一個外中斷，使用正常。

ID:427868 · 發(fā)表于 2023-9-25 15:48

以下是我之前采用拿來主義得到的，只對判斷后執(zhí)行部分稍作修改，應(yīng)用還不錯。
/************************參數(shù)設(shè)置***************************/
void canshu() //EC11旋轉(zhuǎn)編碼器一定位一脈沖
{
static bit LastA = 0; //EC11旋轉(zhuǎn)編碼器的A引腳上一次的狀態(tài)
static bit LastB = 0; //EC11旋轉(zhuǎn)編碼器的B引腳上一次的狀態(tài)

  if(KA != LastA) //判斷EC11旋轉(zhuǎn)編碼器A引腳是否等于上一次的狀態(tài)
  {
if(KA == 0) //EC11旋轉(zhuǎn)編碼器旋轉(zhuǎn)后，判斷KA是否是低電平狀態(tài)
   {
if(KB) //判斷KB引腳當前狀態(tài),高電平則為正轉(zhuǎn)
{num++;}
else
{num--;}
   }
   LastA = KA; //更新編碼器上一個狀態(tài)暫存變量
   LastB = KB; //更新編碼器上一個狀態(tài)暫存變量
}
}

現(xiàn)在看來LsaB變量似乎沒有用，有空了去掉它試試。對于正反向不同的EC11，我是通過調(diào)換num變量的加減方向來解決的。

ID:378108 · 發(fā)表于 2023-9-28 09:49

haokey 發(fā)表于 2021-7-7 12:20
探討一下，假如我改成這樣會怎樣：
if(!PinA&&PinB)
{PinA_O= 1;}

你這樣是不行的,會重復(fù)的加或減

ID:378108 · 發(fā)表于 2023-9-28 09:57

  unsigned char key=0;
  static bit nextA;
  if (KA()!=nextA)
{nextA=KA();
   if (nextA==1)
      {if (KB()==1) key=6;else key=5;}
   else
      {if (KB()==0) key=6;else key=5;}
}
return key;

ID:1053178 · 發(fā)表于 2023-11-25 19:55

劉佑紅發(fā)表于 2023-9-25 15:48
以下是我之前采用拿來主義得到的，只對判斷后執(zhí)行部分稍作修改，應(yīng)用還不錯。
/************************ ...

我跟你用的一樣，但是發(fā)現(xiàn)轉(zhuǎn)快了丟碼，慢很好

ID:103411 · 發(fā)表于 2023-11-29 14:12

下載學(xué)習(xí)一下，正準備用這個一定位一脈沖編碼器。

ID:427868 · 發(fā)表于 2023-11-29 15:01

diyage 發(fā)表于 2023-11-25 19:55
我跟你用的一樣，但是發(fā)現(xiàn)轉(zhuǎn)快了丟碼，慢很好

你說的這種情況，確實存在，也不能旋轉(zhuǎn)過快，且在部分EC11上表現(xiàn)明顯，即存在挑EC11現(xiàn)象，，后來我嘗試將KB對地接的104電容換成105的就改善了，也不挑EC11了，你可試試。

ID:688905 · 發(fā)表于 2023-11-29 16:40

很好的優(yōu)化方法，學(xué)習(xí)了！

ID:471574 · 發(fā)表于 2023-12-14 17:37

樓主的代碼很不錯，我這邊有另一種算法，也很精簡EC11編碼器基于運算解碼的算法(原創(chuàng))，匯編后大小也基本一樣，有一個算法甚至更小

ID:774081 · 發(fā)表于 2024-1-19 14:17

完美的代碼效果應(yīng)該是轉(zhuǎn)動一下只計數(shù)一下，不能多增也不能不增，最重要的是！不論轉(zhuǎn)得多快還是多慢，都如此，那才是好代碼！從這個標準來說，我試驗了上10款作者自詡為非常不錯的代碼，均不合格！當然我自己也編不出合格的代碼來，一度懷疑是我買的EC11編碼器在硬件方面不合格，因為只有上拉電阻。沒有消抖電容。但符合這樣標準的編碼器效果是普遍存在的，比如十幾、二十年前的進口功放機，就采用了旋轉(zhuǎn)編碼器調(diào)整音量，那編碼器的使用效果才是我追求的，現(xiàn)在我的一個項目卡在編碼器上，怎么都不好用，肯定采用中斷來實現(xiàn)，還沒找到合適的代碼，下一步寄加消抖電容看看誰的代碼最理想，再來匯報。

ID:1101997 · 發(fā)表于 2024-1-19 14:51

這東西還是需要用狀態(tài)機來寫，只要描述好正常狀態(tài)遷移的關(guān)系，異常狀態(tài)處理，硬件上消抖不消抖都是可以處理好的。

ID:430492 · 發(fā)表于 2024-1-19 14:56

要想多快都不丟步（相對哈，快到中斷處理都來不及不算哈），必須在中斷里來處理。這種中斷+輪詢判斷的方式，依然會丟步的。

ID:774081 · 發(fā)表于 2024-1-26 16:36

之前測試很多代碼，效果均不理想，表現(xiàn)為正轉(zhuǎn)、反轉(zhuǎn)有誤判，從而導(dǎo)致計數(shù)不對。我想到的辦法是得到方向數(shù)據(jù)后（比如正轉(zhuǎn)定義為1，反轉(zhuǎn)定義為0），先修正方向，再結(jié)合中斷和方向二者，決定是否累加或累減計數(shù)值。方案是建立一個數(shù)組，包括10個元素，用來存儲獲得的方向，任何時刻記錄的是最近十次獲得的方向數(shù)據(jù)，對數(shù)組的10個元素進行累加，和超過5時，強制為正方向，反之為負方向。實測效果有所改善，計數(shù)值絕不會忽大忽小、重復(fù)出現(xiàn)等情況了。遺憾的是如果你反復(fù)正轉(zhuǎn)、反轉(zhuǎn)1下，那計數(shù)還是會有問題，即不會保持不變。但這種使用場景很少見吧？真要微調(diào)，你多轉(zhuǎn)幾下，再反過來多轉(zhuǎn)幾下就行。有人會說，實際卡頓感與計數(shù)反映會不同步吧？理論上講是這樣，但單片機速度很快，實際感覺不到不同步。

ID:119977 · 發(fā)表于 2024-7-2 17:06

個人做法是a下降沿中斷中斷后判斷b高低確定正反轉(zhuǎn)

ID:774081 · 發(fā)表于 2024-9-20 15:54

hewayking 發(fā)表于 2024-7-2 17:06
個人做法是a下降沿中斷中斷后判斷b高低確定正反轉(zhuǎn)

試了，很棒！史上最簡潔的代碼。

ID:471574 · 發(fā)表于 2024-9-27 08:22

http://www.torrancerestoration.com/bbs/dpj-233399-1.html
這個也是很簡潔，又新穎的EC11驅(qū)動

ID:1143011 · 發(fā)表于 2025-1-16 12:31

bhjyqjs 發(fā)表于 2022-2-7 10:49
樓主代碼及其精簡，不錯！
實際上，只檢測A引腳的下降沿，由B引腳狀態(tài)決定加減更高效。
經(jīng)實驗，無漏脈沖 ...

高手啊!

ID:983641 · 發(fā)表于 2025-2-15 15:21

相當簡潔的代碼。需要時間消化。

帳號		自動登錄	找回密碼
密碼			立即注冊