You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
@pankleks, you may face the issue that by the time you read the pin, it is a bounce... because you do not debounce. But even a solid debounce may not help you because you may run into the speed / frequency issue. There was another conversation about the encoder run with
setWatch()(and usingrepeat:trueandedge:"both"options) I elaborated on.If you do not use a mechanical contact / switch based decoder but rather an optical (bare bone) one, following comments apply only partially. If it is electronically - with lights - some kind of Schmitt trigger with appropriate hysteresis has to be applied. The frequency issue - overrun - you can detect by looking at the error flags with
https://www.espruino.com/Reference#t_l_E_getErrorFlags.Handling mechanical switches IS a challenge, because of the bounce and its even more so because of its unpredictability (heavily dependent on materials / quality / cleanliness / etc. of the switch) . For "slowly" changes in states you may get away with a simple approach. But to reliably detect you have to catch not only the good states, but also reject the bad states. I still believe that JS and in particular Espruino is fast enough to handle that. - *** Try your code with an original Espruino board... *** (or at least with an ESP-8266 where there is no - or much less of - layering of SW is involved between the actual pin and your watch callback function, HW event handling and reading the pin state. ESP-32 - though considered powerful in regard of computing power - is not that suitable for handling HW events and interfacing HW and JavaScript as @Gordon's implementation on STM32 and MDBT42).
What I would do - and did in some of my applications where buttons are involved - was to create a state machine which is aware of all the good and bad states and all possible timings and let the
setWatch()feed this state machine. The state machine then sends out valid / validated events to registered subscribers, such as an up or down counter, frequency meter, etc. (Think about a mouse that has multiple decoders... and sends only good signals to the computer).To reliably detect a motion on a rotary/linear decoder you need two events from different sensors / pins to confirm an actual movement. You cannot derive from an on or off of a single sensor / pin wether it is a clockwise / counter-clockwise / forward / backward movement: it could just be a jitter.
With mechanical sensors (switches) you have to have the guarantee that when the second one shows on event, the first one has to have stabilized / debounced. Only then you can be sure about the state of the first one. In basic hardware implementation you use a pairs of interlocking negative and positive pulse triggered RS-flip-flops. Luckily, this you can emulate / simulate w/ software... and that is what I meant with building a state machine.
(Btw, fat-arrow functions have limitations - see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions - but as I see nothing in your code that would hint that these contribute to the flaky results you experience.)
...for some info about encoders see https://www.researchgate.net/publication/305649159_Re-gripping_analysis_based_on_implementation_of_slip-detection_device_for_robotic_hand_model - from where the attached pic is from - and https://www.analogictips.com/rotary-encoders-part-1-optical-encoders/ (interestingly - only optical and magnetic encoders are mentioned...)
1 Attachment