Psuedo Random 4 LED twinkler

Hi there, First time posting a project up here.

I have designed and coded a circuit for the ATTiny85 that Randomly blinks at random durations 1 of 4 LEDs.
I am only using 2 of the 6 pins available on the chip by using the Tri state function of the GPIO pins.
(in plain English, I made the two pins do 3 different things, Sink, source, and Open (or HI-Z))

I programmed everything with the MIT method using an Uno as an ICSP.
The relevant part of this project is the code. I'm not sure if anyone has posted anything similar but I pretty much did this without much reference to anything else.

here is the code.

/*
Code by Nick Tracy 2013
 May contain code parts from other programs, all credit goes to those who helped. 
 Designed around the ATTiny85 @ 8 Mhz with internal oscillator, accuracy is not important here and is actually beneficial. 
 This code uses a random number generator to simulate a twinkling effect on 4 different outputs.
 Used in a decoration for the holidays, can be used for just about anything really.
 it uses 4 LEDs connected to 2 pins (3 and 4 for ATTiny85) that are Tri-stated to provide a HIGH, LOW, and High Impedance output.
 the LEDs are connected in a sink/source set up on each pin. when the pin mode is changed to the third state the LEDs on that pin are off.
 */

//Use Define so that not a lot of memory is wasted.
#define LED1 3
#define LED2 4
//long for random number variables
long rand1;
long rand2;
long rand3;

void setup() {                
  pinMode(LED1, INPUT_PULLUP);
  pinMode(LED2, INPUT_PULLUP);
  //Generate Random numbers seed
  randomSeed(12345612);  
}
void loop() {
  rand1 = random(1,5); //Used for selecting which LED to fire.
  rand2 = random(5,20); //Used to determine delay for On.
  rand3 = random(50,300); //Used to determine delay for Off.

  //Switch case for selecting the appropriate LED
  //Fires one Random LED at a time each loop at a random duration On and Off.
  switch (rand1){
  case 1:

    pinMode(LED1, OUTPUT); //set pin mode to output
    pinMode(LED2, INPUT_PULLUP); //makes sure other output is off
    digitalWrite(LED1, HIGH); //turn on led number 1 of 4
    delay(rand2); //delay for On duration
    pinMode(LED1, INPUT_PULLUP); //turn off the output
    delay(rand3); //delay before next cycle
    break;

  case 2:

    pinMode(LED1, OUTPUT); //set pin mode to output
    pinMode(LED2, INPUT_PULLUP); //makes sure other output is off
    digitalWrite(LED1, LOW); //turn on led number 2 of 4
    delay(rand2); //delay for On duration
    pinMode(LED1, INPUT_PULLUP); //turn off the output
    delay(rand3); //delay before next cycle
    break;

  case 3:

    pinMode(LED2, OUTPUT); //set pin mode to output
    pinMode(LED1, INPUT_PULLUP); //makes sure other output is off
    digitalWrite(LED2, HIGH); //turn on led number 3 of 4
    delay(rand2); //delay for On duration
    pinMode(LED2, INPUT_PULLUP); //turn off the output
    delay(rand3); //delay before next cycle    
    break;

  case 4:

    pinMode(LED2, OUTPUT); //set pin mode to output
    pinMode(LED1, INPUT_PULLUP); //makes sure other output is off
    digitalWrite(LED2, LOW); //turn on led number 4 of 4
    delay(rand2); //delay for On duration
    pinMode(LED2, INPUT_PULLUP); //turn off the output
    delay(rand3); //delay before next cycle    
    break;

  default:
    //If no LED is selected, turn off all LEDs for a random amount of time.
    pinMode(LED1, INPUT_PULLUP);
    pinMode(LED2, INPUT_PULLUP);
    delay(rand2);
  }
}

EDIT: The LEDs I used were White with a 3.2v drop and 20ma draw. but with different resistor values you can use any LED so long as you choose the correct current limiting resistor for your LED.

My only issue here is that two of the LEDs are dimly lit in the HI-Z state due to the internal pull up resistors. there is just enough current to light the LEDs I'm using. if anyone has a recommendation for that let me know.

if anyone has a recommendation for that let me know.

Schematic?

Here it is, If i had a good camera I would upload a video to youtube.

EDIT: added more traditional schematic as well.
EDIT EDIT: Removed schematic due to error in wiring.
EDIT to the EDIT that I EDITED: New Fritzing diagrams with correct wiring. sorry

P.S. I'm refusing to use fritzing anymore, what a terrible program. going back to hand drawing.

This method could be used to expand the amount of leds. Just duplicate this to each pin and change the code accordingly by adding new case switch statements and changing the max number for the random function.

Uh, how do you light any of the LEDs? For example LED2 and LED4 have the cathodes connected to Vcc. No matter what you do with pin 4 (physical pin 3) neither of those LEDs is going to conduct.

Sorry I'm new to fritzing and wasn't paying attention to that, I was more concerned with getting the traces to look nice and kinda threw that up in a hurry.

on my breadboard they are hooked up correctly.

How about a schematic that fits on the screen?

fungus:
How about a schematic that fits on the screen?

You can easily view the image by right clicking it and clicking "view image" it will open the full image in a new window. I won't change the resolution of the image because it may lower the quality, not my fault the arduino forum can't properly handle image attachments like every other forum software out there.

and why is there so much interest in the schematic? there isn't anything there besides 2 pins and 4 leds with resistors. the main focus of this project was the code.

its as simple as connecting it like this

| ATtiny85 |
Physical pin 2---------(a)LED1(c)-------100ohm--------Common -
Physical pin 2---------(c)LED2(a)-------100ohm--------Positive 5v
Physical pin 3---------(a)LED3(c)-------100ohm--------Common -
Physical pin 3---------(c)LED4(a)-------100ohm--------Positive 5v
4 to ground
8 to Vcc 5v
very simple.

SargentSeven:
and why is there so much interest in the schematic?

Two reasons...

  1. I assumed you are wiring the LEDs the way you are in fact wiring them. If the forward voltage was close to 2.5V it could explain the symptom. In your first post you failed to mention the fact that you are using white / forward voltage = 3.2V LEDs. By asking for the schematic I can validate my assumption and confirm the forward voltage is high enough for the circuit to work.

  2. Anyone new to Arduinos / electronics who wants to build a similar device is going to have trouble without a schematic. In addition, they would be rather disappointed if they had used red LEDs instead of white. By providing details you are helping future adventurers.

Now, back to the dim LEDs...

SargentSeven:
My only issue here is that two of the LEDs are dimly lit in the HI-Z state due to the internal pull up resistors. there is just enough current to light the LEDs I'm using. if anyone has a recommendation for that let me know.

Change INPUT_PULLUP to INPUT. All lines like this...

pinMode(LED2, INPUT_PULLUP); //makes sure other output is off

...become this...

pinMode(LED2, INPUT); //makes sure other output is off

The reason I used the internal pullup resistors is because i had read that with any CMOS chip, if you leave an input pin floating in this circuit, you could damage the chip. is this not true for the AVR chips?

here is my source for this information, in the comment section someone brought up this point about using internal pullups to prevent burning up the pins. http://www.neufeld.newton.ks.us/electronics/?p=151

I tried this with other LEDs besides red and i can confirm that it will work with most leds, for the red all i had to do was change the resistor to 150ohm and it worked the same.

I apologize, i kind of assumed that LEDs and current limiting resistors were pretty entry level knowledge. if someone is trying to get into this project and doesn't know at least that much then they should be starting on something simpler IMO.

This appears to be a good description of the problem...

I'm too lazy to read it thoroughly but from a cursory glance I gather the problem has to do with overheating caused by an input floating in the linear region of the transistor or from excessive switching. Neither of those is a problem for an AVR processor. Switching does burn energy but nowhere near enough to cause overheating problems.

In other words, floating inputs are most certainly not a problem for AVR processors. That's how they are initialized after a reset or power-up.

SargentSeven:
here is my source for this information, in the comment section someone brought up this point about using internal pullups to prevent burning up the pins. http://www.neufeld.newton.ks.us/electronics/?p=151

Well, it's on the internet so it must be true. :wink:

If this i the case then this would solve that problem. I have a bunch of these so I will test it out over a period of time to see if there are any issues.

Moderator edit: changed the strikeout to underscore

more like "the guy brought up a valid point so it must need some consideration."

looking over that article you posted in the first introductory paragraph I can see where he got that idea from.

"both CMOS and BiCMOS families have a CMOS input structure. This structure is an inverter consisting of a p-channel to V
CC and an n-channel to GND. With low-level input, the p-channel transistor is on and the n-channel is off,
causing current to flow from VCC and pulling the node to a high state. With high-level input, the n-channel transistor is on,
the p-channel is off, and the current flows to GND, pulling the node low. In both cases, no current flows from VCC
to GND.
However, when switching from one state to another," (or in my case, floating between states) "the input crosses the threshold region, causing the n-channel and the
p-channel to turn on simultaneously, generating a current path between VCC
and GND. This current surge can be damaging,
depending on the length of time that the input is in the threshold region (0.8 to 2 V). The supply current can rise to several
milliamperes per input..."

but then it also states below

"...This is not a problem when switching states within
the data-sheet-specified input transition time limit specified in the recommended operating conditions table for the specific
devices."

So I'm assuming that you would not consider the floating pin on the AVR to be in the threshold region of the gates? does it matter if its switching or not during that time?
this is all kind of just above my experience level, the internet is my only source as well. misinformation needs to be corrected.

SargentSeven:

[quote author=Coding Badly link=topic=207022.msg1523922#msg1523922 date=1388272583]
Well, it's on the internet so it must be true. :wink:

more like "the guy brought up a valid point so it must need some consideration."[/quote]

It is not a valid point. The guy is an idiot. A little basic logic proves my point: Hundreds of millions of AVR processors have been sold (billions of similar products). For all AVR processors (and the vast majority of other products) the inputs are set to high impedance / floating after a reset / power-up. If floating inputs for microcontrollers were a problem a large percent would have cooked when first powered and Atmel, Microchip, Intel, and a long list of other companies would be out of business.

SargentSeven:
this is all kind of just above my experience level, the internet is my only source as well. misinformation needs to be corrected.

Incorrect. The internet-at-large is not your only source of information. Atmel's website is a far better place to look for answers...
https://www.google.com/search?q=atmega328+datasheet

SargentSeven:
So I'm assuming that you would not consider the floating pin on the AVR to be in the threshold region of the gates? does it matter if its switching or not during that time?

Makes no difference. The processor is perfectly stable with floating inputs.