Re: Protected Objects and Interrupt Handlers

[Simon Wright <simon@pushface.org>]

Jere <jere.groups@gmail.com> 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