This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Clocks on EDB7XXX
- To: "'Gary Thomas'" <gthomas at redhat dot com>
- Subject: RE: [ECOS] Clocks on EDB7XXX
- From: "Trenton D. Adams" <tadams at extremeeng dot com>
- Date: Tue, 17 Jul 2001 13:56:35 -0600
- Cc: "'eCos Discussion'" <ecos-discuss at sourceware dot cygnus dot com>
- Organization: Extreme Engineering
> On 17-Jul-2001 Trenton D. Adams wrote:
> > Ok, the RTC on this platform is 1Hz. If I use cyg_clock_create ()
> will
> > it always work with the resolution I pass to it? I want to be
able to
> > get a clock based on ms rather than seconds. Also is there a way
of
> > getting the uptime of the system in ms?
> >
> > What I actually need is a way of getting an accurate time in ms.
I
> was
> > thinking of doing the following.
> >
> > On startup do the following
> > Store the current clock tick value in an initial clock tick
variable.
> > Ultimately I would like this to be in ms and not necessarily clock
> > ticks.
> > Store the RTC value in an initial RTC variable
> >
> > Calculating RTC seconds + ms of time.
> > Since the RTC is in seconds, I have to make sure the tick variable
> > before is synchronized with the RTC so 0 ms is at the right time
(same
> > time as an RTC increment).
> >
> > RTC - RTC variable = seconds since startup
> >
> > Get tick count
> > ms = (tick count - tick variable) - seconds since startup * 1000
> >
> > ms would then be the correct number of milliseconds after the last
RTC
> > increment occurred.
> >
> > Is there an easier way of doing this in eCos?
>
> Yes. Use the system clock, which will have a 10ms resolution by
> default,
> and the function HAL_CLOCK_READ() which can be used to calculate the
> time
> relative to the current 'tick'. Using this method, you can have
times
> as accurate as the hardware supports (on the Cirrus Logic EDB7xxx
down
> to 2us).
>
> What this does _not_ provide is any way to schedule threads on a
higher
> resolution basis, but it doesn't seem like that's what you were
after.
>
Yes, that is correct. I have no need for a higher resolution scheduler.
> [Shameless repeated plug] You'll find code which does all of this
and
> makes use of such high resolution numbers in the kernel test
> tm_basic.cxx
What's a repeated plug?