Re: Using "delay until" in real-time

[Ted Dennison <dennison@telepath.com>]

In article <915p5n$p2j$1@nnrp1.deja.com>,
  Mike Silva <mjsilva@my-deja.com> wrote:
> It's Son of Patriot bug...

That's similar to what I called it. :-)

> I'm as far from an expert as you can get, but what if you defined your
> Iteration in terms of Tick (4*Tick in your case)?  Seems like that
> should provide an exact representation (why do I feel like that
> comment will get me nailed?). Otherwise, keep your own Iteration
> count in a scalar and add it (first converted to a Time_Span) to a
> Start_time for each delay until.

I'm still feeling too dumb for not seeing this before to "nail" anyone
about it. Since Iteration_Hz in my old example was 4*tick, it sounds
like you are saying something like:

   task Executive is
      Iteration_Count : Natural := 0;
      Start_Time      : Ada.Real_Time.Time := Ada.Real_Time.Clock;
   begin
      loop
         -- do work
         Iteration_Count := Iteration_Count + 1;
         delay until Start_Time + (Iteration_Count * Iteration_Hz);
      end loop;
   end Executive;

I see a couple of problems with this.
   o  This would only work for Natural'last iterations. That could be
accounted for though.
   o  Iteration_Count * Iteration_Hz is no different mathematicly from
adding Iteration_Hz to Start_Time Iteration_Count times, which is what I
was doing. You'd still get the same compounding round-off error.

> It's a very interesting question, and if I'm wrong I look forward to
> learning the right answer.

Very. I had a lot of enthusiasticly offered ideas here at work when I
asked about it yesterday.

--
T.E.D.

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


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