# What are my options for interfacing **30** incremental encoders to an MCU?

Background: I am familiar with interfacing a few incremental/quadrature encoders to a single MCU chip. My go-to chip STM32F10x can decode 4-5 encoders even in a LQFP64 package (e.g. STM32F100R8T6 has 4), which had always been more than enough for me... until now.

Problem: I want an ATXMEGA128 to effectively poll counts of all 30 encoders at 1kHz (say, by keeping 16-bit counters). I cannot change the ATXMEGA128 to some other MCU, but I can add another MCU to interface with it.

The bottom line is I could slap on a FPGA (e.g. Spartan3E) and make it talk to MCU through SPI or parallel, but I'd like to consider some alternatives before I go down this path (for non-technical reasons). The number can be reduced to 15 if 30 seems too hard without FPGA.

• I can't see any better way than using an FPGA if you need the parallelism. If you can read them (pseudo-)serially you might be able to divide them into groups and feed them into analog MUXes... but I imagine that would be unnecessarily bulky, expensive, and painful to route – Shamtam Feb 5 '15 at 4:29
• @Shamtam MUX is another thing I'm trying to avoid here, due to complexity as you said. – Yin Zhong Feb 5 '15 at 4:54
• You could group them and use smaller MCUs or maybe CPLDs for each group, in a modular fashion . – Spehro Pefhany Feb 5 '15 at 4:58
• @SpehroPefhany CPLD might make sense as they're dead simple. Thanks for suggesting! – Yin Zhong Feb 5 '15 at 5:15

A small FPGA is the way to go here. You would need a very large CPLD to manage this many encoders - they are not useful for much more than glue logic. Generally a CPLD gives you one flip-flop per pin. An FPGA has logic resources that are specifically designed for building things like accumulators and shift registers, and far more of them than a CPLD with the same number of pins. For 30 encoders with 16 bit counters on each, that's a minimum of 480 flip flops just for the counters, not counting the encoder processing and SPI interface. I would suggest a small Spartan 3 or Spartan 6 - they are available in TQFP and should be easy to interface with.

• Spartans are definitely up to the job; I'm just wondering if I have alternatives... – Yin Zhong Feb 5 '15 at 14:50

Why not use quadrature decoder chips? The LSI LS7366R is a 32 bit quadrature decoder that also supports the index signal if needed. Everything you need is inside that chip and read via SPI.

There is also the old standard Avago, previously Agilent, previously HP HCTL-2032-SC. It uses an old school parallel bus interface and is in a large PDIP package. I am putting it here for reference as I have seen it used in many old CNC controllers.

• This seems like a good idea. One problem is that if you put them all on the same SPI interface, you would need 30 enable or chip select signals. Maybe an IO expander for that part of the problem. – mkeith Feb 5 '15 at 6:09
• @mkeith : Sure I could use some address decoder, but still that means I need to put 30 of these on my board (lots of $). To OP : Do you know anyone who sell them? Not mouser or digikey... I doubt if the price * 30 would beat a CPLD though. – Yin Zhong Feb 5 '15 at 6:22 • US Digital sells them @4.75 each for quantities between 10 and 29 pieces: (usdigital.com/products/interfaces/ics/lfls7366r-s) – Mister Tea Feb 5 '15 at 7:15 • I'd be hesitant to base anything other than a one-off on a chip without a major distributor. – Scott Seidman Feb 5 '15 at 14:42 • I agree that this is a valid hardware-only solution (+), although at$4.75/ch this gets more expensive than FPGA both in cost and in time (-, need to route all 30 channels!) – Yin Zhong Feb 5 '15 at 15:33

This solution is very extensible, but it creates a big mess of wires.

You can interface one encoder with two 74HC193s and use a bunch of I2C GPIO extender to read them. This will allow you to add as many encoders as you like.

• I'm afraid anything based upon I2C wouldn't be fast enough to keep up with the data rate... – Yin Zhong Feb 5 '15 at 14:47

In the end the decision was to group them by 4 as @spehro-pefhany suggested in comment, and connect them to a bunch of MCUs, which can then communicate on SPI bus.

The main advantage is less cable mess, as I can place the MCUs close to the encoders.