Efficiently reading states of large amount of buttons in Series on a microcontroller

Question

I am currently working on a project that involves reading the states of 500 buttons using a microcontroller. Each button is placed on separate PCBs, with a 30cm gap between each button PCB. The microcontroller is positioned approximately 300cm away from the first button PCB.

1. The microcontroller needs to efficiently poll the states of all 500 buttons.
2. The buttons are arranged in series, and I am seeking an efficient communication method for this series-style configuration without specifying any particular protocol.
3. Each button has one leg connected to GND, and the other to a signal line.
4. Simultaneous reading of all button states is the objective; there's no need to address specific buttons individually.
5. The target is a response time of 2ms or less for reading all button states in series.

Seeking Guidance On:

1. Efficient methods for reading states of a large number of buttons in a series-style configuration using a microcontroller without specifying a particular communication protocol.
2. Recommendations for maintaining signal integrity over the long series of buttons and cable lengths.
3. What kind of IC should I look into?

edit:

1. adding illustration figure

Answer 1

Since you don't care about any specific protocol, the most simple is to create a distributed, 500-bit shift register. Nothing else will get you 500 reads in less time because there is zero protocol overhead. Each pcb is one button, one flipflop, and two 5-pin connectors: Data-In or Data-Out, Strobe, Clock, Vcc, GND.

This sounds like a cumbersome mess with a zillion connections and questionable reliability, but given your requirements, so will any other approach. The good news is that it is very low cost, relatively low speed, and easy to debug and maintain.

Conceptually, the software to drive this is pretty simple. In real life - switch bounce. The switches can be debounced on the boards, interjecting a short delay between the physical push and the input to the shift register, or in software by processing multiple scans of the 500-bit pile, basically 500 instances of a debug processing routine.

Update:

It might be cheaper to put a small uC on each board instead of standard logic components. With just one resistor and one capacitor, a 6-pin (SMT) or 8-pin (DIP) PIC with 4 GPIOs can implement a switch debouncer and shift register stage for less than $1.

Each board regenerates all four signals to drive the next board. It is tempting to run the strobe and clock lines as parallel signals to all 500 boards, but that is way too much load capacitance for megahertz signals.

With logic IC's - an AC-series CMOS flipflop has a typical propagation delay of around 11 ns. Lets round that up to 100 ns. 500 stages equals 50 microseconds of delay, for a max frame rate of 20 500-bit frames per millisecond. Thus, a frame rate of 1 ms should not be a problem. Two chips per board, one flipflop and one gate package to buffer the clock and strobe. A frustration is that I don't think there is a way to do it all in one standard logic package. A flipflop can be configured to be a simple buffer, so a standard dual flipflop can be one shift stage plus one control signal buffer (Clock or Strobe). The problem is the other control signal. Grrrr.

With a uC, things are slower. The switch and strobe inputs can be polled, but the clock input should be a hardware interrupt for minimum latency. All it does is move the data-in bit to the data-out pin. I'm not PIC wizard, but this smells like a few lines of assembler. Multiplied by 500, a 4 MHZ part might not be fast enough. This forum has some true wizards, and they can chime in here.

Answer 2

Assuming this is a one-off...

Let's compare two cases...

500 buttons in 2ms = 250 kbps

500 daisy chained boards

Implementation would be something like a shift register, either in hardware or with a micro. With a clock buffer and a 1-bit latching shift register on each board there should be no signal integrity issues because signals are only transmitted to the next board, so you could use fast clock speeds. No problem to reach the target update speed.

- 5 wire cables: Latch, Data, Clock, VCC, GND

You need 499 identical cables (998 connectors). So the only practical solutions are either to whip an unpaid intern into making them or buying them pre-made. This restricts the choice to off the shelf cheap with 5 (or more) wires... maybe RJ45 or JST/0.1" jumpers...

- 4 wire cables: Data, Clock, VCC, GND

To have a wider choice of cheap readymade cables, 4 wires would be more practical as it allows using RJ11, maybe even USB cables.

This means the latch signal should be encoded with the clock. No clock for a while means latch in the button data, then pulsing the clock shifts the data bits.

It should be possible to do that with a 74HC74 plus a bunch of passives and careful engineering of the clock signal, or a cheap micro on each switch PCB. The latter can also allow debouncing locally, but you have to whip an unpaid intern into programming 500 mcu's or buy them pre-programmed.

Here's a quick and dirty example. Each button PCB has a buffer (two inverters) and a D flip flop. The switches are filtered by 100nF capacitors.

Initially, all the flip flops are set to 1. First the clock is held high for 250µs, which sends low voltage to the diodes. When the switch is on, it discharges the 100pF cap, which resets the flip flop. Then clock goes low for another 250µs, which brings the reset lines high again through the diodes. Then 500 clock pulses are emitted at 1MHz, which shifts all the data through the flip flops: the result is inverted, closed switches result in a 0 bit. The last flip flop in the chain has its input tied to VCC, so as the whole shift register is read, it is filled with 1's at the same time. Then the cycle repeats.

I used high value resistors because the per-PCB consumption should be kept low.

- 3 wire cables: Data, VCC, GND

With MCUs this is also possible by encoding the data into the length of a pulse. The last MCU in the chain sends its status every 2ms, then each MCU acts as a repeater and adds its own button status as the end of the pulse train. Decoding could will probably require a dedicated bitbanging micro, or a fast micro using oversampling. But you can use 3.5mm jack cables (and their legendary reliability).

63 daisy chained boards

The alternative is to use one "smart" board for every 8 buttons for example. This adds more 2-wire cabling between buttons and board, and it reduces the number of multiwire cables between boards.

This may be an advantageous solution if it is easier and cheaper to find a large number of 2-wire cables, than a large number of 4-5-wire cables.

In this case each board would either use a 74HC165 shift register, or a microcontroller with local debouncing.

In all cases, wires will be long and thin so each board should use minimum power.

Answer 3

You're looking almost 90 meter of wire. That will give you some signal integrity challanges.
A serial method involving "an IC" will probably be too slow for your 2 ms requirement. For example, CAN bus was mentioned.
CAN bus is a slow protocol, at 90 meters you're limited to 500 kBit, then one frame is ~200 us. You can't poll all 500 buttons states within 2 ms.

However, CAN bus could still be feasable if you let buttons only send changes and the number of buttons changing at once is limited.
CAN bus will provide signal integrity and communication robustness with checksum and retries. An 9-bit DIP switch could set the "ID" of each node. This does introduce implicit priorities for buttons due to the way CAN bus does bus arbitration.

However, in my opinion the optimal way to approach this given the requirements:

• simultaneous reading of all button states
• 2ms response time

Would be to use a realtime field IO system, for example group buttons together into fieldbus nodes with Ethercat. (eg: Beckhoff).
Ethercat is a realtime ring network protocol based on Ethernet, where a single master can poll data from every node on a fixed interval and can be used to read the states every 2 ms for example.

Yet doing Ethercat master in "an mcu" raises the complexity by a large amount.

I would recommend watching Jeff Geerlings video about the MrBeast game setup. For similar challanges.