Print PDF
Favorite
Email
Step 4Time keeping
To keep track of time I used only the arduino, and the standard arduino function millis(). This method won't be completely exact, because the 16Mhz crystal oscillator, that decides the clock frequency of the arduinos CPU, probably won't be exactly 16 000 000 Hz. The good news is that you can measure how inexact your clock is and compensate for it in your code, because the offset should be constant for a given period of time.
Measure how inexact your arduino is:
As said earlier, the arduino will have a small time error, this error depends on the crystal oscillator and will be different for every arduino, to measure how much my arduino clock differed from the correct time, I programmed it to print out the time ( the hour, minute and second variables) via serial. I then let it run for a long time (Over night and more) and compared the arduino time with a clock I knew was exact, at the start and the end of my measuring period. Divide the time difference with the time the test took to calculate the error each hour. I found that my arduino is about 0.4 seconds to fast every hour. I used exacttimenow.com to get exact time, but if you have a watch you know is very exact, feel free to use that instead.
The code I used to keep the time is an adaptation of some code I found on the arduino forums. I rewrote it with if-statements instead of division and modulo, to see if there would be any speed difference and found that the if-version is more than 15 times faster (although both are still quite fast, more info about the test here).
Since I want the other stuff in my main loop (like checking the touch sensor, checking for button presses, etc.) to happen as often as possible, I used the faster version.
The code:
Every time the clock function is called it adds the time in milliseconds since last it was called to a variable m, when one second has passed (m>999) the second variable is increased by one and m is reset. When the seconds variable reaches 60, the minute variable will be increased by one, and seconds will be set to zero. The same thing happens with the minutes variable; when it reaches 60, add 1 to hours and reset minutes. The hour variable will be reset when it reaches 24.
To compensate that my arduino is 0.4 seconds faster evey hour, I decrease the seconds with two seconds every fifth hour.
____________________________________________________________________
______________________________________________________________________
Measure how inexact your arduino is:
As said earlier, the arduino will have a small time error, this error depends on the crystal oscillator and will be different for every arduino, to measure how much my arduino clock differed from the correct time, I programmed it to print out the time ( the hour, minute and second variables) via serial. I then let it run for a long time (Over night and more) and compared the arduino time with a clock I knew was exact, at the start and the end of my measuring period. Divide the time difference with the time the test took to calculate the error each hour. I found that my arduino is about 0.4 seconds to fast every hour. I used exacttimenow.com to get exact time, but if you have a watch you know is very exact, feel free to use that instead.
The code I used to keep the time is an adaptation of some code I found on the arduino forums. I rewrote it with if-statements instead of division and modulo, to see if there would be any speed difference and found that the if-version is more than 15 times faster (although both are still quite fast, more info about the test here).
Since I want the other stuff in my main loop (like checking the touch sensor, checking for button presses, etc.) to happen as often as possible, I used the faster version.
The code:
Every time the clock function is called it adds the time in milliseconds since last it was called to a variable m, when one second has passed (m>999) the second variable is increased by one and m is reset. When the seconds variable reaches 60, the minute variable will be increased by one, and seconds will be set to zero. The same thing happens with the minutes variable; when it reaches 60, add 1 to hours and reset minutes. The hour variable will be reset when it reaches 24.
To compensate that my arduino is 0.4 seconds faster evey hour, I decrease the seconds with two seconds every fifth hour.
____________________________________________________________________
The clock() function:
// CLOCK VARIABLES:
#define MAX_MILLIS_VALUE 34359738
unsigned long current_millis_value = 0;
unsigned long previous_millis_value = 0;
unsigned long m = 0;
int seconds = 0;
int minutes = 0;
int hours = 0;
void clock()
{
current_millis_value = millis();
if (current_millis_value < previous_millis_value) // if millis overflows
{
m += MAX_MILLIS_VALUE - previous_millis_value + current_millis_value;
}
else // if millis has not overflown
{
m += current_millis_value - previous_millis_value;
}
if (m>999)
{
seconds++;
m = m-1000;
}
if (seconds>59) // if seconds == 60
{
minutes++;
seconds = 0;
}
if (minutes>59) // if minutes == 60
{
hours++;
minutes = 0;
if(hours%5==0) // adjust the time with -2 seconds every 5th hour.
seconds = seconds - 2; // this will cause seconds to be -2,
// therefore seconds can't be unsigned.
}
if (hours>23) // if hours == 24
{
hours = 0;
}
previous_millis_value = current_millis_value;
}
______________________________________________________________________
| « Previous Step | Download PDFView All Steps | Next Step » |
condition ? run if true : otherwise run this;
So you could do that first if() statement like this:
current_millis_value < previous_millis_value ? m += MAX_MILLIS_VALUE - previous_millis_value + current_millis_value : m += current_millis_value - previous_millis_value;
It's not as pretty, but as always, C ignores whitespace, so you can write it like this if you want to organize it a little:
current_millis_value < previous_millis_value ?
m += MAX_MILLIS_VALUE - previous_millis_value + current_millis_value :
m += current_millis_value - previous_millis_value;
It might run faster and eliminate some of the timing error.
Also, you might be able to spread out the time correction a little more evenly than 2 seconds every 5 hours. Since it's .4 seconds, that's 400 milliseconds every 60 minutes. That goes down to 20 milliseconds every 3 minutes. Since you're counting milliseconds directly, and the overall count of seconds is a multiple of 3, it might be overall a little more accurate to the user to do the correction more often.
Great tutorial though, I might have to try this!
About the time compensation, yes I have thought about that and maybe I will add it later. Since the clock only shows minutes I don't think it matter that much. The advantage with that method is that it's easier to compensate for cases when you have for example 0.43 instead.
Hmm, I somehow thought It would be more complicated to compensate the milliseconds, but now when I think about it, it should be as easy, one just have to make the millis variable signed, so the subtraction won't cause it to underflow.
Thanks for the suggestions, I'm glad you like the instructable!
Yeah, I'll have to see how ternary operators and if() statements compare when I finally get an Arduino (Christmas is coming, as my plan currently stands). For a lot of embedded environments, all those conditional structures get compiled down the same way anyway. I think I recall that the C18 compiler (for PIC microcontrollers, like the one in my VEX robot) compiles if() and switch() statements to the same thing. I wouldn't be surprised if it takes while() loops down to if()-goto structures. Or I guess I could just look at the avr-gcc manual, but that would be too easy :D
I think I might eventually try this project, I've wanted a binary clock for a while, and I love the AVR line. One thing that I found last night is that the Arduino bootloader still allows you to use the lower-level avr-gcc commands. It turns out that digitalWrite() takes about 10 times longer to run than accessing the PORT register directly, because with each call of digitalWrite(), it turns off all of the PWM timers (and in the comments in the code, the guy is asking why that couldn't be moved up to pinMode(), which is interesting). Basically, digitalWrite() is just some safety mechanisms and a parser for the PORT register. It sets the PORT of your choice (lets say pin 13, which is under PORT B, pin 5) to an entire byte all at once (you can toggle 8 pins just about simultaneously). This would work like this, IIRC:
PORT_B = 0b00010000;
Or, to only affect that pin, you can use the | operator:
PORT_B |= 0b00010000;
You don't have to make these modifications, I realize it would take a long time to recalibrate, just thought you might be interested. I still love the tutorial. I think it might also be interesting to make a multiplexed or charlieplexed version, just for funsies.
Wouldn't that just work if you want to correct at least 1 millisecond every second (60ms per minute) wich is more than I want to?
"[...]
It turns out that digitalWrite() takes about 10 times longer to run than accessing the PORT register directly, because with each call of digitalWrite(), it turns off all of the PWM timers (and in the comments in the code, the guy is asking why that couldn't be moved up to pinMode(), which is interesting).
PORT_B = 0b00010000;
[...]"
Actually there have been much discussion about how to make digitalWrite faster on the arduino developers mailinglist lately (link), maybe digitalWrite compiled to one instruction will come in the next version of the arduino ide.
I think I'll just wait for that since using digitalWrite makes the code cleaner and easier to understand*, and It works good as it is. I don't have much time now anyway to tinker with the clock, because I have calculus exam soon :S.
* = for me at least, I'm not used to the PORT stuff since I have mostly used the arduino. I would like to learn more how microcontrollers really work sometime though. The arduino hides all complexity, which is really nice, and makes it easy to make stuff with it, but it would be intresting to learn how it works low-level.
"You don't have to make these modifications, I realize it would take a long time to recalibrate"
I don't think I would have to recallibrate, the time error should come from the crystal oscillator frequency and not from how long it takes to execute the loop.
"I think it might also be interesting to make a multiplexed or charlieplexed version, just for funsies."
Yes, I would like to experiment with charlieplexing too sometime.
if(seconds==59 && m > (!minutes%3 ? 999+6 : 999+7)) { //If divisible by 3, add
seconds++; //18 ms, otherwise 19
m = 0;
}
else if(m>999) { //Normally, a second is just 1000ms
seconds++;
m = 0;
}
I think how you do it with the 2 seconds every 5 hours is fine by the way, this is more just a point of discussion.
-Simon