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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: STM32F4 Discovery, communication and libraries Date: Fri, 29 Aug 2014 19:52:44 +0300 Organization: Tidorum Ltd Message-ID: 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> <1cd027f2-a0e0-4206-b989-4aed2090cde8@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net Isqgm3AhlOnrt74J3KtPbQH61vCNbALCb+NP/cM/IVBz9JPtIZ Cancel-Lock: sha1:qRo7dxvd3QMJSxfJIlMiifHFIDI= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:21990 Date: 2014-08-29T19:52:44+03:00 List-Id: On 14-08-29 16:06 , Dennis Lee Bieber wrote: > On Thu, 28 Aug 2014 13:34:58 -0700 (PDT), > embeddedrelatedmike@scriptoriumdesigns.com declaimed the following: > >> On Thursday, August 28, 2014 1:09:05 PM UTC-7, Dmitry A. Kazakov wrote: >>> Not really. OS is more than tasking, it is also a queueing mechanism, which >>> allows waiting for I/O completion in one task without blocking all other >>> tasks. >>> ...... >>> You could not implement an equivalent of I/O queueing under the Ravenscar >>> constraints. >> >> Are you saying that a full Ada implementation on bare metal could >> not implement an equivalent of I/O queueing? >> >> Or are you saying that Ravenscar tasking on bare metal could not implement >> such queueing? > > Have you looked at the list of restrictions that profile requires? > > Max_Task_Entries = 0 (which goes along with) > No_Select_Statements > > Max_Protected_Entries = 1 (effectively no queuing up for access to > protected objects by multiple tasks) > Simple_Barriers (plain T/F Boolean variable controlling entries) > > No_Relative_Delays (no "delay n" only "delay until m") > > Oh, and No_Abort_Statements (and a number of other restrictions) All Ravenscar restrictions are on the _tasking_ system, with the exception of No_Implicit_Heap_Allocation and forbidding the use of Ada.Calendar (but _explicit_ heap allocation remains possible). The rest of Ada remains in its full form. However, some Ravenscar run-time systems _also_ have other restrictions, for example limitations on the use of unconstrained array types in expressions. > It works if the entire system including the "user application" level is > built "as one". That same restriction holds for all standard Ada programs (with the possible exception of distributed programs -- I have no experience there). At bind time, all the compilation modules forming the program are identified and included in the program, and no other modules/code can be added later, unless the program dynamically links to plug-in libraries, which is not standard Ada. > It is NOT a very dynamic arrangement wherein you may plug > in a new sensor and have it magically install itself to some list of > sensors to be reported. It is certainly possible to write a Ravenscar program in which adding a new sensor can be done by adding a single line, "with My_New_Sensor", to the main subprogram. At elaboration time, My_New_Sensor can install its tasks and protected objects in the application's data structures. No problem. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .