Getting LED Bar Graph using 2 Shift Registor's

So im using 2 shift registers to try to get a LED bar graph, (green to red).

I got this so far, its not smooth, its kinda doing the green led’s first then the yellow an red after.

I need it to go from greenLed1 to greenLed2 to… greenLed8 then to yellowLed1 then to yellowLed2 then to red etc…

ledbar.ino (1.67 KB)

Code please.

Also the part number of the shift register, and some wiring information.

I attached the code to the post

Im using

Digikey 296-1600-5-ND for shift regs
Digikey 67-1451-ND segment leds
Digikey 754-1200-ND green led
Digikey 754-1203-ND yellow led
Digikey 754-1202-ND red led

and a teensy 2.0 board

this is what it currently does

People say that the SPI is much faster than using shiftIn and shiftOut. Nick Gammon's got some very good tutorials on this, you might want to check them (if you haven't done so already)

I don’t understand what the issue is.
I see leds changing every 200ms.
What should be different?

I also see what looks more like 28pin m328 part on a breadboard
vs a Teensy 2.0 board.

I don’t believe that there is any sort of speed/performance issue here.
While shiftout() code is no speed daemon and
uses the pigishly large and slow digitalWrite() code, it will be more
than fast enough to blink LEDs faster than the human eye can detect.

We will need to a schematic of how the shift registers are wired up.
How you shift out the data will depend on how you wired them up.

The loops that you have look a bit strange to me,
but then I can’t tell what was intended.

There is a loop for 12 bits, with a
The first 8 bits (k bits) are shifted out 8 times to slowly turn on all the bits 1 bit at a time.
The next 4 bits (m bits) are shifted out 4 times similar to above,
however all the bits are shifted using the same clock and data lines.
So that means that if the shift registers are chained together,
that at some point the k bits or the m bits will overlflow into the other shift register
and not display what you want.

post a full schematic of your wiring and that will help determine what needs
to be changed in order to get the effect you are looking for.

If I had to guess, you are probably chaining the shift registers.
If so, you must shift out all the k bits and all the m bits every time before you do the latch.
If that is the case, then you need to move the shiftOut() calls outside the if() statements.
i.e. something like this:

  for(int i = 0; i < 12; ++i)
    if(i <= 8){
      k = (k << 1) | 1;
      m = (m << 1) | 1;
    shiftOut(SER, SRCLK, LSBFIRST, m);
    shiftOut(SER, SRCLK, LSBFIRST, k);

— bill

CHange the shiftOuts to MSB_FIRST and see if that helps. Watching the video I got the impression that the lights were being illuminated in reverse order.

Guessing at things to try is not particularly a good way to get things done.

As soon as we know how the shift registers and LEDs are wired up, it will pretty obvious
what needs to be done.

After going back and looking at the photos, I can see the teensy (wasn't visible in the video)
and see that what I thought was a m328 dip is the two shift registers.

And looking up the digikey part numbers I can see that 595s are being used.

From looking at the pictures it appears that the green leds
are wired up to the left SR using all 8 bits with bit 0 on the left.
The yellow and red are using bits 0-3 with yellow using 0-1 and red using 2-3.

It looks like they are chained together so the Q7 bit will feed into the right SR
and then they both clock and latch together.

When chained together, in order to control all the bits all 16 bits have
to be shifted in every time.
The upper 8 bits go in first, then the lower 8 bits go in and will push the upper 8
bits over into the 2nd SR.

In this wiring, the code will definitely have to be modified from the original post.
The 595 can only shift bits up from lower bits.
Since the yellow and red leds are on the chained 595, they are the carryover bits
frorm the left SR and they are the upper bits of the 16 bit word
and must get shifted in before the green data bits.

Assuming a 1 to 1 mapping between data bits and output bits is desired
(I'd recommend this), then the 8 bit bytes should
be shifted in MSB first.

One thing in the orignal code that is a bit misleading/confusing is the macro
CLOCK_REG since it really is not actually clocking the data bits but rather latching
the SR data bits into the output register.
while, not necessary, you might consider changing the name to something like LATCH_REG?

Here are a couple of functions that could be used to update the 2 SR registers

SRupdate(uint8_t leftSRbits, uint8_t rightSRbits)
	shiftOut(SER, SRCLK, MSBFIRST, rightSRbits); // clock in the (upper) right SR 8 bits
	shiftOUT(SER, SRCLK, MSBFIRST, leftSRbits);  // clock in the (lower) left SR 8 bits
	CLOCK_REG; // latch the SR data to drive all 16 outputs in both chips

or if you want to treat as a 16 bit SR:

SRupdate(uint16_t bits)
	shiftOut(SER, SRCLK, MSBFIRST, (bits >> 8)); // clock in the (upper) right SR 8 bits
	shiftOUT(SER, SRCLK, MSBFIRST, (bits & 0xff));  // clock in the (lower) left SR 8 bits
	CLOCK_REG; // latch the SR data to drive all 16 outputs in both chips

Another thing that may come into play is noise & ground bounce.
595s are very suseptable to this.
The best thing would be to using a single pair of rails for power instead
of using both the upper and lower power rails.
And .1uf bypass caps may needed on the power lines to smooth out the power signals.

--- bill