Sharing wires for shift registers

Hi,

I want to drive 5 74HC595 shift registers from an Arduino Nano. Startup values are not that important. Due to the spatial configuration, I need a star topology around the Arduino and CANNOT put them in series.
However, I figured it might be possible to share the data and latch pin over all registers, reducing the needed pins to 5+2. The data will arive at all DS pins, but will not be saved, since the clock only runs for one register.
Of course, this would only work if the the data is copied from the shift registor to the storage. Else, a second latch HIGH would erase the storage. Is that the case?

Are there other possibilities?

I need a star topology around the Arduino and CANNOT put them in series.

But you can wire then in series even if the chips are physically arranged differently.
You can clock them separately like you said but you would need a separate latch as well. I can't see this getting you anywhere.

So what exactly does the latch do? If it COPIES the data from shift to storage, that I don't need a separate latch. Since the data in the shift register is not changes, I can just copy it over again and again.
If it is MOVED however, you are right, I would need a separate latch.

The different shift registers are independent modules and I would prefer not do introduce unnecessary dependencies.

If it COPIES the data from shift to storage, that I don't need a separate latch.

OK yes that is what it does. If you can ensure that you do not clock your shift register it should just copy the same data over.

Use 5 SPI.transfers to send the data out to the chips - even if it is not changing:

digitalWrite (ssPin, LOW);
for (x=0; x<5; x=x+1){
SPI.transfer[arrayOf5[x]);
}
digitalWrite (ssPin, HIGH); // outputs change on this rising edge - or stay the same

CrossRoads seems to be assuming you do have them in series.

There is no particular reason a star topology precludes you from chaining them, it simply means the shift out from each has to return through the hub wiring and pass out to the next input. Since there is only one load on it, it is somewhat less of a problem than the loading on the driver for the five radials of clock and latch.

If however you must access each separately, it is the latch line that is distributed separately to each. Clock and data will load each shift register with the same data, but only the one whose latch is strobed, will exhibit that data (though you could of course in this fashion, exhibit the same data to any number of latches simultaneously).

Using a 74HC14 for each of the data and clock, you can buffer five lines with one inverter feeding the other five, a separate output line for each.

Paul - while I would do it the way you suggest the OP's way would work also.

Daisy chain works with no buffers.
I have 12 daisy chained here to drive 7 segment displays made from LED strips.

Grumpy_Mike:
Paul - while I would do it the way you suggest the OP's way would work also.

It would, but it strikes me as more clumsy - the code must use different routines (or vector) to clock the different registers as it moves the data, whilst you only need to strobe once to latch the data for a chosen register.

In respect of the original enquiry,

ElCaron:
If it COPIES the data from shift to storage, that I don't need a separate latch.

Well, of course you do need a separate latch in any case since it is a shift register, and the values in that register will be moving as you shift the data in. If it is only for display purposes, that would not really matter as it would arguably be too rapid to see but if it is used for any other function, such "glitches" tend to matter.

CrossRoads:
Daisy chain works with no buffers.

Again, my interpretation of the OP is that his "spatial configuration" refers to separate PCBs with interconnects, leading to the considerations we so often discuss.

My, but this version of the forum really is crap, isn't it? The "auto-save" script is randomly messing with my spelling checker and deleting text that I have typed!

Thanks for all the replies.
If I may summarize:

  1. My version does wrk, but might cause glitches because the state of the storage might change for a short time during update, even if nothing changed. In my case, this is not important, I am switching LED configurations and the transistion doesn't matter.
  2. An improved version with the same amount of wires would be sharing clock and data with individual latches.

I thought about chaining, but in that case, it would not be possible to remove a module. I'll probably go with variant 2.

Regarding the background: I have 4 more or less independent modules on separate PCBs with 4 LEDs each. The have to be connected to the central PCB in a star topology. While it is not an absolutely necessary requirement, I would prefer a version, in which a single module can be plugged out, which kind of rules out daisy chaining.

ElCaron:

  1. My version does work, but might cause glitches because the state of the storage might change for a short time during update, even if nothing changed. In my case, this is not important, I am switching LED configurations and the transition doesn't matter.

Your version would not cause glitches using HC595s because they have the output latches and the data is only updated once you have fully shifted it in.

The ability to remove modules when necessary is an excellent reason for not chaining. I do recommend using the 74HC14 buffers as I described since it prevents any interference between modules due to wiring problems (except for shorting Vcc to ground of course).

Got the spelling check problem licked. I have managed to kill the nuisance "WSYWIG" feature.

I used to daisy chain all the displays on the scoreboards I make, but then changed to sending data to each display separately with its own latch.

I was using ribbon cable and sent data with shiftout which is fairly slow and the capacitance of the cable didn't effect it,

With short cables I used pwm for the auto dimming , but on longer cables I dimmed the power supply independently, as the switching of the LEDs could corrupt the data.

Nowadays each display ( might be 1,2 3, or 4 digits ) has its own receiver and micro, which actually works out better and cheaper than a central controller and all the data cables.