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.42.97.138 with SMTP id o10mr4302326icn.33.1409270840561; Thu, 28 Aug 2014 17:07:20 -0700 (PDT) X-Received: by 10.140.93.181 with SMTP id d50mr117494qge.0.1409270840225; Thu, 28 Aug 2014 17:07:20 -0700 (PDT) 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!news.linkpendium.com!news.linkpendium.com!news.snarked.org!newsfeed.news.ucla.edu!usenet.stanford.edu!r2no9532164igi.0!news-out.google.com!q8ni2qal.1!nntp.google.com!m5no3986815qaj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 28 Aug 2014 17:07:20 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=77.8.91.83; posting-account=Fmp50goAAAA9sbkA2aX-X9YQy6-lkg3J NNTP-Posting-Host: 77.8.91.83 References: <60a42dc6-d8d0-4432-ae5a-86de18b82840@googlegroups.com> <5kkrv9hejn2qhdckkeo8lidkbh3bkme1gn@4ax.com> <5b91313c-acf9-4a6e-b157-6ba7c8021567@googlegroups.com> <0513ad07-6fbe-463a-be6f-097cd5113f52@googlegroups.com> <4f1ec65a-d66a-40bf-a0d6-278fde206e70@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <776fc1ce-f7cf-4e33-b439-0cfe658305af@googlegroups.com> Subject: Re: STM32F4 Discovery, communication and libraries From: Roy Emmerich Injection-Date: Fri, 29 Aug 2014 00:07:20 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:21971 Date: 2014-08-28T17:07:20-07:00 List-Id: On Thursday, 28 August 2014 23:17:12 UTC+2, Niklas Holsti wrote: > On 14-08-28 23:09 , Dmitry A. Kazakov wrote: >=20 > > On Thu, 28 Aug 2014 09:28:15 -0700 (PDT), Mike Silva wrote: >=20 > >> On Thursday, August 28, 2014 6:00:12 AM UTC-7, Dmitry A. Kazakov wrote= : >=20 > >>> One of the responsibilities of the OS and the middleware is to perfor= m I/O > >>> on things like ModBus in background without blocking the application = and > >>> other I/O. Even a very lame board is usually much faster than any Mod= Bus > >>> terminal. >=20 > >> Maybe there is some confusion being caused by the term "OS" here. Ada= 's > >> concurrency and realtime functionality can run on top of an OS, but it= can > >> also run on bare metal (an "invisible" OS?). >=20 > > Not really. OS is more than tasking, it is also a queueing mechanism, w= hich > > allows waiting for I/O completion in one task without blocking all othe= r > > tasks. >=20 > >> The GNAT ARM Cortex M > >> release does have Ravenscar tasking on bare metal. >=20 > > You could not implement an equivalent of I/O queueing under the Ravensc= ar > > constraints. >=20 > It is certainly possible to implement an I/O request queue in Ravenscar; > I have done so for the platform SW on ESA's GOCE satellite. Multiple > client tasks, one server (interface driver) task. An I/O request > contains (or is, or refers to) a client-specific protected object (PO) > with an "I/O completed" entry, on which the client task waits after > enqueueing the I/O request. The server task processes submitted I/O > requests in any order and concurrency it chooses; when an I/O request is > done, the server task calls an operation on the request's PO, which > unblocks the entry, resuming the client task. As I know (almost) nothing about Ravenscar I decided to go reading and foun= d the following article: Guide for the use of the Ada Ravenscar Profile in high integrity systems http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf In the following sections: 2.1.1 Tasks Characteristics 2.1.2 Scheduling Model it very clearly describes what Niklas has pointed out. To go a little deeper into my design: Each sub-module will run in its own task with its own timer. If, for exampl= e, I am monitoring a solar photovoltaic inverter via MODBUS RTU, it is poss= ible to retrieve a lot of different information. Some information, like vol= tage and current, I may want to retrieve every second whereas other informa= tion like battery temperature I may only want to retrieve every 5 minutes. = The module will know the sampling frequency for each variable to be monitor= ed and will trigger itself when it is time to do so. Using protected objects and hard/firm/soft/non-critical tasks it sounds lik= e this could indeed be a viable approach. --- Roy Emmerich www.infinitefingers.com