From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Duration for GNAT on ARM Date: Wed, 24 Dec 2014 09:40:30 +0000 Organization: A noiseless patient Spider Message-ID: References: <14woqdx7yg0ry.eghy2k6aafqc.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="da19c0dc8eec016b1dd8c302a793eb7c"; logging-data="19943"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cYSYcKwTspdGaAFHjf6pLU0B+tx2AeDM=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin) Cancel-Lock: sha1:6+rIknq2XeHRXP2uRJ/v9ZJAxsM= sha1:fuqz3QHxj9QsrE+UktN8kZL7dLM= Xref: news.eternal-september.org comp.lang.ada:24218 Date: 2014-12-24T09:40:30+00:00 List-Id: Simon Wright writes: > "J-P. Rosen" 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.