Interrupts

Interrupts

[USERS]

Hi everyone,

I'm working on an ada application requiring the use of interrupts.
I understand you can use tasks to trap interrupts, but haven't
tested it.

task service is
  entry ISR;
  for ISR use at 16#xxx#;
end service;

My question is: instead of using the overhead of tasks, is it
possible to tie the interrupt directly to a procedure?

procedure ISR is
end ISR;
for ISR use at 16#xxx#;

Any advice or comments is appreciated. Thanks in advance.

Duc Le
email:
led@sunfs1.dsd.northrop.com

Interrupts

[Dat Trie u Le]

Hi everyone,

I'm working on an ada application requiring the use of interrupts.
I understand you can use tasks to trap interrupts, but haven't
tested it.

task service is
  entry ISR;
  for ISR use at 16#xxx#;
end service;

My question is: instead of using the overhead of tasks, is it
possible to tie the interrupt directly to a procedure?

procedure ISR is
end ISR;
for ISR use at 16#xxx#;

Any advice or comments is appreciated. Thanks in advance.

Re: Interrupts

[Bob Kitzberger]

dl10696@ehsn4.cen.uiuc.edu (Dat Trieu Le) writes:

>task service is
>  entry ISR;
>  for ISR use at 16#xxx#;
>end service;
>
>My question is: instead of using the overhead of tasks, is it
>possible to tie the interrupt directly to a procedure?

It's something of a non-sequiter that tasks themselves have too much
overhead.  There are _characteristics_ of tasks that incur varying
amounts of overhead, such as context switch time, interrupt latency,
interrupt lockout, frequency of interaction, stack usage, etc.

In the case of interrupt handling, the main concern is usually
interrupt latency.  Most Ada vendors support interrupt entries for
tasks, and many provide features specifically geared towards reducing
the interrupt latency of task entries to a point where they're just
about as quick to respond as interrupt handling procedures.  Basically,
the approach is to tie the task's interrupt entry to the interrupt
vector with a minimal amount of preambl and postamble processing.
This is usually just a handful of assembly instructions  to
save registers, swap in the new task's stack limits, and jump
directly to the interrupt entry.

TeleSoft calls this optimization "function mapped" entries, and Verdix
calls theirs "passive interrupt tasks".  There are subtle differences,
but both allow the task entry to make a call to another task, as long
as that call is guaranteed not to block.  Other vendors have similar
capabilities, and your mileage may vary.

Of course, you can still use the conventional model of tying subprogram
addresses to interrupt vectors.  Even in this case, your vendor will
probably provide some sort of capability for you to do this painfully
(usually a generic package, where one of the generic actual parameters
is the interrupt service routine) . 

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888

Re: Interrupts

[destroyer!cs.ubc.ca!utcsri!newsflash.concordia.ca!nstn.ns.ca!jmacleod]

In article <1993Feb17.161508.30722@iitmax.iit.edu> LEDUC@chico.acc.iit.edu (USE
RS) writes:
>Hi everyone,

>I'm working on an ada application requiring the use of interrupts.
>I understand you can use tasks to trap interrupts, but haven't
>tested it.

>task service is
>  entry ISR;
>  for ISR use at 16#xxx#;
>end service;

>My question is: instead of using the overhead of tasks, is it
>possible to tie the interrupt directly to a procedure?

>procedure ISR is
>end ISR;
>for ISR use at 16#xxx#;

>Any advice or comments is appreciated. Thanks in advance.

>Duc Le
>email:
>led@sunfs1.dsd.northrop.com

I don't think the procedure would work.  All task gets activated when the 
mainline program gets activated.  Therefore it is actually waiting for 
something to happen at 16#xxx#.  A procedure is only active during its 
lifecycle.  Once the procedure has completed it needs some other procedure 
to activate it and cannot be activated beyond a procedural call.
Micronav International Inc
P.O.Box 1523 / 104 Marine Drive
Sydport Industrial Park,
Sydney, N.S. Canada B1P 6R7
Tel: 902-564-8833      Fax: 902-564-8764

Re: Interrupts

[agate!howland.reston.ans.net!sol.ctr.columbia.edu!eff!news.oc.com!convex!]

In article <jmacleod.79@fox.nstn.ns.ca> jmacleod@fox.nstn.ns.ca (James Mac Leod
) writes:
>In article <1993Feb17.161508.30722@iitmax.iit.edu> LEDUC@chico.acc.iit.edu (US
ERS) writes:
>>My question is: instead of using the overhead of tasks, is it
>>possible to tie the interrupt directly to a procedure?
>
>I don't think the procedure would work.  All task gets activated when the 
>mainline program gets activated.  Therefore it is actually waiting for 
>something to happen at 16#xxx#.  A procedure is only active during its 
>lifecycle.  Once the procedure has completed it needs some other procedure 
>to activate it and cannot be activated beyond a procedural call.

If you have a Verdix compiler, you can declare your interrupt-handling task
to be PASSIVE and drastically reduce the overhead.



-- 
Boris Pelakh		Ada Project Leader          pelakh@convex.com
		     Convex Computer Corporation
"If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek TNG.
			

Interrupts

[Szygula]

I need program in ADA for Interrupts service.

thanks.

szygula@szygula.prv.pl
Poland

Re: Interrupts

[Andrzej Lewandowski]

"Szygula" <szygula@szygula.prv.pl> wrote in message
news:93aklh$4mr$1@news.tpi.pl...
> I need program in ADA for Interrupts service.
>
> thanks.
>
> szygula@szygula.prv.pl
> Poland

See Chapter 11, Burns & Wellings, "Concurency in Ada". They present 2
more or less complete examples of using interrupts.

A.L.