Common latchpins with 74HC595 Shift Register


I'm planning to use the Arduino UNO to drive multiple 74HC595 Shift Registers. To save pins, I had some ideas about connecting all datapins and clockpins of all Shift Registers toghether (i.e. pin 11 and 12 of my Arduino).

Pin 1..10 can then be used to connect 10 induvidual 74HC595 latchpins. Is it true that when I set ALL latchpins to LOW, digitalWrite the common DataPins / ClockPins and only set i.e. Arduino Port 5 (=Latchpin chip 5) to HIGH, only Shiftregister 5 will display the right LED combination?

Are there any drawbacks with this method?
Thanks in advance,

To save pins,

You don't save any pins like this in fact you use a lot more.
What do you see as the disadvantage of the traditional arrangement?

This is an interesting idea, I dont think that I have read this one yet.

If I understand you correctly, you are talking about daisy-chaining 74hc595 8-bit shift registers, but instead of doing it the standard way with all latches tied together, you connect each 595s latch to an IO pin, so that you can latch each 8 bit chip individually, instead of all 80 bits at one time.
I dont see why you could not do that. You would need 12 pins instead of 3, so that would be a disadvantage, however there are a couple ways to further reduce that with a couple more shift registers. There are other ways besides shift registers, but since we are talking about shift registers, why not add a couple more, to control the latches. You could set them up as a separate or combined with the other shift registers.

If you want performance, then connecting Clock, Data, to all in parallel and having individual Latch is the way to go. No need to shift all the data to all the parts every - just update the one you want. Disadvantage is the need for more pins as pointed out. Adding extra shift register then reduces performance.

I think better approach would be to use SPI hardware to update the string of parts. I did some testing recently that showed 40 daisy chained parts being updated at >10KHz speed (loop took 58uS). The 40 bytes of data came from an array and was blasted out at 8 MHz SPI speed.

I can see how cascading the shift registers would dramatically reduce performance.

From my little understanding of SPI, the only thing faster than SPI is direct connection, but that limits the number of LEDs to the number of io pins.

By fast, I mean the fastest way to change all the LEDs at one time, that may not be what you need to do in every situation, but it does seem to be the most common way to do it.

If you had a situation where the bits pattern didnt change often, but which group of LEDs needed to be turned on and off individually. In that case, you could control all the latches individually with another shift register, or directly.

Just for the sake of examples its easier to reduce this from 10 to 8 shift registers (since these registers are 8 bit, not 10 bit).

It seems the total through put will always be faster with SPI, but if control is more important than performance, this might be viable.

lets say you have 64 LEDs connected to 8 shift registers, each shift registers latch is connected to a latch shift register, and each shift registers clock is connected to a clock shift register, and each shift registers data is connected to a data shift register. The data,clock,latch shift could be run from 9 pins, or maybe they could be daisy-chained the typical way, possibly using SPI.

Does having a separate shift register for clock make sense? is could controlling that independently on each chip useful?

I can only imagine that it would be difficult to program

I made an incomplete schematic. I has planned on completing it, but its pretty busy as it is, and If I put in the rest of the wires, it will obscure the drawing. So... The rest of the wiring is the standard wiring, except they are not daisy chained. I was thinking it would be nice to have a switch between each chip to switch them from chained, to not chained.

I didnt draw in the LEDs, resistors, decoupling caps, or the short between + and MR.

It seems to me there are a few more opportunities to add some shift registers.

Would it be beneficial to add a shift registers to:

MR instead of shorting it to the +, what if we used a shift register to send it high?

OE What if we used a shift register to send it low, instead of shorting it to ground?

Switching from daisy-chained, to 8 individual eight bit registers. (Q7 to DS)

It would be interesting to see what you could do with it, but I have many other things that I want to do, so I wont likely try it too soon.

I have 20 shift registers daisy chained across 2 of these boards to drive the display in this clip.

20 SPI.transfer()s are used to send the data out.
I generally see no reason to commit a pin to MR, a specific project might need that.
OE can be tied low, or connected to a PWM capable pin for LED dimming as one option.

Where seperate SS lines comes in handier is for addressing parts which contain multiple registers, such as MAX7219, so you are not forced to send the data thru numerous parts just to update 1 register in one chip.

In your drawing, having seperate Serial Data in lines and seperate Shift Register clock lines does nothing for you.
Clock the same data into all the parts at the same time - only the chip getting the Storage Register clock will have its output updated.

SPI.transfer is fast enough that you can have them all daisy chained, shift out 8 bytes, and update all at once; will turn out to be faster than doing multiple writes to send the data out, then select one of the chips via the intermediate shift register.
Keep the data in an array:

// time to update the registers?
digitalWrite(ssPin, LOW); // goes to RCLK, pin 12
for (x = 0; x<8; x=x+1){
digitalWrite(ssPin, HIGH); // outputs change on this rising edge
// done with transfer

For even faster results, replace digitalWrite with direct port manipulation

PORTD = PORTD & B11111011; // clear D2 on an Uno for example
PORTD = PORTD | B00000100; // set D2 on an Uno

Need to pay attention when porting the code to other chip types.
Can use the default SPI data rate of 4 MHz, or change the divisor to use 8 MHz! Be sure to have a power supply decoupling cap (0.1uF/100nF) on the VCC pin of each device.

If I ever get around to finishing the first 2 RGB cubes, I will need to learn all about SPI, and probably direct port manipulation. I've noticed that the charlieplexed cube uses direct port manipulation, and I need to figure that out so I can make 4 port maps based on the 4 ways you can easily connect the cube to the duino.

I have no doubt that SPI is way faster this, this is more about control, than speed. Ideally, you could change just one bit, and latch it, without effecting the others, but being able to manipulate just the 8 bits in one register at a time, while doing nothing to the others, could be useful.

Lets say, for whatever reason, you need to keep 7 shift registers just how they are, but you need to change just the 8 bits in one register, while you keep the other registers the same, and on, while you change the bits in the one register. Other times you may want to replace all 64 bits at a time. You could just do sequence your 8 bits among 8 chips, but it might be nice to be able to switch from 8 to 64 bits at a time.

Im unsure how to do the 8 daisychain on/off switches was thinking a transistor, but now I dont think that will work.

Ill try to draw up a few different schematics, when you start to think about it, you can come up with a few different ways to wire it up.

I should make a manual shift register and play with it, it might give me some ideas.

I was curious about PWM on the other pins, but it seems they should be bits, so PWM didnt seem appropriate. but I can see how it might be useful for OE or maybe even latch.

If the data is coming from an array, then you just need to update array as needed and send it out again. If the data does not change at a particular device, so what? The outputs just get loaded with the same data again. Highs stay high, Lows stay low. Don't over think it.

How about if the data comes from user or sensor input, but each sensor only relates to one shift registers outputs sometimes, but not always. A benefit of not changing the data in some registers, is that you dont have to keep track of what was there, but if you over write the data, then you could accidentally change it.

It is like trying to solve a problem, when you dont have a problem. What Im thinking is that there might be some strange circumstances where this useful. For all I know, it could turn out to be very useful for something.

Either way, you change a bit or a byte in dataArray[] when you decide to, and then update the shift register outputs - either periodically, or whenever you receive some new input.

I can see how the cascaded shift registers will have to send out a lot more bits than just the ones you may want to change.
I do still like the original idea, of controlling the latches and other pins independently. I dont imagine that it would outperform SPI, but its still may have some benefits.

I would love to see several examples built, and tested, but I dont have the time to do everything that I would like to see.

I have used both - unique SS lines to 4 MAX7219 so each could be individually addressed for updates, and cascading 20 shift registers to drive 12V LEDs. I was going to cascade the MAX7219s, but it got so messy software wise that writing to each uniquely made way more sense. Why write out 8 bytes of data when just 2 are needed for the device at the end of the chain? The tradeoff becomes using more pins & going faster, or using less pins and going slower. I'll take faster anyday.