Re: [ECOS] Another question: real time clock vs interval timer.

[Nick Garnett <nickg at cygnus dot co dot uk>]

"Patrick O'Grady" <patrick@plasticgrape.com> writes:

> Hi, all...  I keep noticing how a platform's interval timer is referred to as the
> real time clock in the eCos source code.  Would it be better to refer to this as
> just the interval timer?

To me "real time clock" captures exactly what this clock does - it
tracks real time. It is possible to have other clocks in the system
that track other times (per-thread execution time for example). It is
also the clock that would drive any real time scheduling algorithms.

In any case, changing the name now would have serious consequences on
documentation and existing software. 

> In the case of the i386/PC, we have another actual real
> time clock which keeps actual real time automatically but has lousy resolution
> (only 1 second).

I would content that the PC RTC is misnamed, it is really a calendar,
or a CMOS clock.

In a system where "real time" has a specific meaning, having a device
called a real time clock that has nothing to do with it would be very
confusing. In any case, it is only on the PC where this confusion
would occur, I don't think we want to compromise our naming
conventions because of a bad decision made by IBM ~20 years ago.

> Since the interval timer uses an input frequency that isn't
> conducive to maintaining actual seconds, it might be better to avoid implying
> that it generates actual real-time data.

It should be possible to get this to work fairly accurately, most PC
OSs seem to manage OK - take a look at what Linux does. The trick may
be to remember that a single timer interrupt need not correspond to a
single clock tick, and each interrupt need not increment the clock by
the same number of ticks. Also, it is not necessary for clock ticks to
be proper fractions of a second.

> There is also a convienent mode that
> the pc's real time clock has: I can set an alarm which triggers an interrupt after
> a specific time of day; this may help reduce overhead implementing some alarms.
> 

Adding an option to the clock to allow it to postpone the next
interupt until the time of the next alarm is something we intend to
add at some point. It is quite an upheval to the clock code, so will
not be done soon.

You can always define a second clock and run it off the RTC and then
choose which clock to use based on some algorithm. But remeber, all of
this would be PC specific, and not easily applicable to any other
targets.


-- 
Nick Garnett           mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK   http://www.cygnus.co.uk