Having many rotary encoders.

[ejeffrey]

Yes, that's the best way for user-operated knobs. They are very slow.

Tell that to the nearly every designer of rotary encoder UIs that poll too slowly. There is very little that bothers me more than using a $200,000 VNA or a $50,000 car and spinning the menu knob only to have the cursor move backwards.  That isn't really acceptable on $5 IoT crap, but it's pervasive on devices in every class.

That's not to say that you can't do it with polling, only that polling too slow is pervasive, and most advice on the topic does not address this.

[Peabody]

I guess I am using a 24 position encoder with detent, so precision is already about as high as usable for human interaction. I probably misspoke about the information to be had from the bouncy pin- with what I am doing, the bouncy pin still cannot be read reliably, but one can deduce its state by knowing its last state (which was a stable read). So the bouncy pin state can be deduced by simply inverting its stored last state value in its isr (we are in its isr because the pin changed).

Indeed.  Just for future reference, below is an Arduino sketch that keeps track of the pins' states, so it doesn't need to trust a read of the interrupting pin when it might be bouncing.  And once a pin interrupts, further interrupts on that pin are disabled, but enabled on the other pin, which should be stable, so bouncing should not trigger interrupts.  The code uses the state machine, or lookup table, method, where an index is created made up of the current and previous pin states and the interrupting pin, and the index selects one of 32 possible table values to add to the count.  Then at a detent, if the count is +4 or -4, a tick is generated.  When I run this code, it seems very smooth, properly detects changes of direction, and most of the time there are only 4 interrupts between detents.  The code is for the Atmega328P, which could have three such encoders (one each on ports B, C and D), plus another on the hardware interrupt pins D2 and D3.

I just wanted to make the point that using interrupts for rotary encoders is definitely not a recipe for disaster, and they can produce by far the lowest servicing overhead in case the processor has other things to do.  But you do need to prevent bounces from triggering interrupts if you can.

Code: [Select]


const int aPIN = 4;                     // encoder pins
const int bPIN = 5;

/*  This section defines the port being used for the encoder pins, along with the PCI registers
    and interrupt vector.  The values shown here are for Port D (D0 - D7), but Port B (D8 - D13)
    or Port C(A0 - A5) could also be used.
*/

#define pinZero 0                       // data pin name of PD0 (0). PB0 (8) PC0 (A0) for ports B and C
#define PORT PIND                       // port input register (port D includes D4 and D5)
#define portVECT PCINT2_vect            // The ISR vector for port D pin change interrupt
#define portINT PCIE2                   // used to enable pin change interrupts on port D as a whole
#define ENABLE PCMSK2                   // individual pin interrupt enabled = 1
#define FLAG PCIF2                      // only one flag for whole port

const byte encoderType = 0;             // encoder with equal # of detents & pulses per rev
//const byte encoderType = 1;             // encoder with  pulses = detents/2. pick one, commment out the other

const int THRESH =(4-(2*encoderType));  // transitions needed to recognize a tick - type 0 = 4, type 1 = 2

const byte CWPIN = bit(aPIN - pinZero); // bit value for switch that leads on CW rotation
const byte CCWPIN = bit(bPIN - pinZero);// bit value for switch that leads on CCW rotation
const byte PINS = CWPIN + CCWPIN;       // sum of bit values of the encoder pins
const byte ZEERO = 0x80;                // "byte" data type doesn't do negative, so make 128 = zero

byte EDGE;                              // the edge direction of the next pin change interrupt
byte CURRENT;                           // the current state of the switches
byte TOTAL = ZEERO;                     // accumulated transitions since last tick (0x80 = none)
byte INDEX = 0;                         // Index into lookup state table
int Setting = 0;                        // current accumulated value set by rotary encoder

volatile byte tickArray[256];           // circular buffer of ticks
volatile byte beginTICK = 0;            // pointers to beginning and ending of circular buffer
volatile byte endTICK = 0;

// The table is now 32 bytes long so as to include the identity of the pin currently interrupting.
// The +2 and -2 entries are for a change of direction.

int ENCTABLE[]  = {0,1,0,-2,-1,0,2,0,0,2,0,-1,-2,0,1,0,0,0,-1,2,0,0,-2,1,1,-2,0,0,2,-1,0,0};

void setup() {

  Serial.begin(115200);
  pinMode(aPIN, INPUT);                 // set up encoder pins as INPUT.  Assumes external 10K pullups
  pinMode(bPIN, INPUT);

  EDGE = PINS;                          // identifies next pin-change interrupt as falling or rising
                                        //    assume current state is low, so any change will be rising
  if(PORT & PINS) {                     // but if actual current state is already high,
    EDGE = 0;                           //    make EDGE low
    INDEX = 3;                          //    and make "current" bits of INDEX match the current high state
  }

  ENABLE |= CWPIN;                      // enable only CWPIN interrupt in mask register
  PCIFR |= bit(FLAG);                   // clear interrupt flag if any
  PCICR |= bit(portINT);                // enable interrupts on Port D
}

void loop() {

  if(beginTICK != endTICK) {            // if anything in circular buffer

    beginTICK++;
    if(tickArray[beginTICK] == 1) Setting ++;
    else Setting--;

    Serial.println(Setting);
  }
}

ISR (portVECT) {                        // pin change interrupt service routine. interrupts
                                        //     automatically disabled during execution

  CURRENT = PORT & PINS;                // read the entire port, mask out all but our pins

/* Time passes between the interrupt and the reading of the port.  So if there is bouncing,
the read value of the interrupting pin may be wrong.  But we know it must be the EDGE state.
So in CURRENT, we clear the bit that just caused the interrupt, and replace it with the EDGE
value. The non-interrupting pin is assumed to be stable, with a valid read. */

  CURRENT &= ~ENABLE;                   // clear the bit that just caused the interrupt
  CURRENT |= (EDGE & ENABLE);           // OR the EDGE value back in

  INDEX     = INDEX << 2;               // Shift previous state left 2 bits (0 in)
  if(CURRENT & CWPIN) bitSet(INDEX,0);  // If CW is high, set INDEX bit 0
  if(CURRENT & CCWPIN) bitSet(INDEX,1); // If CCW is high, set INDEX bit 1
  INDEX &= 15;                          // Mask out all but prev and current.  bit 4 now zero
  if(ENABLE & CCWPIN) bitSet(INDEX,4);  // if CCWPIN is the current enabled interrupt, set bit 4

// INDEX is now a five-bit index into the 32-byte ENCTABLE state table.

  TOTAL += ENCTABLE[INDEX];             // Accumulate transitions

  if((CURRENT == PINS) || ((CURRENT == 0) && encoderType)) {  // A valid tick can occur only at a detent

// If we have a valid number of TOTAL transitions at a detent, add the tick direction
//   to the circular buffer.  The MAIN loop will update the Setting value and print it.

    if(TOTAL == (ZEERO + THRESH)) {
      endTICK++;
      tickArray[endTICK] = 1;
    }

    else if(TOTAL == (ZEERO - THRESH)) {
      endTICK++;
      tickArray[endTICK] = 0xFF;
    }

    TOTAL = ZEERO;                      // Always reset TOTAL to 0x80 at detent
  }

  if(CURRENT == EDGE) EDGE ^= PINS;     // if both pins have reached EDGE state, switch EDGE to opposite
  ENABLE ^= PINS;                       // always switch interrupt to other pin
  PCIFR |= bit(FLAG);                   // clear flag if any by writing a 1
}                                       // end of ISR - interrupts automatically re-enabled


[PCB.Wiz]

SPI bus chaining, I have seen it in some advanced SPI use cases with the MOSI leaves the master to the first slave, which at the same time, in it's slot sends the last buffer out it's while receiving the current on the MISO.  Each in turn along the line do this.  I can see this means you only need 1 SS line.  It also adds latency. 

It's a shame MCUs mostly ignore the simplicity of SPI chaining.

Tangent question, but what is the next logical step up from SPI?  I know there are parallel GPIO connection approaching, but is/are there many established/standard protocols for linking multiple devices more tightly that SPI?
What other options lie between SPI and PCI/ISA or custom full bus?

For this application you do not need faster than SPI, and the option best supported is i2c, which easily runs to 400kHz/1MHz

Since the RGB encoder was mentioned, it would be nice to support Encoder read and LED out.
A small MCU is one solution, if you need a handful the examples linked above save time.

- but there are shiploads of i2c GPIO parts, that are very low cost, and LED capability has been added to many. If you are happy with 5 CMOS pins driving 3 leds the cheapest digital IO ones will do.

Parts like TLC59108 add more LED-Drive smarts with linear current control and a error/open readback that can be used for buttons.
It has 14-devices Address map, which is better than the 8-devices vanilla parts, but not as good as some newer multi-state pins that support 64 or 126 devices.

Adafruit has a AW9523 LED/GPIO module, lcsc has the parts for 31c/100
That has only 4-device Address map, but has 16 io.
There is also a related AW21009  25c/100 with 8io, also 4-device and open/short led detect.

Or, because 8 channels may not mean highest volume, (lowest price points)  we can relax channels/LEDs and search more
The lumisil IS31FL3205, lcsc has for 60c/100 and that has 12 channels, open/short detect and 4-device
The IS31FL3193 is 45c/100, in QFN32 and many more channels than needed for UI drive/sense. (12x9 matrix)

[Berni]

Yes, that's the best way for user-operated knobs. They are very slow.

Tell that to the nearly every designer of rotary encoder UIs that poll too slowly. There is very little that bothers me more than using a $200,000 VNA or a $50,000 car and spinning the menu knob only to have the cursor move backwards.  That isn't really acceptable on $5 IoT crap, but it's pervasive on devices in every class.

That's not to say that you can't do it with polling, only that polling too slow is pervasive, and most advice on the topic does not address this.

Indeed, few things ruin the user experience of an expensive product as much as slow/glitchy controls.

I been mostly using GPIO interrupts to update a encoder state machine and it always worked great and does not need any special hardware, so you can have as many rotary encoders as you have pins to connect them to. Not really worth bothering reading them in a matrix when MCUs in modern SMD packages commonly come with 48 to 144 pins. I like to give the implementation a thorough testing. Marking 0 on the knob with a dot then going apeshit on the encoder, randomly turning it and flicking it as fast as i can..etc then turning it back to the marked 0 and checking the count is 0. Both with or without de-bouncing caps.

Some even take it to extremes. Like for example the Agilent MSO9000 series of scopes actually have a little Xilinx FPGA inside the front panel that is handling encoders,button matrix LEDs..etc This is overkill and the more mainstream MSOX3000 series probably have have a more cost optimal solution (Tho i haven't checked) that still had to perform as well as the older scopes. But they do have a VERY good implementation of encoders on there scopes. They are responsive, never miss steps and have really good velocity control. The velocity control is so good that they just let you adjust parameters with 4 digits without giving you an option to choose what digit you change(like most do). You can just flick the knob fast enough to change the 4th digit, or just turn it fast to change 2nd digit or slowly to do 1st digit (Tho this works well on a scope, you likely wouldn't want that on a lab PSU)

[NorthGuy]

Yes, that's the best way for user-operated knobs. They are very slow.

Tell that to the nearly every designer of rotary encoder UIs that poll too slowly. There is very little that bothers me more than using a $200,000 VNA or a $50,000 car and spinning the menu knob only to have the cursor move backwards.  That isn't really acceptable on $5 IoT crap, but it's pervasive on devices in every class.

This is not because rotary encoders in the knobs are overly fast. Those people have RTOS, gazillion of interrupts which they often disable with and without need, use high levels of abstraction, "don't reinvent the wheel", "fast way to market", and all that. They have no idea what their timing is. That's why you see skipped points.

36 points per revolution rotated by hand? If you think this is fast, I don't know what is slow. Even PIC16 can handle several of these and never skip a point, and this will consume only a fraction of the CPU time.

Compare this to a 1000-point encoder on a shaft of a motor rotating at 1500 rpm. See the difference?

[PCB.Wiz]

Indeed.  Just for future reference, below is an Arduino sketch that keeps track of the pins' states, so it doesn't need to trust a read of the interrupting pin when it might be bouncing.  And once a pin interrupts, further interrupts on that pin are disabled, but enabled on the other pin, which should be stable, so bouncing should not trigger interrupts.

The problem with that assumed quadrature flow, is it will not ignore 'wiper noise' bounce properly.
Also, systems that assume a state engine will be always ok (ie bounce cancels), also presumes the state engine nodes not miss any edges.

The best design approach seems to be a combination of HW and SW, where the hardware filters the pins so there is a firm lower limit to the edge to edge time (RC filter and schmitt does that ) and the SW is guaranteed to always follow up to that speed.

[langwadt]

Yes, that's the best way for user-operated knobs. They are very slow.

Tell that to the nearly every designer of rotary encoder UIs that poll too slowly. There is very little that bothers me more than using a $200,000 VNA or a $50,000 car and spinning the menu knob only to have the cursor move backwards.  That isn't really acceptable on $5 IoT crap, but it's pervasive on devices in every class.

This is not because rotary encoders in the knobs are overly fast. Those people have RTOS, gazillion of interrupts which they often disable with and without need, use high levels of abstraction, "don't reinvent the wheel", "fast way to market", and all that. They have no idea what their timing is. That's why you see skipped points.

or they googled "how to use rotary encoder" and picked the first hit, use one channel as clock the other as direction

[cv007]

Marking 0 on the knob with a dot then going apeshit on the encoder, randomly turning it and flicking it as fast as i can..etc then turning it back to the marked 0 and checking the count is 0

That is what I do when testing any encoder code/method as you at least will know if you have any missed steps. Some proposed encoder methods are quite bad when you do this (a lot of missed steps), but I suspect the programmer was happy with it only because they were happy with the human feedback loop (turn, see response, turn some more, see response, etc.) and never realize how many steps they are missing. If I can do this and get back to the original position with the same count then I am happy (I'll also settle for +/-1 when doing it fast and furious).

For the stm32, I added the lptim1 hardware encoder along with my software encoder with the single encoder driving both- they both match up in absolute position as done above. I initially had driven the lptim encoder with the hsi16 and that did not work at all as there were way too many steps (I had clock filter set to max), but when I switched to the LSI clock then it worked ok. I guess there are too many samples taken when using the high speed clock and my encoder has no hardware filtering.

[SiliconWizard]

You really start realizing you're doing it wrong when using encoders with detent. Those without detent are a lot more forgiving as users don't have the same expectations with these.

[nctnico]

You really start realizing you're doing it wrong when using encoders with detent. Those without detent are a lot more forgiving as users don't have the same expectations with these.

Using an encoder with a detent isn't bad perse but expecting not to miss a step is. IMHO any decent encoder implementation has proportional speed. So the faster you turn it, the bigger the steps it takes. This means that the user never has to turn it really fast to begin with and thus the software doesn't need to support crazy high speeds.

[NorthGuy]

For testing the software, you can generate the pulse sequence automatically and feed it to your MCU without using actual encoders, then send the discovered positions back through UART. This way you can run the test which includes lots of test situations in a matter of seconds.

[8goran8]

The best design approach seems to be a combination of HW and SW, where the hardware filters the pins so there is a firm lower limit to the edge to edge time (RC filter and schmitt does that ) and the SW is guaranteed to always follow up to that speed.

I agree. For this reason, I suggested the use of Microchip microcontrollers with integrated Configurable Logic Cells. See how it looks on an example:

https://github.com/microchip-pic-avr-examples/pic18f16q40-quadrature-decoder/blob/master/README.md

[ejeffrey]

Yes, that's the best way for user-operated knobs. They are very slow.

Tell that to the nearly every designer of rotary encoder UIs that poll too slowly. There is very little that bothers me more than using a $200,000 VNA or a $50,000 car and spinning the menu knob only to have the cursor move backwards.  That isn't really acceptable on $5 IoT crap, but it's pervasive on devices in every class.

This is not because rotary encoders in the knobs are overly fast. Those people have RTOS, gazillion of interrupts which they often disable with and without need, use high levels of abstraction, "don't reinvent the wheel", "fast way to market", and all that. They have no idea what their timing is. That's why you see skipped points.

36 points per revolution rotated by hand? If you think this is fast, I don't know what is slow. Even PIC16 can handle several of these and never skip a point, and this will consume only a fraction of the CPU time.

Compare this to a 1000-point encoder on a shaft of a motor rotating at 1500 rpm. See the difference?

Yet in practice, nobody ships products where the shaft encoder misses steps, but everybody ships rotary knob encoders that miss steps.  All the stuff about interrupts, abstraction layers, RTOS, etc may be some of the mechanisms, but the underlying cause is that people that the mechanical encoder is slow and they don't bother to check *how* slow.  Or they lazily use a single polling interval for the entire UI set by the time needed to debounce push buttons, but an encoder may need 10x or more the sample rate as push buttons.  The shaft encoder is recognized as "fast" so people do it correctly.

[cv007]

For this reason, I suggested the use of Microchip microcontrollers with integrated Configurable Logic Cells. See how it looks on an example

You only need to give up 2 CLC's and 3 timers-

The only requirements to implement the quadrature decoder (with no physical outputs or indicators) are 2 CLCs, TMR1, TMR2, and TMR3.

Any timers left to anything else?

You really start realizing you're doing it wrong when using encoders with detent.

Maybe talk to the oscope users that have an option selector encoder that has no detents, so when they push the encoder switch to select they end up moving the encoder to another selection in the process.

I see nothing wrong with detents as they can be made to work well, so not hard to meet the expectations of one click == one step.

[ejeffrey]

You really start realizing you're doing it wrong when using encoders with detent. Those without detent are a lot more forgiving as users don't have the same expectations with these.

Using an encoder with a detent isn't bad perse but expecting not to miss a step is. IMHO any decent encoder implementation has proportional speed. So the faster you turn it, the bigger the steps it takes. This means that the user never has to turn it really fast to begin with and thus the software doesn't need to support crazy high speeds.

This is exactly what I am ranting about.  Tweaking acceleration parameters on an encoder that can't be relied on to count properly is dumb.

If I can turn the encoder knob by hand fast enough that it looses pulses, your product is defective.  End of story.  Only once you have that dead reliable, go nuts with the acceleration controls.

[8goran8]

For this reason, I suggested the use of Microchip microcontrollers with integrated Configurable Logic Cells. See how it looks on an example

You only need to give up 2 CLC's and 3 timers-

The only requirements to implement the quadrature decoder (with no physical outputs or indicators) are 2 CLCs, TMR1, TMR2, and TMR3.

Any timers left to anything else?

It's just an example of using CLC and the same task can be done with fewer resources. Yes, there is still a lot of hardware available on that series of microcontrollers, and the choice should be tailored to the specific application. The point is that the CLC hardware is available on chip and will relieve the software side of the project. If It Don't Fit, Use a Bigger Hammer

[nctnico]

You really start realizing you're doing it wrong when using encoders with detent. Those without detent are a lot more forgiving as users don't have the same expectations with these.

Using an encoder with a detent isn't bad perse but expecting not to miss a step is. IMHO any decent encoder implementation has proportional speed. So the faster you turn it, the bigger the steps it takes. This means that the user never has to turn it really fast to begin with and thus the software doesn't need to support crazy high speeds.

This is exactly what I am ranting about.  Tweaking acceleration parameters on an encoder that can't be relied on to count properly is dumb.

If I can turn the encoder knob by hand fast enough that it looses pulses, your product is defective.

No, then you are using it wrong. I have actually implemented rotary encoders in several products this way and they work great. There is no need to look for strawman arguments here. If you hit your hand with a hammer, it will hurt. It doesn't mean the hammer is defective; just don't hit your hand with a hammer and all is well.

[ejeffrey]

OK, but if I swing the hammer down at a nail, and the hammer software decides to interpret that as "go the other way bash the user in the face', the hammer is wrong.

If I turn a knob right and the cursor moves left, the device is wrong not me.  I honestly can't believe anyone would even have this argument, but it does help explain why there are so many broken devices out there.

[nctnico]

With proportional accelleration, your point is just moot. You'd be at an insanely wrong value anyway when you spin the knob way too fast. A better analogy is driving a car into a corner too fast. You'll crash the car and it is 100% user error. It is a situation that will not happen when users operate a device the way it is intended. If not, it is immediately clear to the user they are operating the device wrong. So any behaviour outside normal operational limits doesn't need to be covered or dealt with. In the end the device will be cheaper to make which is more of interest to a potential customer compared to having an overengineered front panel that contains more parts that can fail. Besides that, -as I have shown before- it doesn't take much CPU power to sample an encoder at a decent speed that makes missing steps in normal operation (IOW: not turning the encoder with a Dremel at full speed) a non-issue. But yes, some people do have problems getting parallel processes to work well.

[PCB.Wiz]

The shaft encoder is recognized as "fast" so people do it correctly.

Even then I've seen a "second pass" needed - the designer ran the tool bed velocity numbers fine, but forgot about real world site load and shock and whiplash effects.  (operators can be rough    )
So it worked fine on the bench, but lost counts in the field, so he came to me.
We used a PLD to solve it, tho I think the newest LSI Quad counters have upped their MHz to be ok now too.

[artag]

The other two could, again be done with 1.  Rotate to highlight parameter, press to select, rotate to change, press to commit.  I still think it would be much easier, faster to use with 2.  I have 2 hands for a start!

My 3D printer does this. It's horrible. Pressing the control often generates an edge, resulting in the wrong thing being selected. Maybe it's just poor implementation or low quality encoder. The selection items are quite coarse, not a precise value so a deadzone at the start of a move, or a capture of the recent value just before click would improve it.

My HP scope does it, but sparingly - only 2 of 14 encoders have pressbuttons and those are used with coarse selections, not vernier adjustments. It manages not to annoy me most of the time. I guess they did a bit more UX testing than the 3D printer people.

Suggestions ?
 

[nctnico]

A seperate select button is an option but if you have proportional accelleration (here I go again, I know), you can use an encoder with a lower resolution. This makes it far less likely to turn the encoder enough to change a parameter while you press it.

[SiliconWizard]

Different encoders, different use cases, different approaches.

Again if you use an encoder with detent with a purpose, which is usually to make one detent = 1 "step" from a UI POV, acceleration, or uneven steps, is an UI failure.
Acceleration schemes can be useful in other cases and should not be used with encoders with detent, at least IMHO, for a lack of UI consistency.

Obviously UI is kind of a lost art anyway, so everything goes.

[nctnico]

IMHO detents don't matter where it comes to accelleration or not. When turned slowly, you can expect 1 increment per click. When turned faster, anything goes. Who can keep track of the number of clicks when rotating a knob quickly anyway? The only differentiator for using encoders with detents is when these are combined with a select function. With a detent it is unlikely the encoder changes the selection when pressed. OTOH the software can be programmed in a way that the encoder needs to rotate two positions before the selection is changed (basically halving the resolution) to make it less likely to 'slip'.

[RoGeorge]

The contacts can be very noisy.  It might be impossible to preserve the absolute position alignment without continuously estimating the expected duration of the quadrature pulses.