Re: Using "delay until" in real-time

[Ted Dennison <dennison@telepath.com>]

In article <iA1duAAkYpN6Iw1g@diphi.demon.co.uk>,
  JP Thornley <jpt@diphi.demon.co.uk> wrote:
> In article <915jl7$jt5$1@nnrp1.deja.com>, Ted Dennison
> <dennison@telepath.com> writes
> >1/60 works out to about 0.016(6-repeating). That can't be accurately
> >represented in an IEEE floating-point register. So what we get is
> >something like 0.016667 (forgive me if I'm rounding the wrong digit).
>
> Why not use 3 'minor' cycles in a 'major' cycle.
>
> The major cycle then has an exact delay of 0.05, and the minor cycles
> are offset by 0.016667 and 0.033333 within the major cycle.

Ahhh, someone who speaks our language. :-)

It looks like you are essentially suggesting that the scheduler do
something like:
      Minor_Iteration_Rate : constant := 1.0/60.0;
      Major_Iteration_Rate : consant  := 0.05;
begin

   loop
      -- do work
      for Minor_Cycle in 1..2 loop
         delay until Next_Time + Iteration_Rate * Minor_Cycle;
         -- do work
      end loop;
      Next_Time := Next_Time + Major_Iteration_Rate;
      delay until Next_Time;
   end loop;

I think this is essentially the same as my iteration-counting scheme,
except that the "Major_Iteration_Rate" is set to 0.05 instead of 1.0,
and the number of minor cycles is hard-coded.

I did simplify things a bit for my question. We are actually using 4
minor cycles in our 60Hz major cycle. Under the scheme we use here
things can only run once a major cycle, so the fastest with the current
settings would be 60Hz. However, we can adjust the minor cycle used in
order to prevent jitter in those tasks that are expecially sensitive to
it (eg: Controls and the Visual system). So our executive is *actually*
running at 240Hz (but of course this doesn't affect the math problem.
1/240th still a repeating decimal).

--
T.E.D.

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


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