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!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Protected Objects and Interrupt Handlers Date: Tue, 23 Feb 2016 23:09:28 +0000 Organization: A noiseless patient Spider Message-ID: References: <7663896a-a15e-47fd-8c7e-54a1c20d8d0f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="03d977edd803a9f1bf346d48fa393156"; logging-data="15841"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19zn3TZjt7DTh2mSaMRA3y4NeSCMthUMF0=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Cancel-Lock: sha1:AOsntJ4cBEY8agcuf9mjtv/JpoE= sha1:CPDUOSMf0ag1psTOBHk3RGOWbBI= Xref: news.eternal-september.org comp.lang.ada:29595 Date: 2016-02-23T23:09:28+00:00 List-Id: Jere writes: > This is more of a curiosity, but I have noticed that a lot of embedded > Ada examples that I run across use a protected type object to wrap the > ISR for a particular interrupt. I was wondering why this is? Why not > just use a normal Ada procedure for an interrupt? I can understand > using a protected object to handle procedures used by different tasks, > but an ISR isn't a task per say. So how do Ada's protected type per se (Latin for "by itself" or "in itself") > object and procedure implementations work with interrupts? You could certainly use a procedure as an ISR, if you knew how to do it. You can see this being done in [1]; note needing to export the procedure, and set up its address in the interrupt vector table, also fun with the NVIC. But - in general - what is the ISR going to do in order to get the interrupt and associated data into the rest of the program? You'd hardly want the main program busy-waiting while polling to see whether interrupts have happened; might as well not use interrupts at all. A task is a thread of execution, and so is an interrupt, so it seems natural to use the same mechanism to do interrupt-to-task communication as for task-to-task; the originating task/interrupt calls a procedure in the PO which results in waking up the listening task. You may have traced the ARM stuff on interrupt handling (C.3ff, [2]). I wrote up how GNAT/Ravenscar deals with this at [3] (section "Interrupt handling", about 2/3 of the way down). [1] http://www.inspirel.com/articles/Ada_On_Cortex_Interrupts.html [2] http://www.ada-auth.org/standards/12rm/html/RM-C-3.html [3] http://forward-in-code.blogspot.co.uk/2015/06/building-runtime-system-for-arm-eabi.html