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

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

Here is the interrupt exit code produced by C18 including the "missing"=20
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:
> 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 =3D 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 =3D 0;            //clear interrupt flag
>        Flags.Bit.Timeout =3D 1;            //indicate timeout
>        LATBbits.LATB0 =3D !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 retf=
ie)
>
>
>
> void low_isr(void)
> {
>      if ((PIE1bits.TMR2IE =3D=3D 1)&&  (PIR1bits.TMR2IF =3D=3D 1)) {
>          PIR1bits.TMR2IF =3D 0;
>                 DisplayDigit(segment, display[segment]);
>      }
>      _asm
>          retfie 0
>      _endasm
> }
>
> #pragma code low_vector =3D 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 =3D 223;
>      RCONbits.IPEN    =3D 1; /* Interrupt priority enable */
>          IPR1bits.TMR2IP    =3D 0; /* TMR2 Low priority */
>       INTCONbits.GIEL =3D 1;
>         INTCONbits.GIEH =3D 1;
> }
>
> void main()
> {
>      TRISD =3D 0;
>      TRISC =3D 0;
>      init_timer2();
>
>      while (1) {
>
>          }
> }
>
> Thanks,
> Manu

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.