Re: Using "delay until" in real-time

[Ted Dennison <dennison@telepath.com>]

In article <916aqq$9a7$1@nnrp1.deja.com>,
  Mike Silva <mjsilva@my-deja.com> wrote:

> Yep.  You could, e.g. add 1.0 to Start_time and zero Iteration_count
> every 60 iterations.
>

Ahhh. That's essentially what I was talking about doing.


> Still, I think it's better to try and represent your iteration in
> units of Ada.Real_Time.Tick.  Then you are never dividing, only adding
> a scalar.  If Ada.Real_Time.Tick can exactly represent your system
> tick of 1/240 sec. then you should never have an error.  Then the
> question becomes whether Tick is an exact representation of the system
> tick time(seems like it would have to be!).

I don't know about that. The system call on this OS to set the clock
rate takes in units of iterations per second. If that is the actual
units that the real-time clock hardware uses, then there's no possible
way for something expressed in units of seconds (like
Ada.Real_Time.Tick) to represent the *exact* same amount of time.

However, its quite possible that the real-time clock hardware on my
platform (PC) uses something like nannoseconds, and the OS call just
approximates that. In that case it indeed ought to be possible for
Ada.Real_Time.Tick to be an exact match for what the hardware clock
uses. However, since this compiler works with any PC-based version of
this OS, it could be that there was no good way of knowing what the
real-time clock's exact internal representation of time would be, so
they made Ada.Real_Time.Tick an approximation anyway. I'll have to look
into this issue...

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/