[ECOS] More Wallclock questions

[Jonathan Larmour]

Damir Salantic wrote:
> 
> Jesper Skov wrote:
> > Note that on some platforms the kernel clock may not be accurate over
> > long periods of time.
> >
> > This can be caused by (a) inaccuracy in timer programming [even if it's
> > accurate to 0.1% of the 100Hz ticks, the error will accumulate over
> > time], and (b) delays in reloading the timer [some platforms do not have
> > automatic reload of the timer counter, so disabling interrupts may cause
> > (minimal) timer drift, which again accumulates over time].
> 
> Thanks for warning.
> Unfortunatelly access to my RTC is too much time consuming. So, I can't
> afford reading of it each time when time() function is called (and is called
> often).
> So, I have to make some tradeoffs here. Probably some synchronization from
> time to time should be neccessary.
> 
> Anyway, I solved my problem, in way to not change kernel clock, but to keep
> difference between it and hardware clock in some variable and to apply
> correction each time when get_hw_seconds() is called.
> 
> cyg_uint32 Cyg_WallClock::get_hw_seconds(void)
> {
>     Cyg_Clock::cyg_resolution res =
> Cyg_Clock::real_time_clock->get_resolution();
>     cyg_tick_count_t secs = Cyg_Clock::real_time_clock->current_value();
>     secs /= (( res.divisor * 1000000000LL ) / res.dividend) ;
>     return (secs + time_difference);

Hah. I was going to tell you that this would be the better way to do that
than what you were trying before.... but you already have. I would
discourage your other approach for the reasons you gave. This is the way to
do it.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine