Connecting To Interrupts Using Protected Procedures

Connecting To Interrupts Using Protected Procedures

[Marin David Condic]

I'm looking at trying to convert an Ada83 method of handling interrupts
into the Ada95 preferred technique and am a bit puzzled as to how to go
about it. What we've been doing is connecting an entry in one task (or
connecting a procedure) to an interrupt that goes off every milisecond.
The task/procedure does some work and on every Nth cycle it initiates a
slower cycle task by calling a parameterless entry or initiating an
interrupt to which the entry is tied. (Not both at the same time - just
two different ways we have done it.)

Now Ada95 allows this as per ARM J.7.1 etc. but given that it is
considered obsolete, I'd like to do it by the preferred method. So I've
looked at connecting the 1ms interrupt to a protected procedure and this
all looks pretty straightforward. The problem is getting this protected
procedure to periodically kick off the slower cycle task. According to
ARM 9.5.1(8..17) you can't call an entry from there without creating a
bounded error. (Maybe it will run, but only if the system can't detect
it and raise Program_Error.) So how is it that the protected procedure
should communicate to the slower task to start cycling? You want the
slower task to be blocked until its time cycle comes around again, so
you would naturally think of some form of entry - but so far as I can
see, I've got no way of legally doing that. I suppose one could poll a
shared variable until the interrupt handler set the flag, but polling
answers are just not practical in this arena. (Ideally, you would want
to implement this with a clock and a delay statement, but the hardware
doesn't support this at the moment.)

Does anybody have a suggested method of doing this? Possibly with a code
snippet or two to illustrate? Thanks in advance.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Crime does not pay ... as well as politics."

        --  A. E. Newman

Re: Connecting To Interrupts Using Protected Procedures

[Pat Rogers]

Marin David Condic wrote in message <36CB42FA.FDD195CF@pwfl.com>...

<snip>

>Now Ada95 allows this as per ARM J.7.1 etc. but given that it is
>considered obsolete, I'd like to do it by the preferred method. So
I've
>looked at connecting the 1ms interrupt to a protected procedure and
this
>all looks pretty straightforward. The problem is getting this
protected
>procedure to periodically kick off the slower cycle task. According
to
>ARM 9.5.1(8..17) you can't call an entry from there without creating
a
>bounded error. (Maybe it will run, but only if the system can't
detect
>it and raise Program_Error.) So how is it that the protected
procedure
>should communicate to the slower task to start cycling? You want the
>slower task to be blocked until its time cycle comes around again, so
>you would naturally think of some form of entry - but so far as I can
>see, I've got no way of legally doing that. I suppose one could poll
a
>shared variable until the interrupt handler set the flag, but polling
>answers are just not practical in this arena. (Ideally, you would
want
>to implement this with a clock and a delay statement, but the
hardware
>doesn't support this at the moment.)



It sounds like you should have the slower task call and suspend on an
entry in the interrupt handler protected object, and have the
interrupt handler procedure set a flag (inside that same PO) that
allows that entry call to proceed whenever appropriate (ie on the Nth
cycle).  The flag is false until the interrupt handler (procedure)
determines that it is appropriate for the task to return from the
call.

That's the way I interpret what you're saying anyway -- I may have
misunderstood what you want to happen!

HTH,


---
Pat Rogers                          Training & Development in:
http://www.classwide.com    Deadline Schedulability Analysis
progers@classwide.com         Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: Connecting To Interrupts Using Protected Procedures

[Pat Rogers]

Marin wrote:

>>Now Ada95 allows this as per ARM J.7.1 etc. but given that it is
>>considered obsolete, I'd like to do it by the preferred method. So
I've
>>looked at connecting the 1ms interrupt to a protected procedure and
this
>>all looks pretty straightforward. The problem is getting this
protected
>>procedure to periodically kick off the slower cycle task. According
to
>>ARM 9.5.1(8..17) you can't call an entry from there without creating
a
>>bounded error. (Maybe it will run, but only if the system can't
detect
>>it and raise Program_Error.) So how is it that the protected
procedure
>>should communicate to the slower task to start cycling? You want the
>>slower task to be blocked until its time cycle comes around again,
so
>>you would naturally think of some form of entry - but so far as I
can
>>see, I've got no way of legally doing that. I suppose one could poll
a
>>shared variable until the interrupt handler set the flag, but
polling
>>answers are just not practical in this arena. (Ideally, you would
want
>>to implement this with a clock and a delay statement, but the
hardware
>>doesn't support this at the moment.)


and I wrote:

>It sounds like you should have the slower task call and suspend on an
>entry in the interrupt handler protected object, and have the
>interrupt handler procedure set a flag (inside that same PO) that
>allows that entry call to proceed whenever appropriate (ie on the Nth
>cycle).  The flag is false until the interrupt handler (procedure)
>determines that it is appropriate for the task to return from the
>call.


Since you asked for a snippet of code:


with System;
with Ada.Interrupts;

package IO is

  N : constant := 1000;  -- whatever

  Device_Priority : constant System.Interrupt_Priority   :=
System.Interrupt_Priority'Last; -- whatever
  Device_Id       : constant Ada.Interrupts.Interrupt_Id := 0; --
whatever


  protected Handler is
    entry Wait;
    pragma Interrupt_Priority( Device_Priority );
  private
    procedure Handle_Interrupt;
    pragma Attach_Handler( Handle_Interrupt, Device_Id );
    Count : Integer range 0 .. N := 0;
    Enable_Waiting_Caller : Boolean := False;
  end Handler;

end IO;


package body IO is

  protected body Handler is

    entry Wait when Enable_Waiting_Caller is
    begin
      Count := 0;
      Enable_Waiting_Caller := False;
    end Wait;

    procedure Handle_Interrupt is
    begin
      -- do stuff, including incrementing Count
      if Count = N then
        Enable_Waiting_Caller := True;
      end if;
    end Handle_Interrupt;

  end Handler;


end IO;

Re: Connecting To Interrupts Using Protected Procedures

[Marin David Condic]

Pat Rogers wrote:
> 
> 
> Since you asked for a snippet of code:
> 
<snip>
I also received help from David Brown wherein he posted the code
attached. Very similar answers so it seems this is a fairly common way
to go. I appreciate all the help on this. Now the only question we'll
have to answer is how efficient/inefficient the various features may
be...

MDC
===========================================================================

I think this is similar to what you want.  Feel free to post this.
I'm having problems with the configuration of my newsreader, and am
having trouble posting.

   ...

   Tick_Divider : constant := 9;

   protected Pclock is
      entry Wait;
      procedure Tick;
      pragma Attach_Handler (Tick, Ada.Interrupts.Names.SIGINT);
   private
      Counter : Natural := 0;
   end Pclock;

   protected body Pclock is
      entry Wait when Counter > Tick_Divider is
      begin
         Counter := 0;
      end Wait;

      procedure Tick is
      begin
         Counter := Counter + 1;
      end Tick;
   end Pclock;

   task Waiter is
   end Waiter;

   task body Waiter is
   begin
      loop
         Pclock.Wait;
         Ada.Text_IO.Put_Line ("Got slower ticks");
      end loop;
   end Waiter;

==========================================================================

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Crime does not pay ... as well as politics."

        --  A. E. Newman

Re: Connecting To Interrupts Using Protected Procedures

[Matthew Heaney]

Couldn't you reverse the calling sequence?  And have the slower task
call an entry of the interrupt handler?  

The interrupt handler can block its call, until the interrupt comes in.




Marin David Condic <condicma@bogon.pwfl.com> writes:

> I'm looking at trying to convert an Ada83 method of handling interrupts
> into the Ada95 preferred technique and am a bit puzzled as to how to go
> about it. What we've been doing is connecting an entry in one task (or
> connecting a procedure) to an interrupt that goes off every milisecond.
> The task/procedure does some work and on every Nth cycle it initiates a
> slower cycle task by calling a parameterless entry or initiating an
> interrupt to which the entry is tied. (Not both at the same time - just
> two different ways we have done it.)
> 
> Now Ada95 allows this as per ARM J.7.1 etc. but given that it is
> considered obsolete, I'd like to do it by the preferred method. So I've
> looked at connecting the 1ms interrupt to a protected procedure and this
> all looks pretty straightforward. The problem is getting this protected
> procedure to periodically kick off the slower cycle task. According to
> ARM 9.5.1(8..17) you can't call an entry from there without creating a
> bounded error. (Maybe it will run, but only if the system can't detect
> it and raise Program_Error.) So how is it that the protected procedure
> should communicate to the slower task to start cycling? You want the
> slower task to be blocked until its time cycle comes around again, so
> you would naturally think of some form of entry - but so far as I can
> see, I've got no way of legally doing that. I suppose one could poll a
> shared variable until the interrupt handler set the flag, but polling
> answers are just not practical in this arena. (Ideally, you would want
> to implement this with a clock and a delay statement, but the hardware
> doesn't support this at the moment.)
> 
> Does anybody have a suggested method of doing this? Possibly with a code
> snippet or two to illustrate? Thanks in advance.
> 
> MDC
> -- 
> Marin David Condic
> Real Time & Embedded Systems, Propulsion Systems Analysis
> United Technologies, Pratt & Whitney, Large Military Engines
> M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
> Ph: 561.796.8997         Fx: 561.796.4669
> ***To reply, remove "bogon" from the domain name.***
> 
>     "Crime does not pay ... as well as politics."
> 
>         --  A. E. Newman

Re: Connecting To Interrupts Using Protected Procedures

[robert_dewar]

In article <36CB42FA.FDD195CF@pwfl.com>,
  diespammer@pwfl.com wrote:

> Now Ada95 allows this as per ARM J.7.1 etc. but given
> that it is considered obsolete, I'd like to do it by the
> preferred method.

Please, obsolescent, not obsolete. The rules in Annex J
are just as normative as anything else in the RM. They
simply represent the design team's opinion of features
they would have preferred not to support, if they had
had a choice.

I think the likelyhood of ANY of the annex J features ever
being removed fr om the language is zero. Why on earth
cause
significant back compatibility problems for no good reason?

In this particular case, I actually prefer the Ada 83 style
of interrupts. I think it is a much cleaner interface from
a conceptual point of view, and it allows the program
counter to be used to encode the state of the interrupt
handler process.

As far as hardware goes, machine interrupt structure exists
that reflects both models. All ia32 (x86) machines for
example support a hardware model of interrupts essentially
identical to the J.7.1 method.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Connecting To Interrupts Using Protected Procedures

[Marin David Condic]

robert_dewar@my-dejanews.com wrote:
> 
> Please, obsolescent, not obsolete. The rules in Annex J
> are just as normative as anything else in the RM. They
> simply represent the design team's opinion of features
> they would have preferred not to support, if they had
> had a choice.

Hair splitting. The annex says that an implementation *may* provide the
feature, which by my understanding of "may" means they may equally well
*not* implement it. Granted, we usually get from real-time compiler
vendors mechanisms that are necessary for doing the job, but its nice to
know what sort of things you can count on.

> 
> I think the likelyhood of ANY of the annex J features ever
> being removed fr om the language is zero. Why on earth
> cause
> significant back compatibility problems for no good reason?

Probably a good way to bet, but again, considering that the mechanism is
an optional item, I would imagine that over time, compiler writers will
discontinue implementing/supporting it. (Unless guys like me are willing
to shell out the big bucks to keep the feature in ;-)

> 
> In this particular case, I actually prefer the Ada 83 style
> of interrupts. I think it is a much cleaner interface from
> a conceptual point of view, and it allows the program
> counter to be used to encode the state of the interrupt
> handler process.
> 
I prefer it because it is what I know. It has worked well in the past
and I'd agree that it is conceptually clean. However, there are some
obvious inefficiencies and problems in making a task entry an interrupt
handler if the task has to support the full range of features that
"normal" tasks can do. This is why the ARM restricts protected
procedures used as interrupt handlers from doing various things like
making entry calls. When we want to handle an interrupt, we just want to
context-switch and go - not run through the whole scheduler. :-)


> As far as hardware goes, machine interrupt structure exists
> that reflects both models. All ia32 (x86) machines for
> example support a hardware model of interrupts essentially
> identical to the J.7.1 method.
> 
I'd bet that for a while at least, we will get support for entry
interrupt handlers from the real-time compiler vendors. I'd still like
to experiment with the alternatives to find out how fast they work and
what advantages/pitfalls there may be. The world turns and we are all
forced to learn new things or become an impediment to the business we
are in.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Crime does not pay ... as well as politics."

        --  A. E. Newman

Re: Connecting To Interrupts Using Protected Procedures

[robert_dewar]

In article <36CC3CA5.F497700A@pwfl.com>,
  diespammer@pwfl.com wrote:
> Hair splitting. The annex says that an implementation
> *may* provide the feature, which by my understanding of
> "may" means they may equally well *not* implement it.
> Granted, we usually get from real-time compiler vendors
> mechanisms that are necessary for doing the job, but its
> nice to know what sort of things you can count on.

Generally a reasonable point of view, but not applicable
here, the set of interrupts supported by either of the
two techniques in the RM is completely implementation
dependent, so you cannot count on either being present.
A compiler that provided only the Annex J way of doing
things is odd, but not non-conformant.


> > I think the likelyhood of ANY of the annex J features
> > ever being removed fr om the language is zero. Why on
> > earth cause significant back compatibility problems for
> > no good reason?
>
> Probably a good way to bet, but again, considering that
> the mechanism is an optional item, I would imagine that
> over time, compiler writers will discontinue
> implementing/supporting it. (Unless guys like me are
> willing to shell out the big bucks to keep
> the feature in ;-)

What we implement has to do with what customers want, not
whether a feature is optional or not. After all the entire
annexes, including the entire interrupt feature is
optional!
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own