[Finally Solved !] 3 daisy chained 74HC595s but first takes priority over the others (long topic)

I have 3 daisy-chained 74HC595 Shift Registers with 8 RGB LEDs to program a Light Bar.
So, my project has 1 Shift Register per color.

Problem : The Shift for Red color seems to be the "Master" (it's the one directly connected to my Arduino UNO board), it means that when I put a red color on an output, the others are completely off !
I use Bellavance's HC595 Library. Before, I used Timo Denk's ShiftRegisterPWM and ShiftRegister74HC595 libraries, which lead to the same problem.

#include <HC595.h>

const int chipCount = 3;
int data = 2;
int clock = 3;
int latch = 4;

HC595 leds(chipCount, latch, clock, data);

int last = leds.lastPin();

void setup(){
  /*
  pinMode(data, OUTPUT);
  pinMode(clock, OUTPUT);
  pinMode(latch, OUTPUT);*/
  leds.reset();
  leds.setPins(8, 23, HIGH); //0 to 7 are Red color. They seem to turn off green (8 to 15) and blue (16 to 23)
}

void loop(){
  //Tried leds.setPins here but does nothing to the problem.
}

With the SifhtRegisterPWM Library, I put 128 to Red with 255 to Green and Blue, the RGBs are white ! But not with the 2 others, which don't use PWM.

schematic?

You have to combine the red value with the other colour values,
to get the red on.

Or move each shift register to it's own latch pin. :smiley:

const int SerDataPin = 2;
const int SerClockPin = 3;
const int SerLatchPin = 4;

void setup() {
  pinMode(SerDataPin, OUTPUT);
  pinMode(SerClockPin, OUTPUT);
  pinMode(SerLatchPin, OUTPUT);
}

void loop() {
  SendByte(0xFF);
  SendByte(0x00);
  SendByte(0x00);
  digitalWrite(SerLatchPin, HIGH);
  digitalWrite(SerLatchPin, LOW);
  delay(1000);
  SendByte(0x00);
  SendByte(0xFF);
  SendByte(0x00);
  digitalWrite(SerLatchPin, HIGH);
  digitalWrite(SerLatchPin, LOW);
  delay(1000);
  SendByte(0x00);
  SendByte(0x00);
  SendByte(0xFF);
  digitalWrite(SerLatchPin, HIGH);
  digitalWrite(SerLatchPin, LOW);
  delay(1000);
}

void SendByte(byte Data) {
  for (byte i = 0; i < 8; i++) {
    digitalWrite(SerDataPin, Data & (1 << i));
    digitalWrite(SerClockPin, HIGH);
    digitalWrite(SerClockPin, LOW);
  }
}

Uhh what ? If I do setPins(0, 23), only the red is on.

It will be considered as not daisy chained (I think)

pls something like this

ah, i see, should work if connections not faulty.

It's working without any delay (Yes, I will add later a IR Receiver and the Arduino Code uses a delay not to get immediate repeat)

do you see colors other as red?
and of coarse you can add delays or whatever you want.

Yes

  SendByte(0xFF);
  SendByte(0x00);
  SendByte(0x00);
  digitalWrite(SerLatchPin, HIGH);
  digitalWrite(SerLatchPin, LOW);
  delay(500); //Placing here displays blue

  SendByte(0x00);
  SendByte(0xFF);
  SendByte(0x00);
  digitalWrite(SerLatchPin, HIGH);
  digitalWrite(SerLatchPin, LOW);
  delay(500); //Placing here displays green

you're welcome

Yes, because all the other shift registers are turned off.

That is why I suggested giving them individual latch pins,
so only one colour shift register would be selected at a time.

Is the problem solved?

How can they be turned off if they have the same latch as the first shift ?

Uhh yes, but not completely in my sense, because as I said before, i will add an IR Receiver.
Placing a delay after all the SendByte functions in code of @kolaha in a translateIR function will display red.

Because modifying the first register value will modify the others.

you has functional device and if you see only red then wrong is the sketch. show full sketh.

yes, for change of one single bit must all of 3 bytes new shifted.

So if I understand all :

  • One latch per Shift (maybe per SendByte call too ?)
  • Data and Clock wiring will not move

That's what shiftOut function is doing, no ? :thinking:

There are several problems with your circuit. (What you posted is not a schematic, by the way.)

It would be so much simpler to use 8 apa106 LEDs. And the result would be superior.

One individual latch pin per individual shift register, and no data and clock will not have to move.

This would be a lot more advised.
Why didn't I think of that? :wink:

Perhaps you are having more of an eccentric day than a genius day today :wink:

No one on the topic seems to have figured out why the blue and green LEDs go out when the red LEDs are on. I think the answer might be right there in @dj_math 's diagram.