Having many rotary encoders.

[paulca]

I wanted to start making a TFT+Rotary encoder interface for a project, but when I came to work out what I needed the rotary encoders turned out to be a bit more involved than I thought.

I would like 6 to start with, might need more, 10 maybe.

STM32's have a rather handy encoder mode for it's timers.  However, from a quick search the largest amount of these available, from the F103 up to the H750 is .... 4.

I went through a few google searches and seen a few solutions, which seemed either "janky" like HC74 multiplexers and hot loop polling them in the main loop, to using additional micros.

I searched and found a few breakout style AdaFruit et.al boards which presented an I2C bus interface allowing the encoders to be chained into long strings of I2C devices on the same bus.  They even do their own counting internally, raise hardware interrupts on change etc. etc.  They are also damned expensive, come from the US and all it really is, is a £3 micro-controller under the encoder.  While convenient in purchasable form, it's a bit inefficient to use a single micro per encoder when an F103 can handle at least 4 (more if you do the others in software with EXTIrq's).

A rotary encoder multiplexer sounds like a fun project.

I thought I'd ask if anyone has any magical ways of reading 6 or more encoders without having to use 1 or 2 small MCUs to do so?  In fairness, 6 encoders is 18 pins straight up.  Add your uplink periph, like I2S or SPI and the usual other pin items and a 48pin MCU is way over 50% pin allocated.  A F013 running 4 rotary encoders and raising interrupts, transferring data over I2C or SPI probably isn't going to have much left in terms of timing and performance either.

I have an F401 which was dedicated to the UI, now it seems as though that expands to the F401 for the TFT and main UI code + 2xF103's to run the rotary encoders!  Good new is, they are cheap, might do the job without an external clock, available in 10s of thousands for £3 each.

[Ian.M]

It depends on how fast you need to read them.  Save the MCU's built in QEI/encoder modules for anything fast e.g. high RPM shaft encoders.

Assuming you need to read six clickable knob encoders, if you use an ADC input + resistor ladder to read the click switch (which means you cant read clicks further down the ladder if a higher one is held in), you can save five pins, dropping the requirements to 12 digital and one analog port pins.  If you don't want to have to poll them when idle, those will need to be IOC capable + the analog pin will need to be able to generate a comparator interrupt.

Another approach to minimising the pin count for mechanical (switch to ground) knob encoders is to wire them in a matrix with a schottky diode in series with each encoder's A, B and switch pins.  You can then select an encoder by driving its common pin low, deselecting the others by driving their commons high.   That gets you down to nine I/O pins, but you cant use IOC wakeup, unless the encoder knobs have detents with both A and B open at the detent positions.

[dave j]

RP2040s have no problem supporting eight rotary encoders using PIO.

[Berni]

You can just use a GPIO pin change interrupt to fire off a small state machine for each of the encoders.

You also get notified of what pin number saw the change so if you distribute the encoders over the right pins you can have the flags tell you only what encoder needs updating and only execute its corresponding state machine to save CPU cycles.

The code only runs when a encoder makes a step and it is so short that it doesn't really eat many cycles to service. So given enough pins you could easily have one MCU service 50 encoders.

[paulca]

6 encoders.  4 of them on the Timer Encoders.  The other 2 on ExtIrq GPIOs.  Still requires 18 pins, but an F103 should cover that fine and so the SPI updates to the processor with the config.

I think the point about speed is valid, these hardware "encoder" modes might be more useful if you are using, say, high percision, detent-less encoders that encode hundreds of steps per rotation and you can't be expected to handly each step with an interrupt routine.  For a few volume knobs and some parameter select + value knobs....  overkill.

However, if I have 4 of them why not use them.  Actually it works out okay, as 4 of them are volume controls and I already worked out how to limit them to 0-100 in the ISR.

The other two are "Parameter select" and "Parameter value", which have much more free-form ranges and steps so are probably better done in a custom Irq handler anyway.  Obviously it depends on what paramter you have selected as to how the encoder behaves.... I might step through 0-100 volume in 1s, but I'm not stepping through a "Filter cut off" frequency entry in 10s or 100s even, it will need to log something.  The gain is a linear float (unless I get more annoyed with that than I already am), so it needs to step in log-something steps from 0.001 to 1.0.

Putting the TFT and all 6 encoders onto the single F401 might be doable, I mean it's still only 27 pins or something, but I don't think creating a little encoder bank PCB with a F103 is "excessive modularisation".  I'm sure I will have other projects that require a set of encoders.  I'm also striving to find ways to modularise and limit the overall size of the prototype on breadboads.  Wrapping something like this onto a PCB with some JST-XH connectors, rather than a bit hairy jumpered breadboard birds nest.

[paulca]

BTW.... I am also aware it would be possible to do the whole UI with a single encoder.

It's just that is one of my pet peeves about electronics in general.  "You could have done it so much justice, you could have created a truely excellent product, but you had to go and bean count things didn't you?  4 Rotary encoders worked out to be more expensive over the full product production cycle than the time it would take the out-sourced programming contractor to code it for a single encoder.", therefore the product has a single encoder whether that was the best solution or not.

I set the bar quickly by saying, "I want an independant, always available volume control on each input and each output.  No Select from menu, change value."

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!

Also, "Why not just 100K POTs and ADC channel for volume knobs?".  It's a good question.  My answer is mostly subjective.  I hate pots slightly more than I hate rotary encoders, for the same reasons.  They end up scratchy, fissly, jump values, or my favourite.... the volume control stops at 99% and never goes to 100% because the ADC VREF is VCC.  Also.  non-motorised POTs can't be automated and remain in sync.  So if you automate the value and a bird takes off from the window sill causing a twitch on the ADC and it overwrites your value back to the physical position of the POT... rar..rar...rar.  etc.

[wek]

However, from a quick search the largest amount of these available, from the F103 up to the H750 is .... 4.

On STM32H750, you can use TIM1/TIM8, TIM2/TIM3/TIM4/TIM5, and also LPTIM1 and LPTIM2. That's 8.

JW

[paulca]

However, from a quick search the largest amount of these available, from the F103 up to the H750 is .... 4.

On STM32H750, you can use TIM1/TIM8, TIM2/TIM3/TIM4/TIM5, and also LPTIM1 and LPTIM2. That's 8.

JW

Interesting.  To be honest I was basing my "4" from the high level features list.

2× 32-bit timers with up to 4 IC/OC/PWM or
pulse counter and quadrature (incremental)
encoder input (up to 240 MHz)

I wouldn't be surprised if that isn't 100% correct

I could use the 750 for the whole UI, but even then it feels like overkill.  I happen to have an H7B0 as well, even it would be overkill.  Timing is too tight on the processing MCU to task it with UI work and it's complicated enough.

What is bound to happen here is... I'll push forward with an F401, get it nearly working and something will crop up which means I need a bigger micro anyway and end up re-doing it for the H7 anyway.  Still the journey will be fun.

The UI needing the H7B0 of H750 will come about if/when I implement the touchscreen and present the EQ settings as a rendered graphical curve and allow the EQ grab handles to be clicked and dragged around.  Recalculating the curves and rendering them realtime with enough low latency to give enough feedback for dragging will require a descent refresh rate.  I'm not doing that this time round... mostly because I don't have the graphical programming or maths skills to do that and won't really know where to begin.  So a weedier micro will do.

[peter-h]

This is not of direct use to you but in the 1980s I implemented a rotary encoder interface on a Z80, via the Z80-PIO chip, and a few gates. The PIO has two 16 bit counters and this meant the CPU didn't have to sample it very often. It was an elegant solution which went into lots of products and never gave any trouble. I recognise this https://www.fpga4fun.com/QuadratureDecoder.html as something very similar.

[Peabody]

Can you say that at most two encoders would be turning at the same time?  If so, then the interrupt burden wouldn't be all that great, but the limitation would be identifying which encoder generated the interrupt without having to read all the GPIOs.  For the Atmega328P for example, I found that I could have four encoders (but not their push buttons) with very little IRQ overhead.  That chip only has two "hardware" interrupt pins.  And it has one pin change interrupt flag per port, so you don't know which pin changed.

In the end, I worked out a system in which the interrupt is enabled on only one of each encoder's pins at a time (which also greatly reduced interrupts due to bouncing).  To deal properly with direction changes, the 16-byte lookup table was extended to 32 bytes.  Anyway, I could have four encoders on that processor - one on the the hardware interrupt pins, and one on each of ports B, C, and D using pin change.

But if you had a processor that had a more capable pin change flag register that would identify which pin actually generated the interrupt, then it seems the only limitation on the number of encoders would be the pins available.  I think even the lowly MSP430 chips would do that.  They don't have pin change interrupts, but do have both rising and falling edges, by pin, and do identify the interrupting pin in the flag register.

Anyway, my point is that if your processor lets you identify which encoder generated the interrupt without having to read GPIO pins, and if you only have to service at most two encoders at the same time, then the only real limit is the number of pins available.

[mino-fm]

You need one >= ATtiny202 per encoder and can readout via IIC: http://mino-elektronik.de/mt12_iic/mt12_iic.htm#qcnt_tiny202
Look above, there is a circuit using an ATtiny25.

[paulca]

This is not of direct use to you but in the 1980s I implemented a rotary encoder interface on a Z80, via the Z80-PIO chip, and a few gates. The PIO has two 16 bit counters and this meant the CPU didn't have to sample it very often. It was an elegant solution which went into lots of products and never gave any trouble. I recognise this https://www.fpga4fun.com/QuadratureDecoder.html as something very similar.

It has to be similar to what STM32 are doing with the Encoder mode.

[langwadt]

I'm quite sure an F4xx will do six, from stm32f11ex.h

Code: [Select]

/****************** TIM Instances : supporting encoder interface **************/
#define IS_TIM_ENCODER_INTERFACE_INSTANCE(INSTANCE)  (((INSTANCE) == TIM1) || \
                                                      ((INSTANCE) == TIM2) || \
                                                      ((INSTANCE) == TIM3) || \
                                                      ((INSTANCE) == TIM4) || \
                                                      ((INSTANCE) == TIM5) || \
                                                      ((INSTANCE) == TIM9))


[SiliconWizard]

Sorry if I missed a post and that is redundant.

But obviously if you have many encoders to handle, just use GPIOs configured as inputs, one time and sample the inputs, do not trigger interrupts on them. Just use a single timer and sample everything in it.

[paulca]

I'm quite sure an F4xx will do six, from stm32f11ex.h

Code: [Select]

/****************** TIM Instances : supporting encoder interface **************/
#define IS_TIM_ENCODER_INTERFACE_INSTANCE(INSTANCE)  (((INSTANCE) == TIM1) || \
                                                      ((INSTANCE) == TIM2) || \
                                                      ((INSTANCE) == TIM3) || \
                                                      ((INSTANCE) == TIM4) || \
                                                      ((INSTANCE) == TIM5) || \
                                                      ((INSTANCE) == TIM9))


Yes I also found the F401 will do 5.  Possibly the F4* can do 6, but pin count etc. they just say "4" across the board?  Probably a case of "I should FTFD".

[Dave]

But obviously if you have many encoders to handle, just use GPIOs configured as inputs, one time and sample the inputs, do not trigger interrupts on them. Just use a single timer and sample everything in it.

This is the way to go. Triggering interrupts on pin changes is silly. The contacts tend to bounce more as the encoders get old, so it eventually might start to affect the performance of your application. Not good.
In my experience, sampling encoder pins with 1kHz was fast enough that I was unable to make the count skip when twiddling the encoder (12 pulses per rotation) as fast as I could with my fingers.

[peter-h]

It has to be similar to what STM32 are doing with the Encoder mode.

Yes, probably. I remember wrong though. It was a Z80-CTC and the two 16 bit counters were fed with upcount and downcount, and some software subtracted them from each other, using modular arithmetic.

If you were interrupting from each edge you would do the same thing.

The bit I never understood was how the boundary conditions were handled e.g. an edge arriving at exactly the "wrong" time. But it did. Somebody worked it out

[nctnico]

You can just use a GPIO pin change interrupt to fire off a small state machine for each of the encoders.

You also get notified of what pin number saw the change so if you distribute the encoders over the right pins you can have the flags tell you only what encoder needs updating and only execute its corresponding state machine to save CPU cycles.

Interrupts on GPIO pins is asking for trouble. Don't do that. Especially encoders can get flaky and then the whole thing comes crashing down. But still you can use GPIOs. But sample these under a timer interrupt while using a switch matrix. That is how it is done in test equipment like oscilloscopes with rather slow microcontrollers... Easy peasy for a modern day microcontroller.

[PCB.Wiz]

I wanted to start making a TFT+Rotary encoder interface for a project, but when I came to work out what I needed the rotary encoders turned out to be a bit more involved than I thought.

I would like 6 to start with, might need more, 10 maybe.

A rotary encoder multiplexer sounds like a fun project.

I thought I'd ask if anyone has any magical ways of reading 6 or more encoders without having to use 1 or 2 small MCUs to do so? 

That depends on the speed.
You cannot hardware MUX fast quad pins, as the edges contain the information.

There  are  hardware Quad counter chips, but they cost more than the small MCU you want to avoid 
https://lsicsi.com/shop-products/counters/
You would use those if your encoder was motor position driven, needing high capture speed.

I set the bar quickly by saying, "I want an independant, always available volume control on each input and each output.  No Select from menu, change value."

Ah, OK, for a UI operator control,  you do not need MHz speeds, so you have many solutions.

If you expect to use many channels, I'd skip the many-hardware-timer config step, as that's a lot of testing (or maybe config one timer, for easy testing the Sw counters.. )

As the operator has only two hands, total edge rate will be quite low.

Your choices are a pins-change interrupt, or a timer interrupt that polls pins.

In both cases, you read the whole group of Quad Ctrs and act on the one that changed, in a state machine. Interrupt code path is always fast.

It is a good idea to use a series RC filter on the encoder pins, that works with the Schmitt pin (most MCUs have) to limit the highest bounce frequencies.

Notice the decision to use a remote small MCU or poll-read via a i2c/SPI GPIO, is often made by the wiring.

Placing the pin-read device on the front panel, can slash the wires needed.

There are shiploads of 8 and 16 bit GPIO parts, you can even buy > 16 GPIO, but they are into the rare and expensive space.


Addit: If you are not making hundreds, there are at-the-encoder i2c solutions, that place a MCU at each encoder  ( little MCU these days are cheaper than cables !)
https://www.duppa.net/shop/
those have 32-bit i2c counters, mounted on the back of the encoder, and one supports a nifty RGB illuminated encoder.

[SiliconWizard]

But obviously if you have many encoders to handle, just use GPIOs configured as inputs, one time and sample the inputs, do not trigger interrupts on them. Just use a single timer and sample everything in it.

This is the way to go. Triggering interrupts on pin changes is silly. The contacts tend to bounce more as the encoders get old, so it eventually might start to affect the performance of your application. Not good.
In my experience, sampling encoder pins with 1kHz was fast enough that I was unable to make the count skip when twiddling the encoder (12 pulses per rotation) as fast as I could with my fingers.

Yeah. Interrupts on A/B signals change for rotary encoders may be used in very specific cases, for instance if you want your device to be in a deep sleep mode most of the time, and wake up on some action on encoders. (And sure it requires proper debouncing.) Otherwise, simultaneous sampling of all signals in a single timer is the best approach. The sampling period doesn't need to be very short. 1 ms is plenty. You can probably go with even slower sampling.

[dobsonr741]

A long shift register chain read by DMA over SPI. Example at midibox: http://www.ucapps.de/mbhp_din.html + the firmware for ST32

Not polling, not IRQ, DMA instead.

[Berni]

Interrupts on GPIO pins is asking for trouble. Don't do that. Especially encoders can get flaky and then the whole thing comes crashing down. But still you can use GPIOs. But sample these under a timer interrupt while using a switch matrix. That is how it is done in test equipment like oscilloscopes with rather slow microcontrollers... Easy peasy for a modern day microcontroller.

Have been using the interrupt based encoder method a few times and it worked fine.

I always put capacitors on the encoder pins to clean up the contact bounce. But even if they do bounce, correctly written code will not care, it just results in extra CPU load of entering an interrupt multiple times. The interrupt will just have its count value twitch back and forth as if the user was twitching the encoder back and forth (Since that's what the pins look like is happening). Overall the CPU usage is very low because humans can't spin encoders very fast.

The kind of encoder code that breaks with bouncing this is the kind where you interrupt on say A signal and then check the state of B to see if you will increment/decrement. Any contact bounce will completely screw that up and give ghost counts. The method you should be using instead is a state machine with 4 states that transitions between states upon seeing the appropriate edge on the A and B pins.

The more tricky part is getting velocity control to work nicely. That needs the involvement of a timer to periodically check the rotation speed and amplify it up when needed. This is where a lot of products fall on its face. A lot don't have velocity control at all while others implement it in a bad way, like where there is a thin line between no velocity but going a bit faster shoots you off at the speed of light, or even velocity control that seams to sometimes go slow sometimes fast randomly.

[paulca]

Addit: If you are not making hundreds, there are at-the-encoder i2c solutions, that place a MCU at each encoder  ( little MCU these days are cheaper than cables !)
https://www.duppa.net/shop/
those have 32-bit i2c counters, mounted on the back of the encoder, and one supports a nifty RGB illuminated encoder.

I seen these.  They aren't cheap especially if you wanted 6 of them!  When I seen them I thought, well, if I was to buy those, why not make something instead.

I had a play last night.  An STM32F103, 4 timer based encoders, SPI uplink to the main UI.  Interrupts of the switches.  On change handler to filter the output.  Debug UART.  It was rather straight forward to get one encoder working.  4 should mostly be copy and paste.  The F103 has very little left, it maybe has about 7 usable pins left.  Each encoder has a small struct which is sent over SPI "onchange".

I actually went off on a tangent trying to implement the full button state machine events like, Down, Up, Click, Hold, Release, Double Click.  The first 3 are easy enough, the later 3 require state machine and timers.  In the end however I came face to face with the fact that to implement all those "events" properly, I would need to think it through carefully and create some form of event system, winging it and hacking it would just lead to tears.  Up, Down and Click will be fine for now

Good points on the bouncing interrupts.  I will get the same for the switches, but in testing it doesn't seem that bad, they are quite heavily gated microswitches so you have to push them quiet hard and then they "SNAP" closed with a tactile click.  I know they will still bounce, but the onchange handler will stop some of the outputs.

On polling a higher number of encoders.  It sounds interesting.  I have done the state machine variant before, we had a discussion in here about it.  I favoured the approach of ignoring everything except what are valid transitions between previous and current states.   It still suffers from bounce, as we discussed, but, it seems solid enough with a new encoder.  It might not work as well with a dirty old encoder.

Assuming I carry on with the F103 approach, the plan is to make it a PCB with the rotary encoders being mounted mechanically to the PCB via their ring nuts and the pins wired to the board with short wires.  This combines the front panel creation, as I can make the PCB front panel sized, use black solder mask, have the 4 encoders + their MCU on the panel and a large hole and mounting screws for the TFT screen.   I don't need to fix the size of the device, if I need it bigger than I make the front panel, I can just seat the front panel into a larger 3D printed lid.

EDIT: What about the other 2 encoders?

Well, as I said, 4 of them are volume controls, the other 2 are more complicated and will change many different parameters.  So it will be far easier to deal with it local to the UI MCU.  The timer encoders have state (the count).  The 4 volume control board SPI is bi-directional and the UI can send an interrupt to the encoders and send new state for them all, such as at power on to select a default profile or initial volume state.  Trying to use this to set the encoders range, step size etc.  Would be a complete pain.  So they are probably better off local.

[Nominal Animal]

Because I too like rotary encoders, especially the Bourns PEC11R –– I even have a M7x0.75 tap so I can screw the encoder directly to a tapped hole in my cast aluminium project enclosures ––, I've looked at making tiny boards with footprint for the encoder and a TinyAVR 0-series (ATtiny202 or ATtiny402, 0.51€ at Mouser in singles, well stocked; uses UPDI for programming).  As they have I²C/TWI capability (incl. slave) and pin change interrupts on all I/O pins, they're particularly well suited for this.  One could also use them as a SPI slave (chained slave?), but the two need to use different pins, and therefore a different board.

As far as I can tell, the price per such I²C would be around 3€ apiece in lots of ten (including the encoders, which are the majority of the cost – the MCU, board, and passives should be only about 1€ apiece), although one would need to solder the encoder, SOIC-8 MCU, and the couple of passives oneself.

I particularly like the idea of using these in a SPI chain, as SPI slaves, with buffer mode enabled (CTRLB.BUFWR set to 1).  Each encoder would yield a 24-bit record, where the first byte is a 6-bit decisecond counter describing how long the button has been pressed, clamped to 63, starting at 1, with two MSB always 0b10.  The next two bytes are the encoder state as a 16-bit unsigned integer.  The slave chain works like a shift register, and the MCU can find out the number of encoders connected at run time from the first byte in each 24-bit record.  Each encoder state is latched on a suitable transition of the /SS, noting that there must be a couple of milliseconds between that and the first clock pulse, so that all encoders have time to latch their state before the SPI clock starts cycling.

[voltsandjolts]

Addit: If you are not making hundreds, there are at-the-encoder i2c solutions, that place a MCU at each encoder  ( little MCU these days are cheaper than cables !)
https://www.duppa.net/shop/
those have 32-bit i2c counters, mounted on the back of the encoder, and one supports a nifty RGB illuminated encoder.

I seen these.  They aren't cheap especially if you wanted 6 of them!  When I seen them I thought, well, if I was to buy those, why not make something instead.

They're not expensive either and they support open source too.