Relying on the millis

Hey, i am building a sports timer, simple one second increment counter to be displayed on a MAX7219 Led Module 8-Digit 7 Segment unit.

It seemed to work ok for a while, but now it counts one sec, waits over 1000ms, then counts two etc. A bit unstable. What can the issue be? Power?

Hi,
Welcome to the forum.

Please read the first post in any forum entitled how to use this forum.
http://forum.arduino.cc/index.php/topic,148850.0.html then look down to item #7 about how to post your code.
It will be formatted in a scrolling window that makes it easier to read.

Can you please post a copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png?

Thanks.. Tom... :slight_smile:

Did it really work perfectly for a while?

If YES, you might have a hardware problem.
The code you uploaded is stored in EEPROM. Just reinstall your code.

It does not happen that often, but bits in EEPROM might not be stable for several reasons.

This is very rare. Just show us your code.

And YES, you can trust the millis-function.

Hi, and welcome to the forum.
8 digits?
Seconds, minutes, hours, days?
The clock accuracy of an common resonater-based Arduino is ok for simple short-ish durations, but not ok if you want to measure very long times.
You might be a few hours off when you have reached 99.999 days.

My crystal ball sees delay() in your code for the seconds timer.
Not good, because delay() stops the micro dead in it's tracks while the delay is running.
Have a look at how the "BlinkWithoutDelay" sketch (in the examples) manages time without using delay().
Leo..

Hi,
Have you reloaded you code to see if the problem remains?

Tom.... :slight_smile:

arduinoaleman:
... The code you uploaded is stored in EEPROM. Just reinstall your code. ...

Wut?

ChrisTenone:
Wut?

Program Flash is common therm for memory where program is stored. But there is little difference between Flash and EEPROM.

Smajdalf:
Program Flash is common therm for memory where program is stored. But there is little difference between Flash and EEPROM.

None-the-less, in Arduino terminology, there is a difference between Flash and EEPROM. If the OP hasn't bothered to learn the difference between the terms (or to have responded to any of the replies) then why should we put in any more effort to help them?

Cumbrut ... really?

ChrisTenone:
None-the-less, in Arduino terminology, there is a difference between Flash and EEPROM. If the OP hasn't bothered to learn the difference between the terms (or to have responded to any of the replies) then why should we put in any more effort to help them?

Cumbrut ... really?

The OP never indicated he had any confusion regarding flash/eeprom, it's arduinoaleman who posted using incorrect terminology.

arduinoaleman:
Did it really work perfectly for a while?

If YES, you might have a hardware problem.
The code you uploaded is stored in EEPROM. Just reinstall your code.

It does not happen that often, but bits in EEPROM might not be stable for several reasons.

This is very rare. Just show us your code.

And YES, you can trust the millis-function.

The code is stored in Flash, aka "program memory".

There is also a form of non-volatile memory on the chip called EEPROM (you can read from and write to it from within your sketch, for example to save settings).

Neither of them lose data under normal operation - they should keep their data for decades, barring abuse.

While the underlying technology is similar, the way they are used is very different, so care should be taken to use the correct terminology.

Millis can be trusted, but only as far as you can trust the system clock. Which unfortunately is a resonator only accurate to within a percent or two on most arduino boards. Use an RTC if you want more accurate time.

That all said - it's not exactly clear what the problem you're having is - it would be best to post your code and a more detailed description of what it's doing, and how that differs from your expectation.

Hello all!

one strong personality here i see, is this normal? Quite unconstructive.

Well, nevertheless, my reply was delayed()..

  1. The problem did not exist untill lately, some code changes might have caused this i am led to blieve. From a HW perspective i have tried running power from both computer USB power and from a battery.

  2. From the awseom replies, i will do the following to research further:

  • reupload code
  • switch boards

But what struck me most was Wawa´s future-seeing crystal bowl, where the use of delay() was seen. I do infact have a bunch of theese. Furthermore i will abolish the delays and implement BlinkWithoutDelay

A not on the accuracy, the sports timer will never run longer than 120minuttes.

I will keep you informed!

Kind regards,

Cumbrut

My Arduino loses 1s per 1000s. You may lose/gain 7 (or more) sec during the 120 min.

Can you re-iterate your problem?

How are you actually timing the real output?

Delay() can cause issues, but as far as I was aware, the millis() is generate from a hardware counter and therefore is not effected directly by delay. Delay() actually uses the same counter to keep itself working as far as I was aware (might be Timer0).

Some code would be useful to identify where the problem/perceived problem may lie.
I have half a guess you mean that the time on the 8 digit display occurs after the 1 second...leading to me thinking that there is a set of delays() that may be causing an extended systematic period between the actual time and the time being displayed.

Sorry for annoying Arduino people

I live in an Intel/AMD world. Only an EEPROM is reprogrammable and can save data when the power is gone. The BIOS is stored in EEPROM, and even NVRAM is nothing else than EEPROM.

Therefore, technically the Flash of an ATmega is an EEPROM. No matter what you call it.

And I do know that programs will be stored in the flash and user data can be stored in EEPROM when using ATmega terms. And I will not get upset when you call an Apfel (german) an apple (english).

WAWAs crystal ball probably showed something that seems to be true.

Whoops. Sorry for the mistaken identity Cumbrut. I apologize.

arduinoaleman, it's not the technical point about flash being similar to eeprom, but rather the confusion using incorrect nomenclature causes. In an avr chip, there are both kinds of rewritable, non-volitile memory: eeprom and flash. Confusing them means yer program won't work.

Apparently Chris, if you are going to be productive, you will need a much weaker personality.

I'll have to work on toning it down. :stuck_out_tongue:

ps though, I always found the interchange between personalities made internet learning communities so much more fun than reading a book or taking a class.

I do little interchanging but a fair amount of reading.

Delay() can cause issues, but as far as I was aware, the millis() is generate from a hardware counter and therefore is not effected directly by delay. Delay() actually uses the same counter to keep itself working as far as I was aware (might be Timer0).

The problem with delay() is not it's accuracy, but that the processor can't do anything else while it's running...

regards

Allan

Delay() could be inaccurate.

The delay() itself might be accurate, but you might do something else between the delays, like printing to LCD.
That adds to the total "tick" time.
Using millis() avoids that.
Leo..

TKall:
I do little interchanging but a fair amount of reading.

Me too (but prob'ly more internetting.) I prefer wood pulp devices.