Searching \ for '[PIC]Interrupts with 18F4550 and C18' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'Interrupts with 18F4550 and C18'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]Interrupts with 18F4550 and C18'
2012\05\09@033001 by Manu Abraham

picon face
Hi,

The C18 example states that an interrupt handler is to be defined thus:
(in MCC18\examples\Interrupt\main.c)
//----------------------------------------------------------------------------
// High priority interrupt vector

#pragma code InterruptVectorHigh = 0x08
void
InterruptVectorHigh (void)
{
 _asm
   goto InterruptHandlerHigh //jump to interrupt routine
 _endasm
}

//----------------------------------------------------------------------------
// High priority interrupt routine

#pragma code
#pragma interrupt InterruptHandlerHigh

void
InterruptHandlerHigh ()
{
 if (INTCONbits.TMR0IF)
   {                                   //check for TMR0 overflow
     INTCONbits.TMR0IF = 0;            //clear interrupt flag
     Flags.Bit.Timeout = 1;            //indicate timeout
     LATBbits.LATB0 = !LATBbits.LATB0; //toggle LED on RB0
   }
}


But I can't seem to figure out why that INTCONbits.GIEH is disabled
after once it has run through the handler. In asm, the Global Interrupt
handler is enabled after a retfie, but with C18 and the 18F4550, this
doesn't seem to be the case, I do need a retfie as follows, for the
interrupt to be re enabled. Any idea why it is thus ?

Additionally, I have this question, the ISR is unconditionally jumping to
another function. Especially in an ISR, I can't really reason why that
would be a good practice ?  (Although I can assume that the functions
would expand to labels in asm. But still doesn't explain the missing retfie)



void low_isr(void)
{
   if ((PIE1bits.TMR2IE == 1) && (PIR1bits.TMR2IF == 1)) {
       PIR1bits.TMR2IF = 0;
              DisplayDigit(segment, display[segment]);
   }
   _asm
       retfie 0
   _endasm
}

#pragma code low_vector = 0x18
void low_vector (void)
{
   _asm goto low_isr _endasm
}

void init_timer2(void)
{
   OpenTimer2(TIMER_INT_ON & T2_PS_1_4 & T2_POST_1_1);
    PR2 = 223;
   RCONbits.IPEN    = 1; /* Interrupt priority enable */
       IPR1bits.TMR2IP    = 0; /* TMR2 Low priority */
    INTCONbits.GIEL = 1;
      INTCONbits.GIEH = 1;
}

void main()
{
   TRISD = 0;
   TRISC = 0;
   init_timer2();

   while (1) {

       }
}

Thanks,
Man

2012\05\09@105225 by Joe Wronski

flavicon
face
Without actually digging into the doc for the 18F part in the example (18C452 ?), I can give some answers:
o Unconditional goto is due to limited program space in the interrupt vector area.
o Retfie is generated by the compiler, probably due to the #pragma interrupt directive.  Look at View->Disassembly Listing after building.
o Can't speak to the GIE issue without further digging, but if it is disabled by the interrupt mechanism, your cods should re-enable it, unless it is implicitly done by the retfie.

There should be no differences in the chip operation whether using C or assembler.  Always look to the assembler produced by the compiler.

Here is the interrupt exit code produced by C18 including the "missing" retfie:

  00F2    52E5     MOVF 0xfe5, F, ACCESS
  00F4    CFE5     MOVFF 0xfe5, 0xfda
  00F6    FFDA     NOP
  00F8    0011     RETFIE 0x1

Joe W



On 5/9/2012 3:30 AM, Manu Abraham wrote:
{Quote hidden}

> Manu

2012\05\09@112120 by Bob Ammerman

flavicon
face
Just a guess...

If you misspell the name of the interrupt handler on the #pragma interrupt statement the compiler wouldn't know to end the routine with a RETFIE instead of a RETURN.

-- Bob Ammerman
RAm Systems

{Original Message removed}

2012\05\10@145301 by Manu Abraham

picon face
Yeah, that fixed the issue. That was a typo.

Best Regards,
Manu


On Wed, May 9, 2012 at 8:51 PM, Bob Ammerman <spam_OUTpicramTakeThisOuTspamroadrunner.com> wrote:
>
> Just a guess...
>
> If you misspell the name of the interrupt handler on the #pragma interrupt
> statement the compiler wouldn't know to end the routine with a RETFIE
> instead of a RETURN.
>
> -- Bob Ammerman
> RAm Systems
>
> {Original Message removed}

2012\05\10@145726 by Manu Abraham

picon face
On Wed, May 9, 2012 at 8:24 PM, Joe Wronski <.....jwronskiKILLspamspam@spam@stillwatereng.net> wrote:
{Quote hidden}

Missed the #pragma interrupt line here ..

{Quote hidden}

missed the #pragma here


This caused the retfie not to appear in the disassembly. Things are sane now.

Thanks,
Manu

More... (looser matching)
- Last day of these posts
- In 2012 , 2013 only
- Today
- New search...