I have set up the hardware as instructed online, with the 8 outputs on the chip in series with a resistor and one segment of a seven segment display (essentially just 8 leds). However, when i try to code the output, I am getting unexpected results.
int dataPin = 9;
int latchPin = 10;
int clockPin = 13;
void setup() {
//set pins to output so you can control the shift register
pinMode(latchPin, OUTPUT);
pinMode(clockPin, OUTPUT);
pinMode(dataPin, OUTPUT);
}
void loop() {
// count from 0 to 255 and display the number
// on the LEDs
for (int numberToDisplay = 0; numberToDisplay < 10; numberToDisplay++) {
// take the latchPin low so the LEDs don't change while you're sending in bits:
digitalWrite(latchPin, LOW);
// shift out the bits:
shiftOut(dataPin, clockPin, MSBFIRST, numberToDisplay);
//take the latch pin high so the LEDs will light up:
digitalWrite(latchPin, HIGH);
// pause before next value:
delay(1000);
}
delay(800);
}
I realize this code should not make decimal numbers appear on the display, but shouldn't it at least make a pattern of 10 repeating configurations? All it does is create seemingly random things. It will sometimes turn off for a min only to start lighting up again. Sometimes all 8 will light up as if i outputted 255. Often it falls into a pattern of just a repeating pattern of two configurations instead of ten!
I even tried running code that just repeatedly outputted the same byte to the chip, yet varying lights lit up with each output. Is it a faulty chip? Very confused. Thanks in advance.
Go and read the instructions on how to post here, then go back and modify your post (use the "More --> Modify" option to the bottom right of the post) to mark up the code as such so we can examine it conveniently and accurately.
Albeit it is not too complex at present, but it may well get more so.
OK, one minor detail to start with:
RobRedEyes:
// take the latchPin low so the LEDs don't change while you're sending in bits:
digitalWrite(latchPin, LOW);
Turns out that comment is wrong, at least if you are using a 74HC595 or TPIC6B595. They are edge-triggered, so output data will not change as you shift data through. This instruction could quite correctly have come immediately before
Your problem appears to be that you are sending a number in the range 0 to 9 to the shift register and expecting the leds to light up showing "0" to "9". Unfortunately its not quite that simple. Some led driver chips like max7219 will do that for you, but a simple shift register is not that clever.
What you need to do is, for example, translate the number "3" into the pattern of segments that make the shape of "3", so that 6 are lit and those 2 segments on the left are off. You need to figure out, for each number, which segments should be on and which off. You then make binary codes which represent each digit. When you have done that you can translate any number you want to display into that binary code and send that to the shift register.
RobRedEyes:
I realize this code should not make decimal numbers appear on the display, but shouldn't it at least make a pattern of 10 repeating configurations? All it does is create seemingly random things. It will sometimes turn off for a min only to start lighting up again. Sometimes all 8 will light up as if i outputted 255. Often it falls into a pattern of just a repeating pattern of two configurations instead of ten!
I await his reply.
If he actually returns, and marks up the code nicely, I will look at it more closely.
Mind you I have not used, and am thus not familiar with "shiftOut".
{That description BTW, sounds like either a loop out of bounds, or a hardware problem.}
Thanks for the reply, but unfortunately that is not my problem. I realize that shifting out the numbers 0 to 9 should not literally make the decimal numbers 0 to 9 appear, but it is my understanding that it should make a pattern of 10 repeating configurations. Nothing like this occurs. Instead, I get seemingly random results.
To further emphasize what I mean: even when i try shifting out the same number repeatedly, i get changing configurations instead of one constant configuration.
Post your wiring diagram/schematic. Your code looks good - I expect some hardware issue: no 0.1uF (100nF) decoupling cap on the Vcc pin, MSCLR not tied high, OE/ not tied low, no current limit resistors, 0.1uF cap across the control signals.
@Paul, what purpose do the caps serve? And how important are they (I dont think I have any available caps atm except for some ones with an unknown capacitance)
The 0.1uf near the chip's power pins is what's known as "decoupling" or "bypass". As circuits inside the chip switch on/off, there can be spikes in the demand for current. These spikes can theoretically affect other parts of the same chip, or other chips in the circuit, causing them to function in unexpected ways. The cap provides a nearby reservoir of charge to prevent those spikes causing problems.
You might very well get away without them, but is is good practice to always put them in, so you can avoid wasting your own time or those trying to help you, because hours and days can so easily be lost trying to find the cause of some bizzare problem in a circuit that doesn't have decoupling caps.
For example, I recently programmed a tiny85 with the standard "blink" sketch. The program upload went ok but it went absolutely loopy when the sketch began to run, flashing at different rates, speeding up, slowing down and stopping apparently at random. I had forgotten the bypass cap! As soon as I added it, the tiny started behaving normally.
The larger cap helps smooth out the larger and longer term changes in current due to switching leds on and off.
