Behavior of the "Encoder" module is unexpected - two call per notch #820
Replies: 4 comments
-
Posted at 2015-11-02 by @gfwilliams Hmm, it's difficult. When I did it, I'd assumed that my particular encoder was non-standard in that it effectively jumped two positions for each 'click', but I haven't yet seen an encoder that doesn't do that :) Of course my problem is that the module is now in use by people, who presumably have worked around that behaviour. I think it's probably correct to change it though - and hopefully users can just remove the Your code looks great! I just tried it on an encoder here, and it still calls the callback twice for each 'click'. Is that the same for you? The old one called it 4 times though! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-11-02 by luwar After you mentioned an encoder with four callback per click I looked for different types of encoders: The topic is more complicated than I thought.
Espruino is such a great platform so we should supported each type out of the box with simple parameterization and not choose one in favor of the others. The principle of a rotary encoder is the same only the state machine differs. I have created a small pull request to initialize the current module correctly. Next I will play a little bit with different rotary encoders. I will try to merge the current module code with the attached version and generalize the module. The current module behavior (+/-2) could then be the default one. Existing clients will not be broken. And the documentation should point to the parameterization possibilities. What do you think? Should I try this? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-11-03 by @gfwilliams Thanks for the PR! This is the first one I found when I just googled for I think it's like the one I have. It'd be great if you could look at it - your code was much tidier! Perhaps (to be backwards compatible) we could have:
Of course there might be a better name for it, but allowing the function to be changed to an object with extra parameters would be really good. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-11-04 by @allObjects The fixed issue was that |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-11-01 by luwar
Hello,
I tried to use the Encoder module with a rotary encoder (http://www.amazon.com/dp/B00HSX9ZB2).
step will be incremented/decremented by 2 on every notch. This is not expected when looking at the api but understandable when looking at the implementation. The state machine 00 → 01 → 11 → 11 → .. calls onChange() also in the instable states 01 and 10.
This is academically correct for general gray codes. But I think that is not the intended behavior for supporting an incremental rotary encoder because client code will now have to skip every second callback. What is your opinion? Who is using this module? How do you deal with these circumstances? Do you use the "Encoder" module for something other than rotary encoders?
I made an adaption with a more "rotary encoder" behavior - it's attached. If desired I could make a pull request with some additional debounce logic. Debouncing is now possible because of the internal "forbidden" states.
BTW there is a small bug in the initialization code of the original module. The first step will not be detected correctly. I fix it if the attached new code should not be used.
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions