Micro,
Let me follow up with some comments. I think you are missing the goal of the “Easy and Accurate Clocks without RTC IC.” The goal was just that - to make an easy and accurate clock without a RTC. The way it is set up now (prescaler=256), the user has lots of time to do stuff between TMR0 roll overs – and the long term accuracy is amazing. The user also does not need to do much overhead to keep the clock running other than add time to a counter every so often.

The “lots of time” is handy for updating serial displays, reading other sensors, turning on other things, doing something else, etc. (For example, depending on how it's done, to update the clock from 9:59.59 to 10:00.00 would require about 15 bytes sent to a display. Serially at 9600 baud, this is about 15.6 mS just to send. The user still has about 50mS to prepare the data for sending and to do other stuff!)

With the algorithm in the examples above, you could easily reduce the the prescaler, which would reduce the second to second jitter – but the overall long-term accuracy remains the same. For example, if the prescaler was changed to 1 instead of 256. The second to second error would be: 1,000,000/256 = 3906.25 overflows, error = .25*256 = 64uS. For 1000 seconds, the total error would be 0 (which is hard to beat). The trade off for the second to second reduction in jitter is less time between overflows (with a prescaler of 1, the rollovers are every 256 uS – forget updating a display). But the point is- who cares about the jitter! When I look at my alarm clock every morning I do not care if if it is off by 34uS. When I am turning on lawn sprinklers every third day at 1:00AM, I do not care if it is 21 uS early., etc. What I do care about is the long term accuracy of my clocks.

These algorithms are meant to be easy to use. There are only about 30 lines of code required to keep the time and maintain a display (including colon blinking). On the Internet or in this forum I have not seen anything close to this little amount of code for keeping good time with or without a RTC. If you are worried about the second to second variations, or making accurate short time timers, then check out Melanie's “Olympic Timer” or Darrel's “Elapsed Timer Demos”. They are both excellent!. Or, with my examples, you can look inside the TMRO counter at anytime and know your exact error. Skinning cats is fun!

A comment about your option of initializing TMR0 to 194. This approach works, but you must note that you need to account for the fact that the timer does not start up immediately after you write to it. You also have to ask yourself what the Timer is doing while you are writing to it, i.e., is it counting? Because of these, you usually have to add a “fudge-factor” and reduce the initialized value even more. This can be done but takes more overhead code and you are getting farther away from “easy” (in my opinion). The nice thing about PICs is you truly do have lots of options. Everybody should use the option that best suits them.

Paul Borgmeier
Salt Lake City, Utah
USA