Re: Duration for GNAT on ARM

[Simon Wright <simon@pushface.org>]

Simon Wright <simon@pushface.org> writes:

> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> Le 23/12/2014 23:42, Dmitry A. Kazakov a écrit :
>
> Actually, it was me.
>
>>> However, if I do this with both GNAT GPL 2014 and FSF GCC 4.9.1
>>>> cross-compiling to arm-eabi for the STM32F4 family (Cortex M4), I get
>>>> 
>>>>    type Duration is delta 0.020
>>>>      range -((2 ** 31 - 1) * 0.020) ..
>>>>            +((2 ** 31 - 1) * 0.020);
>>>>    for Duration'Small use 0.020;
>>>> 
>>>> I can understand the 32-bit vs 64-bit part - a misguided attempt at
>>>> efficiency, perhaps - but who gets to say that the clock runs at 50
>>>> Hz?
>
>> Duration'small is not related to the accuracy of the hardware clock,
>> it's just the elementary step for time. Ada.Real_Time might be more
>> useful for you.
>
> This is for a Ravenscar RTS, so I have to use Ada.Real_Time.
>
> in GNAT, Ada.Real_Time.Time and Time_Span are both new Durations.
>
> I find the "elementary step for time" concept somewhat confusing. I have
> a clock which ticks every millisecond, but the 32-bit Standard.Duration,
> Ada.Real_Time.Time, and Ada.Real_Time.Time_Span all have the same
> granularity of 20 ms!

I get the point, now.

I've put this in Ada.Real_Time:

      Time_Unit  : constant := 1.0e-9;

      [...]

   private
      type Time_Base is
        delta 0.000000001
        range -((2 ** 63 - 1) * 0.000000001) .. +((2 ** 63 - 1) * 0.000000001);
      for Time_Base'Small use 0.000000001;
      --  Replaces Duration, which has a different representation on
      --  systems with 32-bit Duration.

      type Time is new Time_Base;

      [...]

      type Time_Span is new Time_Base;

      [...]

      Time_Span_Unit  : constant Time_Span := 1.0e-9;

      Tick : constant Time_Span := 0.001;

> Oh. AdaCore's arm-eabi Ada.Real_Time works with very low-level stuff to
> provide for 50 years of running, and doesn't use Duration. For the
> present work, I'm quite happy not to meet that requirement!

They're based on the processor high-res time base, which is typically a
32-bit register that overflows after 7 seconds ... so lots of work
extending that to the 50 years requirement.

When I worked with PowerPC boards (from Radstone, now part of GE
Intelligent Platforms) the on-board crystals were good for 50 ppm, about
5 seconds/day, so after 50 years that's over a day!

My present implementation is only valid up to 10 days. Quite good enough
for school projects, I think, but will consider extending.

> It would be good to work out why my clock is running fast by almost a
> factor of 2 ...

With the above changes, all is good.