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!mx02.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: Ravenscar and context switching for Cortex-M4 Date: Thu, 12 Feb 2015 23:28:18 +0200 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net XZbxIMou9d7f9QjXOZSMygt/X+w9KHBrngr+/J6TgP5KVV24TZ Cancel-Lock: sha1:NA1fnAnob06cS29RFGp+g1MCFB8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:24955 Date: 2015-02-12T23:28:18+02:00 List-Id: On 15-02-12 22:25 , Patrick Noffke wrote: > I am porting the GNAT Ravenscar-sfp runtime to work with the TI TM4C > MCU, using the STM32F4 implementation as a starting point. I am > having a problem where one of two tasks blocked on entries (each in > separate protected objects) is not getting activated. Can't help you with that, sorry... but hurrah! for working on Ada run-times for microcontrollers. > According to > http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug/the_predefined_profiles.html#ada-restrictions-in-the-ravenscar-profiles, > at most one task may be queued on an entry. I take this to mean *on > a single entry* and that two tasks may be simultaneously queued on > separate entries. Is that correct? Definitely correct. In typical Ravenscar applications, at any one time there are many tasks queued on entries, but at most one task is queued on each entry at the same time. In some Ravenscar design guidelines, it is suggested that there should be a static association between task and entry, so that for each entry there is exactly one task that ever queues on this entry. This guideline ensures that there is no risk of two or more tasks ever queuing on the same entry at the same time, but I believe that the profile does not require this design rule -- it is allowed for more than one task to queue on the same entry, as long as they do not do it at the same time. In other words, the entry-queue length should never be more than one in a Ravenscar system (which means that it is not necessary to implement actual entry queues in the run-time). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .