# Maximum Switching Speed Chained 74HC595

I'm planning to use a set of daisy chained 74HC595s to control a set of 108 mosfets, 3 of them are geographically in the same area (couple of mm apart) and for the sake of modularity should each use their own register. That would mean I will use 36 74HC595s and chain them together. They are all on one board and the distance between the groups of 3 is around 2-5cm.

Questions:

1. How do I calculate the minimum time it takes to to write the whole set of serial instructions to 36 74HC595? I figured I need to add clock rise times and propagation times, but I'm not sure exactly how.
2. Is there anything else I need to add for this to work? Do I need additonal buffers or delay components? There's gonna be some noise made by high currents (through the mosfet).
• a set of 108 mosfets, 3 of them are geographically in the same area. So 105 MOSFET's are "somewhere else"? How "far away" are they? You should include a schematic (of at least a section) of how you intend to connect everything. You might want to first just figure out how to use two (or three) 74HC595 in a daisy chain and make that work, see how fast it can go. Commented Mar 12, 2019 at 11:15
• As mentioned the groups of 3 are 2-5cm apart, I updated my question to reflect that better. It's a modular system, thats why I want to have a register per group. I was planning on doing exactly those tests, I just wanted to know how to calculate the theoretical minimum speed before I order them. Commented Mar 12, 2019 at 11:30
• Your numbers are a bit off. A total of 13 8-bit shift registers will have a total of 104 outputs. If you truly need to have 108 outputs you would need 14 shift registers. I really do not understand why you now say that you need 36 shift registers. That would give 288 total outputs. Commented Mar 12, 2019 at 12:00
• Because I have a requirement that each module (group of 3) looks the same. I have 36 such modules, i.e. I need 36 identical layouts which leads to 36 registers. An alternative would be a shift register with only 3 outputs, but I couldn't find one. Commented Mar 12, 2019 at 12:18

It would appear that you intend to operate these 13 shift registers using software to bit-bang some GPIO pins of a microcontroller to operate the SER_IN, SER_CLK and REG_CLK of the 74HC595s. It would be unlikely that in this scenario that you would be able to generate the control signals fast enough to exceed the capabilities of the shift registers.

From a pure analytical standpoint, if you can build the circuit to ensure that the SER_CLK signal is essentially the same signal to all of the shift registers then the maximum shifting frequency will be based upon the same specifications of just the first shift register. If there is delay of the SER_CLK getting from shift register to shift register due to long signal traces then you would want to total up that overall delay from end to end and use that as a guide to understand the fastest positive edge to positive edge to next positive edge of the SER_CLK.

I had a recent project there I operated a series of 8 such shift registers driving a total of 64 LEDs in an 8x8 matrix. I was using a microprocessor running at 22.1184 mHz and writing the tightest code possible to bit-bang the control signals I never even came close to overclocking the shift registers.

You will have to use very careful design with handling the high current paths of your MOSFETs. If you get significant GND noise it could impair the signal integrity at the shift registers and cause them to not operate correctly. Do keep in mind that this type of noise and its ability to disrupt proper operation of the shift registers will have very little to do with how fast you operate the shift register control signals.

• thanks for the coherent answer! what would you consider 'long' when you are talking about signal traces? Commented Mar 12, 2019 at 11:47
• @Julian - Long traces would be ones that start delaying your clock so much that you would have to be concerned about the additional nanoseconds accumulated. Best answer I can give is that signals travel about 1.5 nanoseconds per foot of signal transmission. Of bigger concern would be the distributed capacitance of the signal trace and the input pin capacitance of many loads. This capacitance will have the effect of slowing down the rise time of the signalling. A slower rise time can change the time a distant shift register may respond to the signal due to the extra time for the (continued) Commented Mar 12, 2019 at 11:54
• (continued from above) signal to trigger the active threshold of the target IC. Commented Mar 12, 2019 at 11:55

I daisychained 45 shift registers (TPIC6B595, high current sink version of 74HC595) with Arduino, system clock 16 MHz, using built-in SPI hardware to send data out with 8 MHz SPI clock. The shift register clock ran at 8 MHz. I was able to achieve 20 KHz update rate. SN74HC595 (TI brand) has a max clock of 25 MHz, so with a faster processor you should be able to go 3 times faster. With Arduino, it takes 17 clocks to output a byte. At 16 MHz, that's 62.5nS/clock, so you could figure it will take

36 shift registers * 17 clocks/shift register * 62.5nS/Clock = 38 microseconds

With a faster processor, you could push that down by ~ 1/3.

For layout comparison, I had 5 boards with 9 shift registers each, and each board had the shift register clock, data out line, and latch line buffered to break up the capacitance seen by the microcontroller.

• can you explain where the 17 comes from? The 74HC595 only has 8 bits correct? Commented Mar 12, 2019 at 11:49
• Yes, shift register has 8 bits. Need 2 system clocks for each SPI clock. Then one more to load a byte into the SPI hardware register. Each transfer looked like this in code: spdr = arrayLookup[0]; nop; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop; repeated 45 times, with the array index going from 0 to 44. No-ops were used to wait out the transfer vs waiting for an interrupt from the SPI hardware. Member Nick Gammon helped me figure that part out. Additionally, I had to turn interrupts off to keep the background millis() and micros() timer from screwing up the data flow. Commented Mar 12, 2019 at 12:02