> > Stop the clock, set the time to somewhen in the > future, wait for that set time to arrive, and start the > clock exactly then, > Good idea: it would be wise to stop the clock before > setting it and > start it afterwards in any case. > I'm not sure if acual waiting after setting the time adds > much. The > sequence probably takes less than 2ms (3 i2c messages?) and > the clock > resolution is 1 second...
Yes, I was just riding theory. Probably it makes no sense to wait. It strongly depends on where I get the time to set from. It can make sense if an internet time server or a radio clock is connected. If the time is somehow set by hand, I'm sure it makes no sense. You won't be setting the time more accurate than 1 second. > > Another, quite slow possibility would be to read the > seconds again and again *until* they change. Then you'll > have one second within no carry can occur to read the other > values. > This means it could take up to 1001 ms to read the clock, > assume the > read itself takes 1 ms... It's not the best solution in general. It could be useful however, if e.g. I want to do something for 10 seconds. Reading the clock this way would lead to timing 10.00 seconds. Other variants could lead to 10.99 seconds. or 9.01 seconds. But, to be honest, this is "to make up accuracy". Meaning, trying to make a device give accuracy it doesn't have. Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
