Silly parallel 74HC595 problem

Hello, I'm using two 74HC595 serial to parallel shift registers to light up 8 bi-colour LEDS - red and green. I have the CLOCK and LATCH pins wired together to work in parallel but separate DATA pins for each so that one controls the red part and the other green.

The problem is when I shiftOut on the second 74HC595 to set the other colour, it affects the first colour. Here's the code:

  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);
  pinMode(dataPinG, OUTPUT);
  pinMode(dataPinR, OUTPUT);
  digitalWrite(latchPin, LOW);
  shiftOut(dataPinR, clockPin, MSBFIRST, 192);//Last two red
  shiftOut(dataPinG, clockPin, MSBFIRST, 3);//First two green
  digitalWrite(latchPin, HIGH);

A solution is to wire up the OUTPUT_ENABLE pins to stop one from updating, but does anyone have a software solution? Thanks.

Please follow the advice given in the link below when posting code, in particular the section entitled 'Posting code and common code problems'

Use code tags (the </> icon above the compose window) to make it easier to read and copy for examination

Decoupling caps on the 595s?
Current limiting resistors on the LEDs?
Sufficient current for all the components being used.

Just thinking there may be some noise getting onto the supply, causing invalid data in the shift……

Your code and your wiring work exact the way they are expected to work.

If you have wired the clock-signal and the latch-signal of both shiftregisters together they obey your signals:

shift-in with each clock-pulse (if you have level LOW on the other shifregister datain-pin you are "clocking in zeros" if you have HIGH on the other shiftregister you are clocking in 1's
and with the latch-signal store shifted in bits into outputregister.

My solution would be to cascade the two shiftregisters and always shiftout 16 bits.
The shiftout-function takes two different byte-variables and shifts up the first 8 bits into an integervariable then adds the second 8 bits

shift in the 8 upper bits into integer
1111 1111 0000 0000

add lower 8 bits
1111 1111 1111 1111

shiftout 16 bits to cascaded shiftregisters

For cascading you connect the Qh' output to the serial datain-pin of the second shiftregister

in the datasheet the serial-out pin is named "Serial Data Output"
If this is not fast enough you have to unreveal your project and give an overview about your project

best regards Stefan

Hi, @uhf_123
Welcome to the forum.

Can you please post your code, using the link in post #2 ?
Can you please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png?

Thanks.. Tom.. :smiley: :+1: :coffee: :australia:

The software solution is to not use shiftOut() but to write your own code to put data on both data pins before pulsing the clock pin. You can use the AVR 'shiftout()' function as a start:

void shiftOut(uint8_t dataPin, uint8_t clockPin, uint8_t bitOrder, uint8_t val)
	uint8_t i;

	for (i = 0; i < 8; i++)  {
		if (bitOrder == LSBFIRST) {
			digitalWrite(dataPin, val & 1);
			val >>= 1;
		} else {	
			digitalWrite(dataPin, (val & 128) != 0);
			val <<= 1;
		digitalWrite(clockPin, HIGH);
		digitalWrite(clockPin, LOW);		

Hello many thanks for the replies. I should have mentioned that it's all on PCB already. I'll go with writing my own shiftOut() to do both. I'll attach an MCU pin to the OUTPUT_ENABLE in the next iteration. That's why PCBs have bodge wire for moments like this!

Not wise. The daisy chain configuration is simpler, better. That is what you will see in all commercial devices.

1 Like

Actually yes, that would be fine. I have three 74HC165s being used to read encoders and their switches, which are in parallel. No reason to do the same with the LEDs. Thanks

Have you prototyped your project before going to PCB?

Tom... :smiley: :+1: :coffee: :australia:

Aha. There are some specialised chips for purposes like this:
SX1508 SX1509

which make it easier to connect a keypad-matrix.
Additionally the SX1508 can drive LEDs including brightness-control

Or the MCP23017

The SX1508 / MCP23017 also includes an interrupt-pin which means connecting this pin to an interrupt-capable IO-pin of the microcontroller to catch events on the chips inputs with interrupts.

best regards Stefan

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.