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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31d67020d4b04d5b X-Google-Attributes: gid103376,public From: dennison@telepath.com Subject: Re: Simple Real_Time.Time_Span question Date: 1998/10/15 Message-ID: <705n7o$ro2$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 401452173 References: <6vvsgo$rvo$1@nnrp1.dejanews.com> <7003e4$534@hacgate2.hac.com> <700ic6$q1p$1@nnrp1.dejanews.com> <702oll$1v4$1@news.hal-pc.org> X-Http-Proxy: 1.0 x8.dejanews.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Thu Oct 15 20:51:04 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.05 [en] (WinNT; I) Date: 1998-10-15T00:00:00+00:00 List-Id: In article <702oll$1v4$1@news.hal-pc.org>, Jonathan Guthrie wrote: > Of course, the correct approach is either to count integral numbers of > ticks and then find the current time when you want to know it by > multiplying the tick count by the duration of each tick or to make sure > that the units of the time intervals are themselves integral. If, for > example, you have a 100Hz timer tick, measuring intervals in seconds and > fractions therein is not a good idea, but counting them in milliseconds > works just fine whether you're accumulating floating-point values or > integer. That is pretty much what I ended up doing (see my second post in this thread). The thing that bugs me about that is the large amount of work it involves, compared to what could have been done as part of the package (again, see my previous post). Even though this code has to be portable, I probably would have considered cheating and using Duration if I could have found any documentation from my compiler vendor on how it is implemented. Unfortunately, there seem to be *no* documentation requirements on Duration (unlike all *other* predefined types), so my vendor didn't bother to document it. Lucky me. The silly thing is that near as I can tell this is what the package is supposed to be there for. Needing to perform calculations based on elapsed time since the last iteration is part of what makes a real-time system. A typical R/T program will have a cycle rate of 60Hz or greater (ours is 240Hz, but may go up to 2KHz). But the numeric type Ada.Real_Time provides for this purpose (Duration) is only required by the laguage to support increments of 1/50th of a second! I don't think there is much doubt that the specification of Ada.Real_Time is seriously broken in this respect. Until this can be addressed properly, I would implore Ada vendors who support this annex to provide a child package with subprograms capable of converting between Float and Time_Span. I realize Float as a type has its problems too, but between Float and Duration I think we would have the needs of Real-time programs fairly well covered. -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own