Re: Interrupt Handler Problems

[claveman@cod.nosc.mil (Charles H. Sampson)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4018 bytes --]

In article <3784D1A2.5B40939C@pwfl.com>,
Marin David Condic  <diespammer@pwfl.com> wrote:
>I wrote:
>> 
>>      We're having a terrible time getting our code running in the new
>> environment.  The killer problem of the moment is interrupt handlers.
>> (We have a lot of them.)  Our handlers have been modified into protected
>> procedures, as required by Green Hills, but they don't seem to be seeing
>> the interrupts.  Green Hills assures us that interrupts are enabled when
>> the main program begins executing.  However, when we enable them our-
>> selves in a little test program, its interrupt handler begins working.
>> When we enable them in our "real" code, VxWorks blows up with a
>> workQPanic.  The three vendors are now in a finger-pointing contest (the
>> Navy term is ruder), each claiming that it's not their fault, it must be
>> caused by one of the others.
>> 
>
>I've had similar problems with connecting to interrupts with other
>compilers. Here's a couple of things to check: The interrupt handling
>routines are generally considered to be a kind of "task", if you will,
>in that compilers often create some sort of memory heap for them. If you
>have a lot of handlers and the memory reserved for each is by default
>large, you can blow the available memory and be standing there doing
>nothing with an unhandled exception. This could be why your little test
>program works fine, but the same thing scaled up to the "real" system
>won't run.

     I doubt that absolute memory usage is a problem, but we'll probably 
check it at some point.  Thanks.

>Also, it would help to know exactly how the RTK connects your ISRs to
>the interrupts. Do you get a "hard" connection where the address of your
>ISR is directly placed in the interrupt service vector? Or does the RTK
>step into the middle of it so that first the RTK is called, then
>(eventually) your ISR? The former is easier to deal with usually because
>you don't have to guess about what might be going on between the
>interrupt and you.

     An interrupt handler in VxWorks is not a task, it is a very re-
stricted procedure (void function in the documentation; VxWorks is very 
Unix-like).  Even working at the VxWorks/C level, the address of the in-
terrupt handler is not put directly into the vector.  Instead, when the 
call to set up a handler is made, VxWorks puts a little wrapper around 
it.  The wrapper does such things as setting up the stack and saving and 
restoring registers.  Green Hills Ada might also put a wrapper around 
the protected procedure, but their documentation implies not.

>Can you post a sample of the code that demonstrates how the ISR is coded
>& how you are connecting to the interrupts?

     Because of the restrictions on interrupt handlers under VxWorks, 
ours are absolutely minimal.  The technique for attaching the handler is 
pure Ada.  Here is an example (vertical white space removed):

     protected Handler_Object is
        procedure Start;
        procedure Handler;
         pragma Interrupt_Handler (Handler);
        entry Release_For_Processing;
     private
        Interrupt_Occurred : Boolean := False;
     end Handler_Object;

     protected body Handler_Object is
        procedure Start is
        begin
           Ada.Interrupts.Attach_Handler (Handler�Access, Vector_No);
        end Start;
        procedure Handler is
        begin
           Interrupt_Occurred := True;
        end Handler;
        entry Release_For_Processing when Interrupt_Occurred is
        begin
           Interrupt_Occurred := False;
        end Release_For_Processing;
     end Handler_Object;

     A call to Start is made to attach the handler.  Associated with the 
handler is a high priority task that we call an interrupt processor.  It 
hangs on the Release_For_Processing entry until an interrupt occurs and 
then does whatever is necessary to respond to the interrupt.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".