This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: ecos and gettimeofday()
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