Wiring a basic LED clock into the Arduino to use for calculations?

Ok I know this is a bit different than most people wanting to make a clock using their arduino... Anyway my arduino is used to control all the various pieces of equipment in my car audio installation. It also is patched into a Nokia 5110 LCD to show me what it's doing, and when in idle it shows me the ambient/outdoor temperature. What I would like to do is wire in an off the shelf LED clock so I can then display the time on the Nokia 5110 screen during idle. I don't believe the arduino has the resources to keep accurate time along with the other tasks...

Anyone done this? Any idea how many pins it would take to interpret what the clock would send the display and then convert that into usable information for displaying on the attached LCD?

It may be possible to add a load of shiftregisters to read all segments of your clock using 3 pins.

Buying an rtc-chip like the DS1307 is probably much simpler and cheaper though.

What kind of output would the chip give me? Problem is I use alot of delay commands in my loop.. so it would be difficult to keep accurate time by querying something that required feedback.

By using the time-library, arduino creates a clock in software based on internal timers. It will keep running if you use delays or not. It is indeed less accurate as the clock in the RTC-chip and needs resetting quite often.

Reading the RTC-chip and synchronizing the software-clock requires just a few milliseconds though and by adding a routine that synchronizes clocks every x minutes, your display will show the correct time.

This chip uses I2C, it wouldn't require any pins if you already use arduinos I2C-bus, or just 2 pins if you haven't.
I'm recommending the 1307 since it is used very much in arduino-projects, you can find a lot of examples for it, but other types of RTC-chips are available as well.

A DS3231 may... be interesting as well. The 1307 is a standard RTC which may still be a minute fast/slow each month.
The DS3231 is compatible with the DS1307 and accurate up to a minute a year.

The DS3231 is a great suggestion. Looks pretty straight forward coding wise.. I think this will be the best avenue to go.

Thanks!

Why are you using "Delay()" routines in a real-time application?

The main purpose of the arduino I'm looking to add-on to is for delay. It has a 4ch mosfet board attached and I read input from a constant and momentary feed. Then I calculate if my equipment should be turned on or off and in what order with delay between. I use the LCD to show what's happening.

I'm not sure what type of delay you need and how you use it, but the delay()-function, although easy to use, indeed isn't one of the best functions.

While waiting using delay(), arduino is more or less dead, It won't notice that you push a button, it won't update your LCD, read sensors etc until the delay is finished...

You can also set timers and check those periodically in your loop. If it isn't time yet..., you could check for keypresses, synchronize clocks, update your screen etc. Once the check is true, your program could do what is needed after waiting for a certain time.

If you check the difference between the blink- and blink without delay()-examples, you can see how you can use your arduino more efficiently without delays.

Simpson_Jr:
I'm not sure what type of delay you need and how you use it, but the delay()-function, although easy to use, indeed isn't one of the best functions.

While waiting using delay(), arduino is more or less dead, It won't notice that you push a button, it won't update your LCD, read sensors etc until the delay is finished...

You can also set timers and check those periodically in your loop. If it isn't time yet..., you could check for keypresses, synchronize clocks, update your screen etc. Once the check is true, your program could do what is needed after waiting for a certain time.

If you check the difference between the blink- and blink without delay()-examples, you can see how you can use your arduino more efficiently without delays.

Thanks for the tip. I discovered what you are referring to already when I wanted to cancel or abort a process it could only happen after the delay was over. So I wrote a quick function that loops through a delay(100) but each time checking for an input status change. That way if something changed during a delay it would abort.

BowDown:
So I wrote a quick function that loops through a delay(100) but each time checking for an input status change. That way if something changed during a delay it would abort.

So now, if you want your code to be genuinely flexible and adaptable/ extensible, you need to comprehend the concept of the "Blink without Delay" where instead of looping and delaying whilst checking for events, you loop and check for both external events and expiry of the delays you have set according to an anticipated value of the millis() timer.

This importantly allows you to perform any number of simultaneous delays and input checks. It also tends to make delays more precise since the millis() counter continues to keep time whilst other functions - such as updating an LCD - which may take a certain amount of time to execute, divert the program flow.

In particular, it would allow you to keep track of time within the accuracy of the Arduino crystal (and requiring a crystal rather than a resonator). Presuming of course that the Arduino is continuously powered. It is however generally more practical to use a RTC.

Ok I dug into the blink without delay idea. It's actually very similar to what I was trying to pull off with delay(100) and counters. LOL.

My question is how long can the unit run before it maxes out the Long variable type? My unit will remain powered on continuously unless my car battery goes dead.

If my math is correct with an unsigned long it will go 49.7 days before crashing?

Nope, as long as you use subtraction to compare times it will roll over with no issues. If you do not believe us, write a test version with an unsigned byte (uint8_t) and see what happens when it rolls over.

I'll take your word on it ;).

Thanks again. Time to rewrite parts of my code. lol.