Rotary encoder counter with serial interface

[bastiaang]

Well I am back again with a question. I am searching for a rotary encoder counter like the LS7366R (see attachments for the datasheet). I can already hear you say, why don't you choose th LS7366R, well it is not purchasable at the big three (Digikey, Farnell/Avnet, Mouser) for me. Also the counter doesn't have to be bigger than 16 bits. And the serial interface can be anything readable with a microprocessor. I hope you guys can help me

[KrudyZ]

I would recommend you use an encoder with quadrature output and add a small MCU or CPLD to do the conversion if you can't do it in the existing MCU.

EDIT: re-reading your post I see that you are looking for just the decoder. This is quite straightforward to do in either an MCU or CPLD and likely cheaper as well.

[Illusionist]

How about a dsPIC33EP32MC202? It has a quadrature interface and is cheap enough (possibly, depends if you are talking one-off or production)  to use just for that. It might do the whole job though, whatever that is.

[mrjoda]

or STM32L011 (   STM32L011F4U6TR) , almost every STM32 has encoder interface on general purpose timer. And costs nothing.

[james_s]

Or absolutely any MCU on the market, decoding a quadrature encoder is such a common task that you can just grab some code that already does it and port it to any platform you like.

[SiliconWizard]

And the serial interface can be anything readable with a microprocessor.

I second what others have said. Use a small MCU to do this.
Just a quick question though, if you're using a "microprocessor" (what is it?), can you not implement the decoding for the rotary encoder right inside of it instead?

If not - small MCU. Any very small one should fit for this sole task. Pick any that can do SPI slave. An embedded quadrature decoding peripheral would really not be necessary here IMO as long as it has timers and interrupts.

Besides, who knows, there may even be a small niche market for this, so you could sell that (and make it a little more versatile while you're at it, like offering UART as well, maybe support a few rotary encoders instead of just one, etc.)

[Howardlong]

I agree, use an MCU, particularly for front panel knobs.

I did this with a PIC10F322 some time ago, it provided a simple (software) UART result. This implemented a state machine using change notify interrupt bits.

See posts 14, 22 and 26 here https://www.microchip.com/forums/m933132.aspx

If you want things like SPI or I2C, you might want to consider a device with a couple more pins and hardware serial peripherals. A daisy chained SPI seems like a perfect solution if you have multiple encoders.

[Illusionist]

Aye, small PICs are great for little jobs like this.

I just bought a load of 16F18313 because I needed a flexible logic divider, and the PIC was cheaper and smaller than doing it with logic chips. (Propagation delay wasn't an issue in this case.)

The 8-pin 16F18313 is about 5p more expensive that the 10F322 but has an amazing array of peripherals in it, including a EUSART, DAC, ADC, NCO, CLC... I couldn't resist picking up a tube for those 'little' jobs.

[Howardlong]

I agree that the 18313 (and 15313) are good for this too, as you say the hardware peripherals are better, and the hardware is a lot more flexible: the 10f322 project was there to see if it could be done in a six pin package.

[ggchab]

I am using a small PIC12F1840 to read the rotary encoder of a hobbyist project. It's configured as an I2C slave device and a dedicated line can trigger an interrupt on the main processor when the encoder is rotated.

[Haldor]

I realize this is an old thread, but I was just researching this exact same subject and thought what I found might prove useful.

The first question you have to answer, is how fast do you need need to be able to handle quadrature input? This is determined by the resolution of the quadrature encoder (# of steps/revolution) and the maximum RPM you need to be able to handle.

For handling low speed input, by all means bit-bang it in software. This method can handle higher speed input, but you may want to dedicate a processor to just the quadrature input processing to ensure you don't lose track of position.

Newer ARM processors typically include a QDAC (Quadrature Counter) input block that you can use as long as the step rate is < 10,000 Hz.  This worked out to a max speed of ~ 1000 RPM at 512 steps per revolution (128 step coding disk in x4 mode) for the processor I am using (nRF52832).

If you have higher speed requirements (like a motorized application), then this can be too slow. The LS7366R-S is a great choice for these kinds of applications. In fact the LS7366R-S is overkill for me since it will operate up to 78kRPM at 512 steps/revolution. The downside to the LS7366R-S is it is a single sourced, special purpose IC and considering how difficult the supply chain has become, I am uncomfortable designing that into a commercial product that will be in production for > 10 years. The IC is not exactly cheap either at $7 each.

I found this app note from Renesas that explains how to implement a quadrature counter function with a SPI port using an inexpensive PLD (Programmable Logic Device). The is about 1/4 the speed of the dedicated LS7366S-R for less than $0.50 each. And the concept is easily implemented in a number of comparable parts from a bunch of IC makers.

https://www.renesas.com/br/en/document/apn/cm-277-quadrature-encoder-counter-spi-bus-interface

The app note design can operate above 20,000 RPM at 512 steps/revolution which is a perfect fit for my application. You do need to program the PLD, but the same would be true for a processor based solution. Programming PLDs is not something than most hobbyist are familiar with, but it is less complicated than writing embedded firmware is.

[Infraviolet]

Use a microcontroller to read a quadrature (or other) signal from whatever encoder is in use, then have the microcontroller provide the serial inteface using other GPIO pins? Probably cheaper than a dedicated quadrature-counting-to-serial chip, and more choices for much better availability, Literally any microcontroller which fits with whatever programming toolchain you're used to, fits any board space requirements and can kep up with the encoder signals at maximum rotation speed (interrupts help here) will do.

OOPS, this has already been said several times. But in an era of logistics hell and chip crises, it does have the advantage of just how wide a variety of microcontrollers would all be perfectly compatible for use this way.

Another thought, raspberry Pi's Pico (rp2040) chip has a programmable IO option for some GPIO pins, this might be quite quick?