cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 part with the most avialable rotary/quadrature encoder inputs

JU
Associate III

Let me start by saying:

  • Yes I know the STM32 Finder exists, no it doesn't help me find what I need
  • Yes I've seen this thread but I do not want to get into manually coding a script to try and find parts if I can avoid it
  • Yes I have used the CubeMX and no it can't filter for this requirement

Basically I'm after an STM32 that will allow me to interface the maximum number of rotary encoders possible into timer inputs (no I do not want to bit-bang it).

That's it - any suggestions welcome!

7 REPLIES 7

Usually any regular TIM the has 2 pins/channels. Most will 16-bit

At most only 2 32-bit TIM

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Lots of timer channels that have 2-pins are up-count only, for example G071 has TIM1,2,3,4,6,7,14,15,16,17,and LPTIM 1 & 2 but only 4 timers out of that lot can actually work for encoder inputs (TIM1,2,3,4) hence my question.

AN4013 would be a good place to list available timers with encoder mode or at least the up/down count possibility.

As only Advanced control and General purpose can count up/down, what about adding up both number in table 2/3/4 of AN4013 to get the number you want?

It's not only advanced & GP timers though - LPTIM1 on G071 can do encoder mode but other GP timers cannot - and I've not audited the entire range to see if LPTIMx on other MCU's can do encoder mode or not.

The encoder feature seems to be somewhat inconsistent across timers/MCU's hence my question - it's not clear to me if it depends on number of pins etc...

Add all LPTIM  where you have access to both input pads. Probably LPTIM appeared first in F410 and it already has encoder mode as shown in the block diagram

LCE
Principal

A little bit OT / probably not helpful:

About 2 years ago I tried to add a special kind of pulse measurement to the audio / measurement data, synchronized to the audio sampling, options for IE included. The synchronization actually killed it, took too much CPU power to fiddle pulse / IE data into the audio stream.
So I finally came to the conclusion that our current FPGA-based solution (just switched from Xilinx to Efinix) plus MCU was still the better solution.