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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.58.43.161 with SMTP id x1mr5415922vel.18.1391776487537; Fri, 07 Feb 2014 04:34:47 -0800 (PST) X-Received: by 10.140.37.18 with SMTP id q18mr38138qgq.20.1391776487514; Fri, 07 Feb 2014 04:34:47 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!v102.xanadu-bbs.net!xanadu-bbs.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!f11no13402421qae.1!news-out.google.com!y18ni5460qap.1!nntp.google.com!k15no13382284qaq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 7 Feb 2014 04:34:47 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=189.77.226.1; posting-account=TRgI1QoAAABSsYi-ox3Pi6N-JEKKU0cu NNTP-Posting-Host: 189.77.226.1 References: <5e8fad3a-94e6-4517-af54-db8b4146803e@googlegroups.com> <858uto3cj3.fsf@stephe-leake.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Raspberry Pi, Real-Time and Ada From: "Rego, P." Injection-Date: Fri, 07 Feb 2014 12:34:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3349 X-Received-Body-CRC: 1906822045 Xref: news.eternal-september.org comp.lang.ada:18423 Date: 2014-02-07T04:34:47-08:00 List-Id: On Friday, February 7, 2014 6:42:41 AM UTC-2, Dmitry A. Kazakov wrote: > I don't think that 10ms would be a problem even for ARM. > On an Intel board 200=B5s loops (read inputs, calculate, write outputs) a= re > doable. It turns things much better.=20 > Ada has everything you need for that. That is always as good as it sound :-) > The main problem is how good the RT clock is. Windows and VxWorks typical= ly > have miserable RT clock services on x86. x86 Linux has a decent one. Ok. > Regarding ARM Linux, I didn't tested its clock, so I cannot tell. The > primary test is to call Ada.Real_Time.Clock twice and to compare if the > reading is same. If they are you should look for an alternative > implementation of. The second test is to measure how close delay 1.0 is t= o > 1 second using Ada.Real_Time.Clock. The deviation from 1s tells how coars= e > OS programmable timer services are. There are OS means to attune that (on > the performance cost). > Once you have Ada.Real_Time.Clock it is no problem to measure the control > loop your system does. Usually you would measure several thousands of > cycles to get min, max and average times. If you have background services > to run, you do measures under load (with other services) and without load= . Great. I think it will cover most of what I need to know. > The OS latencies (in the driver etc) is a more difficult stuff. If the OS > does not have means to measure these times (VxWorks has), you still can > estimate these by subtracting known durations from the whole cycle time. Do you remember how can be done on VxWorks? (it could be also good to test = it on VxWorks just for curiosity). So I can try to find an alike alternativ= e, maybe in Xenomai it is available. > You can also use digital outputs which are considerably faster than > analogue ones and the oscilloscope, etc. You can calibrate digital output > times by measuring many thousands of write-cycles and taking the mean. Ok. This will complement the tests. Great. -- Regards, Rego.