Re: [ECOS] ecos and gettimeofday()

[Peter Korsgaard <jacmet at sunsite dot dk>]

>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:

 >> Independently of where to put the implementation, it would also be
 >> very interesting to provide sub-tick resolution with HAL_CLOCK_READ -

 Andrew> Sure, but one problem at a time please....

Yes, sorry about that - I just got reminded of the issue with I saw
the gettimeofday implementation..

 >> 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);
 >> 

 Andrew> I don't like this. Worse case scenario is that we spin for a complete
 Andrew> eCos tick, typically 10ms. This would happen when the HW timer counter
 Andrew> can only do 10ms ticks. This is probably very rare, but not nice. In
 Andrew> practice the code spins for one HW timer tick.

Sorry, that I don't get. in what situation will the loop be executed
more than twice?

 Andrew> Your code does not work. You are looking for the wrap around
 Andrew> condition. If the hardware timer has wrapped around you assume the
 Andrew> eCos time has been incremented and things are wrong. Actually, it is
 Andrew> the opposite assumption you make. You assume that if the timer has not
 Andrew> wrapped around the eCos counter is correct. This assumption is
 Andrew> false. It could be that the scheduler is locked and the HW timer has
 Andrew> gone off. But since the DSR cannot run the eCos clock is behind by a
 Andrew> tick, or more if the scheduler locked for a long time. Calling
 Andrew> gettimeofday() with the scheduler still locked will allow the HW tick
 Andrew> to increment so fulfilling your test, but the eCos time is still
 Andrew> wrong.

Ah yes, I forgot that the timer isn't updated in the ISR - back to the
drawing board...

 Andrew> I think the best you can do is simply combine HAL_CLOCK_READ and
 Andrew> cyg_current_time and store the time you returned. The next time
 Andrew> gettimeofday() is called you compare the current result with the last
 Andrew> and if time has gone backwards you return the old stored value.

Yes, but that would effectively freeze the clock for a complete tick.

If the problem is that you don't know if the clock DSR has run or not,
perhaps you could do something hackish like this to make sure it hasn't:

cyg_scheduler_lock();

before = HAL_CLOCK_READ();
time   = cyg_current_time();
after  = HAL_CLOCK_READ();

if (after < before)
{
   /* timer overflowed, but DSR hasn't updated cyg_current_time() yet */
   time++;
}

cyg_scheduler_unlock();

.. instead of the do .. while loop. Wouldn't that work?

-- 
Bye, Peter Korsgaard

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