595 + 7seg - Works half the time

Hi all,

I have a weird problem I cannot seem to debug.

When I run through 0-9 on my 7seg, it displays the number fine - but on the next iteration it has all the LEDs lit up. The following iteration it will then display the next number.

If I watch it for long enough sometimes it gets through 0-9 without a problem, but after reaching 9 and beginning again - it will run oddly again.

It will run like: 0, *, 2, *, 4, *, 6, *, 8, *, 0, *

Then if I change the delay slightly, I'll get: *, 1, *, 3, *, 5, *, 7, *, 9, *, 1

(* is key for the 7seg being fully lit - decimal point and all)

Got a very basic 595 + 7seg common anode.

595 has clock/latch/data pins hooked up and working.

595 pins Q0 - 7 hook up to 7seg through resistors

Code is also about as simple as it gets. I've tried the hex values as well as the corresponding binary digits just in case.

#define LATCH 6
#define CLK 4
#define DATA 2

byte digitsHex[]= {0x3F, 0x06, 0x5B, 0x4F, 0x66, 0x6D, 0x7D, 0x07, 0x7F, 0x67};

byte digitsBits[] = 
{
  B00111111,  // 0
  B00000110,  // 1
  B01011011,  // 2
  B01001111,  // 3
  B01100110,  // 4
  B01101101,  // 5
  B01111101,  // 6
  B00000111,  // 7
  B01111111,  // 8
  B01100111
};

int i;

void setup(){
  pinMode(LATCH, OUTPUT);
  pinMode(CLK, OUTPUT);
  pinMode(DATA, OUTPUT);  
}

void loop(){
  numberLoopTest();
}

void numberLoopTest()
{
  for(int i=0; i<10; i++){

    digitalWrite(LATCH, LOW);
    shiftOut(DATA, CLK, MSBFIRST, ~digitsBits[i]);
    digitalWrite(LATCH, HIGH);

    delay(500);
  }
}

Does anyone have any idea why it would be behaving erratically like this?

I'm about to pull my hair out :astonished:

I think you need digitalWrite(CLK, LOW); just before the shiftOut.

Hmmm dang that doesn't appear to change the output.

What makes even less sense, is if I remove the for loop and just try and print one number - it still jumps between the correct number and (ALL_ON)

eg

void numberLoopTest()
{
  digitalWrite(LATCH, LOW);
  shiftOut(DATA, CLK, MSBFIRST, ~B01100110);
  digitalWrite(LATCH, HIGH);
  delay(500);
}

It jumps between 4 (correct) and * (ALL ON).

Exactly how is it wired up? Could you post a drawing or a photo? Not a link to how it should be!

Sure!

I've taken a pic of the breadboard - I haven't got any plans as such. The second 595 is not hooked up.

Basically:

Breadboard (+)ive = Arduino VCC
Breadboard (-)ive = Arduino GND

595 Pin 16 = VCC
595 Pin 13 = GND
595 Pin 1-7 (q1-q7) = digit pins on 7seg
595 Pin 15 (q0) = digit pins on 7seg
595 Pins 11, 12, 14 = arduino pins 6, 4, 2

7seg Pin 14 = VCC+

I can't see a ground connection to pin 8 of the '595?

Hmmm.. I also thought that had to be connected to ground - but when I do, it simply shows all the leds fully lit and doesn't even switch to the number I set.

If I unplug that pin 8 while it's on - it goes back to working 50%. With it plugged in - it works 0%.

bryanpaddock:
Hmmm.. I also thought that had to be connected to ground - but when I do, it simply shows all the leds fully lit and doesn't even switch to the number I set.

If I unplug that pin 8 while it's on - it goes back to working 50%. With it plugged in - it works 0%.

Without a ground connection you are using the chip in a configuration that isn't documented. If it isn't documented then any results you get are also, undocumented. So if you get any usable results at all, it's a bonus.

The reason that your LEDS come on when it's first connected has nothing to do with it "working" or not. It's simply because you're using common Anode display (instead of common cathode). So the default LOW on the output pins, supplies power to each segment. This is normal behaviour of the IC.

BTW I think you have your LATCH and Clock pins around the wrong way. If you try switching them it may start to work BUT you MUST have that ground pin connected.

Hi, please have you got a circuit diagram drawn.
If not then draw one and post it so we can see how you have it connected.
Please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png or pdf?

Tom...... :slight_smile:

Thanks for the info on the ground - it is connected now. Even though I now get no numbers at all.

KenF:
BTW I think you have your LATCH and Clock pins around the wrong way. If you try switching them it may start to work BUT you MUST have that ground pin connected.

Hmmm - Tried swopping them around and no avail.

TomGeorge:
Hi, please have you got a circuit diagram drawn.
If not then draw one and post it so we can see how you have it connected.
Please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png or pdf?

Tom...... :slight_smile:

Sure! - I've created a fritzing sketch of the current layout - hopefully that can shed some light.

You have pin 10 of the 595 floating? I think this should be connected to 5v

You're my HERO!

As soon as I connected that up the numbers starting flowing....

Thanks Ken

Ahh - so the Master Reclear pin being set low was telling the 595 it doesn't have to refresh the display hence it displaying the "start screen" of all led's being lit....?

is it possible to replace delay(500) using millis() using bryanpaddock codes ??
anyone helpf for this please

bryanpaddock:
Ahh - so the Master Reclear pin being set low was telling the 595 it doesn't have to refresh the display hence it displaying the "start screen" of all led's being lit....?

Actually, I believe if you turn everything off and on again, you'll still get that result. As I mentioned in answer #7 By default all the outputs will be LOW. So your common anodes will all get turned on by this situation.

So your display uses counter intuitive logic. A high on the output turns OFF the segment and a LOW turns it ON.

Your sketch even makes allowance for this by use of the tilde symbol (~) in your shiftOut command.

is it possible to replace delay(500) using millis() using bryanpaddock codes ??
anyone helpf for this please

hey guys
is it possible to replace delay(500) using millis() using bryanpaddock codes ??
anyone helpf for this please

Ah! Makes sense now.

When I re-power it now the initial screen is half-garbled and then it goes onto work correctly. Fine with that.

I couldn't for the life of me figure out why I was having to use NOT to get it to work. If I send the bits as-is its a no-go.

bryanpaddock:
Ah! Makes sense now.

When I re-power it now the initial screen is half-garbled and then it goes onto work correctly. Fine with that.

I couldn't for the life of me figure out why I was having to use NOT to get it to work. If I send the bits as-is its a no-go.

If you really wanted to prevent the display of the garbled output, you could connect the OE of the chip to a separate I/O pin on the UNO. Then shiftOut something valid, before finally setting that I/O pin to output and sending it low.

But like you say, if it gets written to immediately, it hardly seems worth the effort. Although, dependent on your final application, it could be handy to have a method of turning the display off at any time. (simply by sending OE high).

For reliable operation, you should add a decoupling capacitor to each 74HC595.