I want to do timed measurements and after the timing period I want to reset the internal clock to zero and start again. How do I do it ?
Why reset it?
Why not just offset it?
If I reset it, I don't have to do calcs for when it overflows.
Reset should be an easy task.
You can't reset millis(), but you can set a variable equal to millis() and then reset it every time.
setup:
unsigned long Starttime
mainloop:
Starttime = millis()
Then you would trigger Starttime = millis() when you want to start and then maybe have a Stoptime = Starttime + 5000 for a five second timer.
just in case you're wondering you would also have a present variable
present = millis() that is always updated. You can use a do/while loop while Stoptime > present
Is millis() overflow really that much of a problem?
Four billion plus milliseconds is quite some time
There is NO problem with overflow if you use
unsigned long
for the variables (same type that millis() uses, check the reference)
unsigned long Timer1 ; //dont give it a value.
You "start" the "Timer" by assigning the current millis() to it.
Timer1 = millis() ;
When you want to check the timer you use the following construct
if (millis() - Timer1 > interval) ...where [i]interval[/i] is the number of milliseconds. This will work correctly even when the millis() wrap.
Now, the only potential problem is that if you wait approximatly 49 days, you will get into the range where it again waits for the timer. Thus if you know the timer has expired and possibly may not be reused in the next 49 days, you must have an additional flag or codepath that avoids testing the timer when you know it is not "active"
From what I have read, millis() overflows after 9 hours. This is probably long enough for me. I'm reading 100, 100ms samples for a session. I probably won't be working on the device for more that 3-4 hours each time so 9 hours is enough.
The question still remains, is there a way you can 'poke' the ATMEL device with native device instructions from within Arduino environment?
If so I 'can' add a function to reset the clock.
The "millis" counter is not a function of the AVR (there is no 32 bit millisecond clock counter in a register somewhere), but of the Arduino environment.
I don't know where you read about the 9 hour roll-over, but I don't think it applies anymore - it's more like 49 days.
Short answer "no".
However, you can make it seem like it has been reset to your code.
You basically use an offset (as suggested by the other posts).
Take a look at "stopwatch" and I'm sure that you will get a few ideas
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1280262760
<--! Please pardon the cross post -->
I'm sure this has been addressed elsewhere, but since this came up first when I googled the topic, I thought it might be helpful to post this solution here. It is absolutely possible to reset the millis() counter, and is absolutely desirable to do so in many situations.
If you're timing out a short event and aren't keeping track of timing elsewhere in your program, resetting the counter before you start your timer helps to avoid any possible overflows. I've seen some people post that 9 hours (or whatever it actually is) is way longer than what they need to time. But what if your 3 second event happens to start right before millis() overflows? Unlikely? Yes. Possible? Extremely. Resetting the timer beforehand gives you 100% assurance that it won't.
So, long answer short (no pun intended), you reset millis() by directly setting the variable that millis() uses to keep track of clock cycles to zero.
Make sure the variable is in the scope of your code by declaring it sometime after wiring.c is included and before loop():
extern volatile unsigned long timer0_overflow_count;
Then, whenever you need to reset the timer back to zero, just set:
timer0_overflow_count = 0;
...and then use millis() as you normally would (i.e.the offset examples above).
Then, whenever you need to reset the timer back to zero, just set:
While you have provided one of the steps, there are two more. Without the other two steps, your line of code will cause very difficult to debug problems. The other two steps cause an undesirable side-effect.
Millis overflows after 49 days and around 17 hours. I never bothered with any fancy code to allow for it. An odd glitch 8 times a year is something I can live with - often, depending on circumstances the roll-over happens completely unnoticed.
What are the two other steps? I haven't had any problems with this code so far?
What are the two other steps?
You want a snippet of code, that causes an undesirable side-effect, to overcome a serious problem introduced by your unnecessary attempt to reset the millis counter. The answer is no.
The solution to your problem is here...
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1281558329/6#6
You want a snippet of code, that causes an undesirable side-effect, to overcome a serious problem introduced by your unnecessary attempt to reset the millis counter. The answer is no.
I'm not sure why you're being argumentative about this; it's nothing personal. You said there were two additional steps, so I'm curious to know what they are. Otherwise, I'm not sure what undesirable side-effects you're talking about.
The solution to my problem is not at the reference you cited. It states:
Now, the only potential problem is that if you wait approximatly 49 days, you will get into the range where it again waits for the timer....
Which is exactly what I need to avoid. So far, my device has been running for 90+ days without the problems it was having at around 49 before this fix. I posted this because it was helpful to me, and may be to others as well.
Just because this dude said:
There is NO problem with overflow if you use unsigned long for the variables
Does not mean it's true. Using the unsigned long type may eliminate the problem for some, but only lessens it for others.
I'm not sure why you're being argumentative about this; it's nothing personal.
I'm argumentative because you're asking me to help you dispense bad advice.
The solution to my problem is not at the reference you cited.
In that case, you will need to clearly state the problem you're trying to eliminate.
Now, the only potential problem is that if you wait approximatly 49 days, you will get into the range where it again waits for the timer....
Which is exactly what I need to avoid.
You have an application that needs to wait more than 49 days between two events?
So far, my device has been running for 90+ days without the problems it was having at around 49 before this fix.
That does not change the fact that resetting millis in the way you've shown will cause problems.
I posted this because it was helpful to me, and may be to others as well.
While I have certainly been terse and, as you said, argumentative, at this point I will remove the chip from my shoulder... I do appreciate your participation and I hope that neither your experience on this thread nor my attitude will dissuade you from continuing to participate. In other words, thank you for trying to help.
Just because this dude said ... There is NO problem with overflow if you use unsigned long for the variables ... Does not mean it's true.
You're right. It may not be true. And the same logic can be applied to the things you claim to be true. Just because you say that resetting millis is safe does not mean that it really is safe.
Using the unsigned long type may eliminate the problem for some, but only lessens it for others.
Prove it. Show me how this code can fail...
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1281558329/6#6
If you can prove that code fails in your application, I will post a detailed description of how to safely reset millis and what the side-effect is.
I agree that there should be a future-proof way for a programmer to reset the "system clock", or even to set it to a specific value. Overflow detection and computations is a hack and not future proof. And a lot of messing around for something that only happens rarely and is thus hard to test.
If you have questions about Bradleys timer0_overflow_count suggestion, take a look at the timer code:
http://github.com/arduino/Arduino/blob/master/hardware/arduino/cores/arduino/wiring.c
I've used it before, and had it break in subsequent versions, then start working again in another version of arduino, so it is arduino version dependant (i.e. not future proof).
What I eventually wound up doing was making my own timer interrupt and disabling timer0.