Serge Bets wrote: > Hello David, > > On Tuesday, July 22, 2008 at 7:45:06 +0100, David Woolley wrote: > > >>Serge Bets wrote: >> >>>Hwclock 2.33 sets the RTC with typically a maximum error of >>>10 microseconds >> >>That would only be possible if the RTC's counter was updated on both >>phases of the 32kHz clock, which I rather doubt. > > > Excellent example, Dave! The source 32K crystal period being 30 µs, you > point the finger at a real issue. An issue that has been squashed some > time ago by hwclock's feedback mechanism. Not a problem anymore. > > For simplification, I'll assume everything else is instant and perfect, > and will neglect RTC restart delay. When we set the RTC, the last crystal > pulse happened between 0 and 30 µs ago. Let's pick 18 µs for the > example. This last pulse becomes the start of this RTC second, the next > second will start 32768 pulses later, and so on. Result: the RTC is in > advance by +18 microseconds. Problem. > > However the feedback mechanism measures this +18 µs offset, and corrects > future readouts by -18. Final result: nothing less than perfection. :-) > > > Serge.
If you fix the RTC time in the ISR for the "second tick" you have a deterministic relation from edge to (update) action. IF you take in the same ISR the value of one of the high resolution counters you can establish over time a relation between RTC and CPU clocks. ( even independent of any external time source ) Some years ago I did something similar with the DCF77 signal and the cpu clock of a data aquisition system. Both informations were stored in 10ms Dataframes. uwe _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
