Electronics > Microcontrollers

Having many rotary encoders.

(1/17) > >>

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.

Navigation

[0] Message Index

[#] Next page