20 + Incremental Encoders, Due, Multiplexers or I/O Expanders?


I'm looking to use a Due with 20 incremental encoders for a midi controller. I know I have enough pins on the Due to do this alone, but I would like to free-up as many pins as possible for future expansion.

I have read many posts regarding, and have read of users having problems using encoders and multiplexers, also encoders with I/O expanders 'MCP23017, I2C' and the SPI version 'MCP23S17' is the way to go.

I would like to ask the community of your thoughts or experince's of such.

If the MCP23S17 'SPI', is the best way forward, should I use a special library or should I just use SPI.h? Should I have 1 MCP23S17 for every 8 encoders with it's own CS pin, or should I daisy chain them all to the same CS pin? Should I change the Clock Divider speed?

I would be grateful for your thoughts and any other possible options.

Thank's in advance.


With SPI you need one CS for all or one for each expander. Eventually you can use a decoder to create 8-10 CS signals from a 3-4 bit address. If the I2C expanders have already 3 address pins, no additional signals are required to use 8 expanders at the same bus.

I don't know about special software problems, use whatever does not cause trouble in your project. The speed is limited by the physical extent of the bus, and eventually by external noise.

I'm not sure if it's going to be fast enough. Usually, external interrupts are required to get good accuracy. You could probably use port expanders with pin change interrupts, but still ... One of the advantages of the Due is that it supports interrupts on all pins.


I'm looking to use a Due with 20 incremental encoders for a midi controller.

Exactly what type of encoder are you talking about?

If you are talking about a control knob, then you can probably handle it with 4 IO expanders. You can use the interrupt line on the expander to interrupt when a pin changes, to avoid polling. SPI would allow a higher speed than I2C, plus you can probably daisy chain the SPI devices to read all of them in one transaction (also reduces number of CS lines required).

I think SPI would be better and simpler, it depends what else might be using SPI. Certainly, using hardware interface whether SPI or I2C should be preferred over bit-banging.

Thank you for all of your replies and sharing your thoughts.

The encoders are just the cheap KY040 type with 20 detents.

So the concensous is go with SPI. I'm currently waiting for these SPI versions 'MCP23S17', to arrive.

I'll try them on 1 CS pin, and see how well a couple of encoders react on each IC.

Using the SPI.h library should be ok to use then?

I ask about the SPI.h as I did find the following;

Which links to a Github Library;

"sorry, but the link button only seems to work the once???"

As PieterP is previously aware, my coding skills are quite poor, so if SPI.h will do the job, why complicate things further. If someone could correct me if I'm incorrect?

Thanks again for your inputs.


Regarding the speed, you have to remember that us humans only have 2 hands, so I will only need at the most to be able to read 2 encoders at any moment and only at a revolution speed of how fast I can twist my fingers and thumb.

Still awaiting the SPI ICs, thought they might arrive today, but no such luck.

I have however found this sketch that may or maynot work with the encoders and the MCP23S17s, as I'm using PieterP's MIDI_controller library. I'll just have to wait for the ICs to turn up to test.

Post #9;


The above sketch should have the basic MCP info instead of using an MCP library.