The lack of a break in a state machine is often done on purpose. It is
used where we want to immediately execute the code for the next state
instead of exiting and coming back to execute it. I don't like using
state++ because it's too easy to lose track of where you're going to. I
like saying state=3DStateName and going on from there.

In my use of the Microchip SNTP client, I have a 32 bit counter that is
incremented by a once per second interrupt. If the counter disagrees with
the result from SNTP by more than one second (I allow for plus/minus one
second jitter), I stuff the value returned by NTP into my counter. I also
save this value as LastNtp so I can see when the RTC was updated, if ever.
Generally, if it was ever updated, I consider the clock to be valid. Also,
if I have to move my clock ahead, I adjust the 1 Hz interrupt period
register one count to make the interrupts happen faster. If I need to slow
the RTC down, I go the other way.

I'm using the 32 bit time stamp value for all my internal usage and
converting to a string only for user interface.

Does anyone have suggestions for handling the upcoming 32 bit rollover
with the Microchip code? Can we move to a 64 bit version of time_t?

Harold




--=20
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Not sent from an iPhone.
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.