Stop mode problem

[ubercraftworks]

Posted on May 23, 2010 at 23:18

Stop mode problem

[shannon2]

Posted on February 12, 2012 at 00:48

Sorry to revive an old thread but I had a relevant question.

First, I'd like to say I respectfully disagree with you Clive that using the RTC to only maintain seconds per day is ''stupid''.  We all have different applications and in my case, time is updated via GPS.  GPS gives only time of day.  Converting it to time since epoch is extra work. I have to maintain day, month, year variables anyway so why store it in two places?  Anyway...that's not my question.To handle the rollover at midnight, shouldn't the comparison be >= 24:00:00 and not = 23:59:59?  It would seem to me if it = 23:59:59 and you reset it to zero you would be missing the last second of every day.  Does it take a full second to update the RTC counter?Shannon

[Tesla DeLorean]

Posted on February 12, 2012 at 03:01

Sorry to revive an old thread but I had a relevant question.

First, I'd like to say I respectfully disagree with you Clive that using the RTC to only maintain seconds per day is ''stupid''.  We all have different applications and in my case, time is updated via GPS.  GPS gives only time of day.  Converting it to time since epoch is extra work. I have to maintain day, month, year variables anyway so why store it in two places?  Anyway...that's not my question. To handle the rollover at midnight, shouldn't the comparison be >= 24:00:00 and not = 23:59:59?  It would seem to me if it = 23:59:59 and you reset it to zero you would be missing the last second of every day.  Does it take a full second to update the RTC counter?

Way to totally miss the point of flawed implementation I made through the entire thread. Sure if you code properly and test adequately things will work as they should, more often people don't.

GPS also tracks weeks and emits UTC time properly only when it corrects for UTC leap seconds. GPRMC and GPZDA both emit dates provided they have the GPS week number, and know which ~19 year roll-over period they are in.

[Tesla DeLorean]

Posted on February 12, 2012 at 03:36

Converting it to time since epoch is extra work. I have to maintain day, month, year variables anyway so why store it in two places?

Here's the rub, when you account for time as a linear progression of seconds you can do some simple integer math on two numbers and figure out 29, or 43.5, days have passed without having to figure out which day, month, year implications there are. So now your computation takes a few machine cycles, not a few hundred or thousand. In situations where you need a human representation of time and date this can be readily computed, and the day/month/year result can be cached to significantly decimate the repetitive work required to arrive at them. Want time-of-day, TOD = SecondsSinceEpoch % 86400, perhaps a dozen or so cycles.

[shannon2]

Posted on February 12, 2012 at 06:53

Sigh... Can we at least try to act civil.  Would you answer me like that face to face? ''

Way to totally miss the point

 .... ''  I have respected you and your answers for quite some time on here but when people act this way on these public boards due to some kind of anonymity it not only diminishes respect for them but drags down the entire board and stifles the flow of free information.Yes I understood your point.  Thank you.  I guess I was unable to get my point across to you.  I do not see any computational or memory usage advantage to maintaining a linear accumulation of seconds since some random epoch.  It seems like a units problem... seconds or months, days, years.  My application does require human readable units.  I have to maintain them.  That understood, why on earth would I want to convert between that and seconds since epoch?  Oh yes...you pointed out that I missed the point. Doing it any other way than as you state is fraught with complexity that outweighs the inconvenience of converting from seconds to calendar time.I did not come here to debate the merits of this minutia however.  I simply asked a question as to why the ST example (that was restated above) checked for 23:59:59 and then updated to zero.  It would seem to me that this would miss the last second of the day. UNLESS it takes a full second for the update to take effect.  Can anyone help me on THIS point?Shannon

[Tesla DeLorean]

Posted on February 12, 2012 at 08:22

Actually I'm sure I would, but I'd also take time to read and digest the thread, and test

some of my assumptions. The points advanced, separate from my view that the lads developing UNIX 40 years ago got it right.''Seem also to remember that 00:00:00 is equivalent to 24:00:00 not 23:59:59, or perhaps you have some leap second event you are handling.''''If you want to confine it to 24 hours, you should always check >= 86400, in which case you should then subtract 86400 from the RTC. If it was out for several days, you might have to repeat the check/subtraction until the number is in scope. You can enumerate the days.'' Now clearly, if the RTC would have a weird advancement mechanism, this would be evident every time you try to advance/sync the RTC to an external source, and it would keep being off-by-one. This however is not apparent, or observable. There are synchronization issues across the power domains, and further complications about when you change the value within the second (ie fractionally via the prescaler), which is why doing it in the RTC interrupt, or waiting for the top-of-second, is advisable to avoid a race condition. That, or clearing the prescaler count before writing the RTC count. The example uses 23:59:59 because it's busted, a point also made. Implementation FAIL And yes it's a units issue, and the same reason I wouldn't hold intermediate results in obtuse units like inchs, feet, yards and miles, and why I'd process them at a bandwidth appropriate for the human interface that was consuming them.

[shannon2]

Posted on February 13, 2012 at 04:51

Thank you for your altruism.