Re: [ECOS] ecos and gettimeofday()

[Gary Thomas <gary at mlbassoc dot com>]

On Sun, 2005-10-16 at 14:29 +0200, Andrew Lunn wrote:
> On Sun, Oct 16, 2005 at 12:45:41PM +0200, Peter Korsgaard wrote:
> > >>>>> "Alexander" == Alexander Neundorf <neundorf@kde.org> writes:
> > 
> > Hi,
> > 
> >  Alexander> From net/ppp/current/src/sys-ecos.c:
> > 
> >  Alexander> int gettimeofday(struct timeval *tv, struct timezone *tz)
> >  Alexander> {
> >  Alexander>     cyg_tick_count_t time = cyg_current_time();
> >  Alexander>     tv->tv_sec = time/CYGNUM_HAL_RTC_DENOMINATOR;
> >  Alexander>     tv->tv_usec = (time%CYGNUM_HAL_RTC_DENOMINATOR)*10000;
> >  Alexander>     return 0;
> >  Alexander> }
> > 
> > Independently of where to put the implementation, it would also be
> > very interesting to provide sub-tick resolution with HAL_CLOCK_READ -
> 
> Sure, but one problem at a time please....
> 
> 
> > E.G something like (completely untested):
> > 
> > int gettimeofday(struct timeval *tv, struct timezone *tz)
> > {
> >     cyg_uint32 before, after;
> >     cyg_tick_count_t time;
> > 
> >     /* repeat until we can do a HAL_CLOCK_READ and cyg_current_time
> >     without getting a timer tick */
> >     do {
> >        before = HAL_CLOCK_READ();
> >        time   = cyg_current_time();
> >        after  = HAL_CLOCK_READ();
> >     } while (after < before);
> > 
> 
> I don't like this. Worse case scenario is that we spin for a complete
> eCos tick, typically 10ms. This would happen when the HW timer counter
> can only do 10ms ticks. This is probably very rare, but not nice. In
> practice the code spins for one HW timer tick.
> 
> Thinking allowed here...
> 
> We are trying the prevent a mismatch between HAL_CLOCK_READ and
> cyg_current_time() becasue the timer interrupt has gone off, but the
> DSR has not yet run so that cyg_current_time is one or more ticks
> behind. If we don't handle this case the time returned will jump
> backwards by up to one eCos tick.
> 
> Your code does not work. You are looking for the wrap around
> condition. If the hardware timer has wrapped around you assume the
> eCos time has been incremented and things are wrong. Actually, it is
> the opposite assumption you make. You assume that if the timer has not
> wrapped around the eCos counter is correct. This assumption is
> false. It could be that the scheduler is locked and the HW timer has
> gone off. But since the DSR cannot run the eCos clock is behind by a
> tick, or more if the scheduler locked for a long time. Calling
> gettimeofday() with the scheduler still locked will allow the HW tick
> to increment so fulfilling your test, but the eCos time is still
> wrong.
> 
> What you need to know is has the hardware timer wrapped around and the
> eCos clock not yet ticked. I don't see any easy way to detect this. I
> also don't really see what you are going to do even if you could
> detect this condition. Spinning is not going to help, since something
> is blocking the DSR. 
> 
> I think the best you can do is simply combine HAL_CLOCK_READ and
> cyg_current_time and store the time you returned. The next time
> gettimeofday() is called you compare the current result with the last
> and if time has gone backwards you return the old stored value.

Much better would be to just use HAL_CLOCK_READ() for what it's
designed - it is supposed to return an indication of how much time
has elapsed since the last clock tick.  You can use this to compute
the sub-tick (sub-second) portions of the time-of-day.

For an example of how to use it this way, look at tm_basic


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss