This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: # ticks per second?
Grant Edwards <grante@visi.com> writes:
> On Wed, Aug 30, 2000 at 06:41:35PM +0100, Hugo 'NOx' Tyson wrote:
> > And there is a C++ solution to this within the kernel. See the test
> > clockcnv.cxx in the kernel tests directory for how to use it, and clock.cxx
> > in the kernel source for its implementation.
> [...]
> > thus making it all far less likely to underflow or lose precision.
> >
> > It doesn't (yet) have a KAPI (C) API. It's used within the uITRON
> > implementation to get milliSecond clocks, which is bare C++.
> >
> > Feel free to design and contribute a KAPI API?
>
> Since it's not possible to change the clock tick period at
> run-time (right?), I'd try for a pre-processor constant. But
> that might be pretty hard to do in an accurate, general way.
Precisely!
The thing within the kernel will create for you a "converter" object to or
from "system clocks" from or to any unit of your choice - you then use the
converter object to change eg. N seconds into M system ticks. Or vice
versa, whatever...
You're right, any application would only create a very small number of
these of these during startup, but the calculation involved is way beyond
the preprocessor and so forth. So to generalize fully, it's done at
runtime. (This is one of the very very few examples of stuff I feel it's
OK to do at runtime, even though the result is the same every time - and it
also makes it easier to test properly)
- Huge