Controlling many LEDs with an arduino; two loops at once.

[Tim4444]

Hello,

I am trying to control 60 LEDs in one way and simultaneously 12 LEDs in another.  I understand that I can run two simple programmes at once using millis() functions, but does anyone know how I can run two big functions at the same time, almost like if I had two 'for' loops running simultaneously.

The idea is to make a clock where the 60 LEDs are on a loop with each LED lighting up every minute, and the other 12 (of a different colour LED) are controlled by another function causing each one to light up successively every hour.

Any help on this would be very much appreciated.

Tim

[David_AVD]

A microcontroller can only do one thing at once.  You can however use a timer interrupt to do steps of your program at regular intervals.

So, you have a timer interrupt that fires every one second.  Each time it does, you update the 60 LEDs using one function.

You also have one or more counters that get tested / incremented every second.  One of them can count the seconds and cascade to count minutes, hours, etc.

When the minute counter hits 60, you  can clear it, advance the hour counter and update the 12 LEDs using another function.

I've simplified it a little, but hopefully you get the general idea.

[psycho0815]

or you could do something like:

Code: [Select]

long start;

setup(){
  start = millis();
}

loop(){
  if(((millis()-start) % 60000) == 0){
    doMinuteStuff();
  }

   if(((millis()-start) % (60*60000)) == 0){
    doHourStuff();
  }

}

However you should know that the millis() funktion on the arduino is only somewaht acurate. For a clocl you probably want an rtc.

[dannyf]

two big functions at the same time,

First of all, unless you have a multi-core mcu, you can never truly run two "functions".

2ndly, it is tough to know what exactly you meant by "big".

The idea is to make a clock where the 60 LEDs are on a loop with each LED lighting up every minute, and the other 12 (of a different colour LED) are controlled by another function causing each one to light up successively every hour.

That's fairly easy: you need to piece of code that lights up the leds, with "time" being passed as a parameter. Anytime you call the function, it will light up the right second leds, and the right minute / hour leds.

[Tim4444]

Thanks for the replies everyone.

I think I will learn how to use the 'interrupt' function.

Does anyone know of a good on-line source to learn this from?

Tim

[MatCat]

Thanks for the replies everyone.

I think I will learn how to use the 'interrupt' function.

Does anyone know of a good on-line source to learn this from?

Tim

http://www.arduino.cc

[MacAttak]

Thanks for the replies everyone.

I think I will learn how to use the 'interrupt' function.

Does anyone know of a good on-line source to learn this from?

Tim

http://playground.arduino.cc/Code/Interrupts


edit: oops, that's what I get for walking away for dinner before posting

[Tim4444]

Thanks for the replies everyone.  I shall give the interrupts a go.

Tim

[daveatol]

The idea is to make a clock where the 60 LEDs are on a loop with each LED lighting up every minute, and the other 12 (of a different colour LED) are controlled by another function causing each one to light up successively every hour.

This doesn't require two loops, or interrupts...

[netdudeuk]

The idea is to make a clock where the 60 LEDs are on a loop with each LED lighting up every minute, and the other 12 (of a different colour LED) are controlled by another function causing each one to light up successively every hour.

This doesn't require two loops, or interrupts...

Agreed.  Psycho's answer is a good starting point.  There's no point in over complicating with an extra loop and interrupts.

[dannyf]

Psycho's answer is a good starting point.

That piece of code suffers from poor atomicity: millie() will have advanced and causing inconsistent display.

A better - not yet fully atomic - approach would be like this:

Code: [Select]

  time_now = milli(); //read the current time
  show_time(time_now); //display time

Now, millis() as well as time_now are unsigned long so the code above isn't 100% atomic. You have to institute a double read:

Code: [Select]

  do {time_now=milli();} while ((milli() & 0xffffff00ul) ^ (time_now & 0xffffff00ul));

time_now contains the correct and atomic time stamp.

The best is actually use a timer + interrupt to keep time.

[David_AVD]

The interrupt method gives a stable period between "ticks".  Using inline delays is just bad.

[daveatol]

The following code should give (long-term) accurate timing. You'll have to find out what the actual value is for TICKS_PER_SECOND, as I don't know what it's called, or its value (I assume it might be 1024 though).

Code: [Select]

long due;

setup()
{
    due = millis();
}

loop()
{   
   asm("cli");
    long now = millis();
   asm("sei");

    if(now > due)
    {
        due += TICKS_PER_SECOND * 60
       
        doMinuteStuff();       

        static uint8_t minuteCounter = 0;
        if(++minuteCounter == 60)
        {
            minuteCounter = 0;
            doHourStuff();           
        }       
    }
}

[psycho0815]

since timer0 that is used for millis() doesn't actually run at 1kHz your timing will always be a little of.
If you want actual accuracy put a 32.768kHz crystal on TOSC und set the timer2 prescaler to 128. that'll give you an interrupt exactly every second.
Or i guess you could look up what frequency timer0 actually runs at (i believe its 976Hz, but don't quote me on that) and adjust for the difference in software.

That piece of code suffers from poor atomicity: millie() will have advanced and causing inconsistent display.

wasn't supposed to be production code, just an idea to start with. However there are about 16000 clockcycles between increases of milli() and one milli() isn't actually one ms anyway, so i wonder how much that would really matter in terms of accuracy.

[dannyf]

(i believe its 976Hz,

=1k/1024.

wasn't supposed to be production code, just an idea to start with. However there are about 16000 clockcycles between increases of milli() and one milli() isn't actually one ms anyway, so i wonder how much that would really matter in terms of accuracy.

Two issues:

1) Your code can cause display inconsistency: assume that you are 6:59.9999999 -> sufficienly close to 7:00. You pick up the time and shows the minute to be 59. Then you read milli() against to process the hour. by that time, the time has advanced to 7:00 so you show the hour to be 7 -> 6:59 being displayed as 7:59.

2) millie() is 100% as accurate as the crystal. If you look at the code, the timing "errors" are accumulated so most of the time, milli() is advancing 1 per timer0 interrupt (64*256 ticks) but once in a while it will advance 2 per timer0 interrupt, in order to maintain long-term accuracy.

[mrflibble]

Quick! Someone measure the Allan deviation on those mission critical blinky leds!

 

That said, timer + interrupt as suggested would be the way to go.

[psycho0815]

1) Your code can cause display inconsistency: assume that you are 6:59.9999999 -> sufficienly close to 7:00. You pick up the time and shows the minute to be 59. Then you read milli() against to process the hour. by that time, the time has advanced to 7:00 so you show the hour to be 7 -> 6:59 being displayed as 7:59.

i acknowledge that. As i said that code was not supposed to be used as is. Just to give him an idea of how to approach the problem. He probably would've had the problems you mentioned and tried to figure it out by diving into the innards of the arduino libraries and atmega timers. You deprived him of the learning experience 

2) millie() is 100% as accurate as the crystal. If you look at the code, the timing "errors" are accumulated so most of the time, milli() is advancing 1 per timer0 interrupt (64*256 ticks) but once in a while it will advance 2 per timer0 interrupt, in order to maintain long-term accuracy.

That's my bad. i just assumed they didn't account for that. I do remember actually reading on the arduino page that the timing functions weren't that accurate. However that was quite a while back. Totally possible taht they fixed it since then or my memory is wrong to begin with.

[Jeroen3]

Buy a Real Time Clock IC and use it. Most RTC's can also give you a interval interrupt.

If you use a hardware timer for this you must use an 32 KHz oscillator, higher crystals or even the internal osc will give you seconds off every day.

[dannyf]

If you use a hardware timer for this you must use an 32 KHz oscillator, higher crystals or even the internal osc will give you seconds off every day.

I disagree, other than the internal osc part.

[netdudeuk]

Psycho's answer is a good starting point.

That piece of code suffers from poor atomicity: millie() will have advanced and causing inconsistent display.

A better - not yet fully atomic - approach would be like this:

Code: [Select]

  time_now = milli(); //read the current time
  show_time(time_now); //display time

Now, millis() as well as time_now are unsigned long so the code above isn't 100% atomic. You have to institute a double read:

Code: [Select]

  do {time_now=milli();} while ((milli() & 0xffffff00ul) ^ (time_now & 0xffffff00ul));

time_now contains the correct and atomic time stamp.

The best is actually use a timer + interrupt to keep time.

I said it was a good starting point.  The issue you mention could be handled easily by just reading the info into a variable and then referring to that in the tests.

Why doesn't he just buy a DS1307 from eBay ?  Mine cost less than £2 delivered and they come with what could be a handy 32K I2E EEPROM as well.

As it's just a simple clock application, he can do this with a simple loop (in loop(), funnily enough  ) and would still get reasonable accuracy without needing to use interrupts.

[dannyf]

The issue you mention could be handled easily by just reading the info into a variable and then referring to that in the tests.

No.

Why doesn't he just buy a DS1307 from eBay ? 

Simplicity? Why buy something you don't need?

As it's just a simple clock application, he can do this with a simple loop (in loop(), funnily enough  ) and would still get reasonable accuracy without needing to use interrupts.

He could. But he can do better with less.

[mrflibble]

While you guys are discussing the finer points of "how many different ways are there to blink a led in a timely fashion", the OP is probably sitting in a bar somewhere. Possibly even discussing his already working led blinky project.

[MatCat]

ROFL you don't NEED an RTC to blink an LED, it's not like this project is being used by NASA to transmit data over light with sub-uS accuracy in timing...  I am surprised someone didn't mention using a 555 by now!

[David_AVD]

Ummm... well the OP is building a clock !

[MatCat]

Ummm... well the OP is building a clock !

ROFL I did not notice it was actually a clock, I just saw LED's, well then in that case I do recommend an RTC hehe.

[scientist]

Use a few shift registers and only shift out data when the clock changes?