[sdiy] Need goog working rotary encoder in C code..
tom at electricdruid.net
Fri Aug 6 21:21:50 CEST 2021
+1 agree with these points.
Use polling, and make sure you can easily adjust the rate you check the inputs in case you need to slow it down. I used a loop of 2msecs, I think, and the software debounce required 4 stable reads to consider an input changed (so 8msecs in the same state). These numbers depend on the type of encoder used, and you should probably go as *slow* as you dare. Going faster is tempting as it “makes it more responsive” but at some point the bouncing will get worse, and then your code will no longer cope. Either test with half-dead, heavily-worn encoders, or work to a worse-case scenario!
The code should detect each input change, which is to say, on the encoders I used there are four changes between each detent. Keeping track of the changes allows both direction detection and some degree of error correction.
Interrupt based code is just going to throw a lot of unnecessary interrupts every time the input bounces, unless it’s all debounced in the hardware…in which case, what’s the software for?!?
My favourite debounce routine is a vertical counter debounce since it can do eight inputs in a single pass (or 16 on a word-based processor).
> On 6 Aug 2021, at 19:05, John Speth via Synth-diy <synth-diy at synth-diy.org> wrote:
> I have substantial experience with the application but not in a musical context. My extensive trials and errors has convinced me of the following:
> 1. You'll need to know when inputs change state, not just when the signals go low. Consider rising and falling edge interrupts on both inputs. You can detect rotation direction using this strategy.
> 2. There WILL be bouncing so plan for it. Contact type switches will bounce more than optical switches. Contact type switches will degrade over time.
> 3. Interrupts vs polling: Interrupts are great but they have a hidden hazard in that they can flood and overwhelm some MCUs (YMMV of course). A capacitor can help alleviate the problem but it's better to find a non-cap solution. I've found polling is better. I use a digital integration method (*) and a fast polling interval. That works so well, I automatically go to that design solution for most applications.
> * --- A digital integration method uses a counter that counts up and down and outputs a state change signal when a count threshold is reached. Increment the counter while the input is high and decrement the counter when the input is low. Reset the count when the output state changes. Adjust the polling interval for speed and accuracy. As a frame of reference, I use a 5 msec polling interval for keyboard debouncing. You'll probably want a faster interval if your encoder can be turned fast. I'll warn you that there can be a surprisingly large number of lines of code for such a simple task like digital debouncing.
> On 8/6/2021 8:46 AM, Jean-Pierre Desrochers wrote:
>> Hi everybody.
>> I’m doing some tests on a rotary encoder and a PIC16F1783.
>> A standard Bourns encoder like THIS <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjyoqDF3JzyAhUmhOAKHf3lAzoQFnoECAoQAw&url=https%3A%2F%2Fwww.bourns.com%2FPDFs%2Fpec11l.pdf&usg=AOvVaw2RyieyzPnujiOTS7LBcbpw> .
>> Connected using 2 x 10k pullups with 0.01uf caps to ground
>> to PORTB of the micro. Interrupt calls (falling edges) used on encoder pins A & B.
>> I struggled so far to get clean increments/decrements out of it.
>> Many missing counts occur..
>> I tried many source codes on the web with no luck..
>> Is there anybody who’d have worked on this in the past
>> and have a working c code ?
>> No ARDIUNO please.
>> Thanks !
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> Selling or trading? Use marketplace at synth-diy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Synth-diy