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.188.84 with SMTP id cz20mr6988405icb.1.1409333063947; Fri, 29 Aug 2014 10:24:23 -0700 (PDT) X-Received: by 10.182.246.69 with SMTP id xu5mr27287obc.9.1409333063718; Fri, 29 Aug 2014 10:24:23 -0700 (PDT) Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!uq10no6834812igb.0!news-out.google.com!aw9ni0igc.0!nntp.google.com!uq10no6834801igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 29 Aug 2014 10:24:23 -0700 (PDT) In-Reply-To: <1ibla8yyj3ibm$.1lz0cmeu8ptp2.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2001:5b0:232d:e1e8:cb7:c298:eab2:eaa7; posting-account=qZVz2QoAAAAN9WxYp-9jYb7jORc4Zqwt NNTP-Posting-Host: 2001:5b0:232d:e1e8:cb7:c298:eab2:eaa7 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> <1ibla8yyj3ibm$.1lz0cmeu8ptp2.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9620b2bd-9275-4273-b7ef-166c7227783b@googlegroups.com> Subject: Re: STM32F4 Discovery, communication and libraries From: Mike Silva Injection-Date: Fri, 29 Aug 2014 17:24:23 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:188742 Date: 2014-08-29T10:24:23-07:00 List-Id: On Friday, August 29, 2014 12:34:06 AM UTC-7, Dmitry A. Kazakov wrote: > On Thu, 28 Aug 2014 13:34:58 -0700 (PDT), >=20 > Mike Silva wrote: >=20 > > Are you saying that a full Ada implementation on bare metal could not > > implement an equivalent of I/O queueing? >=20 > You could, but that would be equivalent to writing a small OS. This is certainly the case - a complete Ada runtime is more complex than e.= g. a complete C runtime, but it doesn't have to be built on an OS, and for = smaller systems a bare-metal implementation is often going to be more attra= ctive. Interestingly, the original Lego Mindstorms Ada port was built on a= n RTOS, but later they switched over to bare metal. >=20 > > Or are you saying that Ravenscar tasking on bare metal could not implem= ent > > such queueing? >=20 > Ravenscar tasking profile has serious constraints preventing this. The > nature of the constraints is to statically ensure schedulability. Asking > that much you must pay the price... That brings up two points relevant to this thread. One is to find out from= AdaCore how much more capability, if any, their current ARM Cortex M runti= me actually has beyond the Ravenscar constraints. I'd like to find that ou= t. Second is a brief comment I received from AdaCore, that they are looking at= another tasking subset that removes some of the Ravenscar limitations whil= e still allowing a small and fast bare-metal tasking implementation. In my= own words, I think they are looking for another sweet spot re functionaliy= vs runtime complexity, one that will be useful to designers not requiring = the guarantees that Ravenscar allows. It makes a lot of sense to think tha= t there could be other beneficial tasking/runtime profiles besides just Rav= enscar and full Ada.