This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
RE: Timer tick length
- To: Grant Edwards <grante at visi dot com>
- Subject: RE: [ECOS] Timer tick length
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Wed, 05 Apr 2000 06:51:35 -0600 (MDT)
- Cc: ecos-discuss at sourceware dot cygnus dot com
On 04-Apr-00 Gary Thomas wrote:
> Here's how to get at it (culled from ecc/kernel/XXX/tests/tm_basic.cxx):
>
> #include <pkgconf/kernel.h>
>
> long rtc_resolution[] = CYGNUM_KERNEL_COUNTERS_RTC_RESOLUTION;
> long ns_per_system_clock;
>
> // To convert system clock 'ticks' to nanoseconds (ns)
> ns_per_system_clock = 1000000/rtc_resolution[1];
> ns = (ns_per_system_clock * (long long)ticks) / CYGNUM_KERNEL_COUNTERS_RTC_PERIOD;
>
Notice I was little over exuberant in my response. These calculations tell
you how to interpret the results of HAL_CLOCK_READ() which accesses the highest
resolution timer in the system (a raw system clock). The system realtime
clock, sometimes called a hearbeat, which is used for 'cyg_thread_celay()', etc,
actually runs at one clock "tick" per 'ns_per_system_clock'.
Thus, to sleep for some number of micro-seconds 'n', you would
cyg_thread_delay((n*1000)/ns_per_system_clock);
So eCos's notion of how fast the system clock runs isn't that complicated after all.