# What problems could occur when chaining 40 shift registers?

I'm planning on chaining together 40 x 74HC595 shift registers. The whole chain of 74HC595s will be controlled by a 5 V microcontroller, which will generate the SDI, CLOCK & LATCH signals.

Each shift register and the microcontroller will have its own PCB, as illustrated in the diagram below:

Because of mechanical constrains, the distance between each shift register will be of about 30 cm (12 in), so the control signals will travel along a distance of aprox. 12 m (40 ft). Besides that, the whole system will be mounted in a very noisy environment (near fluorescent lights, mains wires etc.)

My concern is that the control signals will be very noisy and the shift registers might output the wrong things. I was thinking of:

• Using a buffer IC on each board, to buffer the control signals. Which one would you recommend?
• Using shielded cables between the boards for the signals
• Lowering the CLOCK frequency as much as possible. I only need to update the registers' content a few times a day.

Are the above solutions a good thing to do? What else can I do to keep the (potential) noise in the signal wires to a minimum?

• This sounds like a fantastic candidate for a CPLD in place of the 40 shift registers. – Joel B Sep 13 '12 at 19:58
• @JoelB It might sound like a good fit for a CPLD, but that would mean having 320 (= 40*8) signals going from the main board (CPLD) to all over the place. It would be very hard to install, in my case, in that environment; and it will be very hard to maintain. Plus, the signals, although shorter, they'll still be subjected to noise. – m.Alin Sep 13 '12 at 20:25
• @Joel - Digikey lists only a few CPLDs with 320 I/Os, and they're all BGAs. They're more expensive than 40 '595s also, and like m.Alin says you don't have the advantage of the distributed signals. From a logical point of view this is a perfect job for a CPLD, from a practical less so. – stevenvh Sep 14 '12 at 5:45
• @m.Alin - You're totally right. I just read 40 shift registers and typed in CPLD. After reading the question thoroughly, how you are doing it makes sense. – Joel B Sep 14 '12 at 14:25

Use Schmitt-trigger buffers at the inputs of each board. They will clean up the signals so that any noise won't give false pulses on the clock, for instance. The 74LVC3G17 is a triple non-inverting buffer.

Also, pass the buffered signals to the next board. Otherwise all inputs would be parallel and you may exceed the fan-out of the driving microcontroller (I'm especially thinking of the total capacitive load). The daisy chain of clock and latch signals will give a ripple delay throughout the chain, but the data will do so as well, and you plan to go for low speed anyway.

• @m.Alin - Yes, a push-pull stage would be fine. But I would strongly recommend the buffers, not just for the drive capability, but especially for the Schmitt-trigger's hysteresis, which will avoid false clock pulses caused by noise around the threshold. – stevenvh Sep 13 '12 at 16:21
• @Saad - You mean the buffer drives the signal to the cable? The good thing is then that it will provide a low impedance which reduces noise. But if there would be noise on the receiver side you can't do anything about it on the sending side. So it's the receiver which needs a good noise immunity, which the Schmitt-trigger provides. – stevenvh Sep 13 '12 at 17:57
• @Saad - Yes, but in this case it seems overkill: the wires are only 30 cm long, and you have a repeater/buffer on each board already. – stevenvh Sep 13 '12 at 18:14
• @stevenvh Yes, I was talking generally. Your posts have a wealth of information and I almost always learn something new! In this case, I have buffers on a controller board which connect to a cable which connects to a 'daughter board'. I don't expect much noise, so I might stay with my arrangement. I only have buffers there so that my source doesn't end up driving 8 devices (with 8pF input capacitance + trace and cable capacitance). – Saad Sep 13 '12 at 18:18
• @Saad - Thanks for the flowers! :-) Keep an eye on the cable's capacitance, especially if it's more than a meter or so long. Rule-of-thumb: 100 pF/m, that's a lot more than the input capacitance. – stevenvh Sep 13 '12 at 18:23

The problem that can occur is that some SR clocks before the next SR clocks, so that next SR will clock in the wrong data. A (standard?) solution for this is to wire the clock starting at the last SR.

I would consider adding a (schmit-trigger?) buffer at each board for all 3 signal lines.

(edit) Lowering the clock frequency won't help (unless it was far too high to begin with). The problems you can have occur at the clock edges, which you will have anyway, no matter how low you choose your clock frequency.

The biggest issue when chaining shift registers is ensuring that the timing relationship between the clock used by each board uses for receiving data and the change in data from the previous board is predictable. The fact that the output of the 74HC595 changes on the same edge as the clock is a little annoying in that regard. I would suggest that the clock signal should be buffered as it goes through each board and that the data signal coming out of one board's 74HC595 should be put through a buffer that will delay it by a time slightly longer than the clock buffer.

Alternatively, you could use a shift register like the 74HC4094 which has its data output change on the falling clock edge, or you could add a flip flop between the output of the last 74HC595 on the board and the next board, and have that flip flop latch its output on the falling edge of the clock that drives the 74HC595's (perhaps pass the clock through two inverters to buffer it and feed the inverted clock signal to the flip flop).

If the number of 74HC595 outputs you'll be using is one (or more) less than the number supplied by your chips (e.g. on a board with two 74HC595's you actually only need 15 outputs) you could feed the last 74HC595 on a board with a clock inverted from the others, but that would cost you the use of one 74HC595 output for each time the signal passes between a non-inverted-clock 74HC595 and an inverted-clock 74HC595.