This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ecos and gettimeofday()


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.

        Andrew

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]