This is the mail archive of the ecos-discuss@sources.redhat.com 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: posix time functions


David Brennan <eCos@brennanhome.com> writes:

> Nick Garnett wrote:
> >Using the PIT to keep track of real time over a long period is hard
> >since it runs at a very awkward frequency -- although I believe it is
> >reasonably accurate at a 200Hz interrupt rate. It is OK for handling
> >timing requirements of less that a minute or so.
> >
> Yes the problem is with that awkward frequency. I don't have the math
> handy, but we calculated that if we set the PIT to an interrupt rate
> of 1kHz, we would end up off by about 180 mSec per hour. Our system
> actually has multiple computers which generate messages with
> "real-time" time stamps which are often compared with each other for
> diagnostic purposes. So we need mSec accuracy on those messages.

Of course this is the sort of thing that the numerator/denominator
representation of the clock resolution is meant to deal with. The idea
is to adjust those values to more accurately represent the interrupt
frequency the hardware actually gives you, rather than the
approximation used to calculate the timer period. The result is that
eCos ticks end up slightly shorter than 1ms and you don't get the
drift.

> >Does your i386 platform have the standard Dallas RTC device? If so
> >then you could use that to track real time more accurately. The Dallas
> >device also provides a 1KHz interrupt which is more accurate than the
> >PIT, and is synchronized to the real time clock. It may be easier to
> >add an option to switch the eCos timer over to using that.
> >
> >
> >
> Really? I did not think the Dallas chip could interrupt that
> quickly. (I thought it was on the order of 1 Hz).

Specifically it generates a 1024Hz interrupt. However, since there is
no underying fast counter, you cannot do timing more accurately than
that, for hal_delay_us() for example, so it is not a good choice for
the main eCos timer.

> However, I will
> still need to be able to set the clock without affecting any of the OS
> timers.

If you can sort out the timer frequency, then you should only really
need to set it once at startup, before any timeouts are started. If
you use the RTC then you may not need to set it at all.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
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]