再玩EC11编码器的解码思路

pla155

再玩EC11编码器的解码思路

之前的一篇小作文 ， 《我玩EC11编码器的解码思路》

https://www.mydigit.cn/thread-521793-1-1.html  

因为描述不清，可能误导了部分热心网友，

特别在详细的写一篇，争取能把事情说清楚。

市面上 EC11 大多是金属的机械触点，不是光栅结构。

不过，原理相同，所以也就不再特别的区分说明了。

lmn2005

太有耐心了！

jpdd521

我提一个思路，不知道是不够可行，如果是用PCB打印一个线圈，通过异步感应的方式与外部线圈耦合产生正反向电场来实现同样的“编码”作用，只需要外部信号解码就可以，这样就解决了编码器物理磨损问题，又可以增加或者是降低编码器阻尼，我说的这样好像是跟FOC类似了。

pla155

jpdd521 发表于 2025-5-18 20:03
我提一个思路，不知道是不够可行，如果是用PCB打印一个线圈，通过异步感应的方式与外部线圈耦合产生正反向 ...

这个想法一定会有应用场景的。

数显的游标卡尺测量原理也用用电容或光栅的方案。
他的电容方案可能和你的电场的方案异曲同工。

磁场方案目前难度比较大，主要是磁感应传感器成本高。
当然，也可以考虑相位编码，成本问题而已。

liaoxiao123

逆天，能不能改成按键操作

nvy

很用心了。。。

pla155

liaoxiao123 发表于 2025-5-21 10:58
逆天，能不能改成按键操作

能，一定能

amsl

16字节的查表法?16~64字节的缓存计算方向?
太复杂了!
也是看了楼主的帖子才同期发布了旋转编码器的检测代码,
可以移步帖子<<ECC11_12编码器检测程序>>
这个程序最早只在矿坛发布过,这里发布的是它的变种,更符合于需要事件驱动的场合,检测的核心思想没变,
解算旋转编码器仅需1个字节,就是那个变量ec->status和AB相信号的实时状态,
编程是个简单的活,别想太复杂.

ahyu99

看完了，又没有看懂。

pla155

amsl 发表于 2025-5-24 10:52
16字节的查表法?16~64字节的缓存计算方向?
太复杂了!
也是看了楼主的帖子才同期发布了旋转编码器的检测代码 ...

你的帖子拜读了，
代码写的很规范，
判断逻辑也写的很严谨。

不过，
我的方法也不差。

咱俩的出发点不同；
我的目的是占用最少的资源和时间；

16字节查表占用的是代码空间；
如果只解算方向，
RAM可以仅用4个bit，不到一个字节。
定时器中断资源是可以共享的，
因为是“数学运算代替逻辑判断”，
需要的代码很短，时间也很少。


另外，
16-64字节是用来存储方向标志的，
并不是计算方向，
它的功能是用来解算旋转速度的。
具体占用多少RAM取决于实际需要检测的最快速度和最慢速度，
一般来说，转速越快占用越少。

其实，
通常的算法是中断程序里判断另一管脚电平，
这个方法已经是最优解了；
缺点仍有4个状态的需要判断；
特别的是不能简单的的解算速度而已。

pla155

ahyu99 发表于 2025-5-24 11:04
看完了，又没有看懂。

因为这个思路是逆向的，
而且的确反人类；

但是，
正如我一直很耐心的说，
知其然还要知其所以然；

当你很耐心的把它再看几遍，
你会发现，这也是正向思维。

应为有了这个旋转编码器，
程序员的需求就是“我应该怎么解码呢”，
这是正向思维。

穿越到还没有这个玩意儿的时代，
工程师的需求是“我应该怎么把一个旋转动作变成一个可以测量的电平的时间函数呢”，
这也是正向思维。

但因“供给”和“需求”视角的不同，
造成了正向和逆向思维的不同。

你试试，
把这个文章当故事看，
就当看个热闹，
把“这程序该怎么写”的想法扔掉，
应该会很有意思。

pla155

已经做了硬件，写了代码，做了验证；
事实上是可行的。
开元地址 ： https://oshwhub.com/pla155/decode-ec11-by-simple-table