Interrupt

[arga]

I'm new to CCS C.
When an interrupt is called, say a serial interrupt or a TMR2 interrupt, is it *automatically disabled* whilst the interrupt routine is still being handled and *automatically enabled* once you finish processing it?

What happens if, say the serial interrupt is still being processed and a TMR2 interrupt occurs or vice versa?
Or is it that if any interrupt occurs the global interrupt is disabled? If so, is this automatically enabled once finished with the processing?
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516982

[Castle Buff]

:=I'm new to CCS C.
:=When an interrupt is called, say a serial interrupt or a TMR2 interrupt, is it *automatically disabled* whilst the interrupt routine is still being handled and *automatically enabled* once you finish processing it?
:=
:=What happens if, say the serial interrupt is still being processed and a TMR2 interrupt occurs or vice versa?
:=Or is it that if any interrupt occurs the global interrupt is disabled? If so, is this automatically enabled once finished with the processing?

The compiler should turn off the interupt in the handling routine automatically. You can see this by opening up the .lst file after a compile.

You will need to be carefull about the other interupts in your code. Often you will want to do an disable global upon entering interupt routines.

You can also read up on interupt prioritization. The compiler allows you to set this, but I haven't bother yet on any of my projects.

Good luck!
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516983

[PCM programmer]

:=:=I'm new to CCS C.
:=:=When an interrupt is called, say a serial interrupt or a TMR2 interrupt, is it *automatically disabled* whilst the interrupt routine is still being handled and *automatically enabled* once you finish processing it?
:=:=
:=:=What happens if, say the serial interrupt is still being processed and a TMR2 interrupt occurs or vice versa?

Whichever interrupt occurs first will be handled first.
Then the 2nd pending interrupt will be handled.
If they both occur within a few micro-seconds of each other,
then the order of execution is determined by the order
of the tests that are placed in the CCS interrupt dispatcher
code. You can set this order by using the #priority statement.
If you don't use a #priority statement, the order of execution
may not be the one that you would prefer. Or, it may not
matter in your program. In that case, you can leave off the
#priority statement.

:=:=Or is it that if any interrupt occurs the global interrupt is disabled? If so, is this automatically enabled once finished with the processing?

Yes, that's true. See the explanation below.

:=
:=The compiler should turn off the interupt in the handling routine automatically. You can see this by opening up the .lst file after a compile.
:=
:=You will need to be carefull about the other interupts in your code. Often you will want to do an disable global upon entering interupt routines.

That's not true. The PIC turns off the GIE bit in hardware
when the interrupt occurs. When your interrupt service routine
finishes executing, some cleanup code will be executed in the
CCS interrupt dispatcher, and then a RETFIE instruction will
be executed. The RETFIE instruction will re-enable global
interrupts by setting the GIE bit. So, it's all handled for
you. You don't have to worry about disabling/enabling global
interrupts in your interrupt routines.

:=
:=You can also read up on interupt prioritization. The compiler allows you to set this, but I haven't bother yet on any of my projects.
:=
:=Good luck!
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516984

[Castle Buff]

:=:=:=I'm new to CCS C.
:=:=:=When an interrupt is called, say a serial interrupt or a TMR2 interrupt, is it *automatically disabled* whilst the interrupt routine is still being handled and *automatically enabled* once you finish processing it?
:=:=:=
:=:=:=What happens if, say the serial interrupt is still being processed and a TMR2 interrupt occurs or vice versa?
:=
:=Whichever interrupt occurs first will be handled first.
:=Then the 2nd pending interrupt will be handled.
:=If they both occur within a few micro-seconds of each other,
:=then the order of execution is determined by the order
:=of the tests that are placed in the CCS interrupt dispatcher
:=code. You can set this order by using the #priority statement.
:=If you don't use a #priority statement, the order of execution
:=may not be the one that you would prefer. Or, it may not
:=matter in your program. In that case, you can leave off the
:=#priority statement.
:=
:=:=:=Or is it that if any interrupt occurs the global interrupt is disabled? If so, is this automatically enabled once finished with the processing?
:=
:=Yes, that's true. See the explanation below.
:=
:=:=
:=:=The compiler should turn off the interupt in the handling routine automatically. You can see this by opening up the .lst file after a compile.
:=:=
:=:=You will need to be carefull about the other interupts in your code. Often you will want to do an disable global upon entering interupt routines.
:=
:=That's not true. The PIC turns off the GIE bit in hardware
:=when the interrupt occurs. When your interrupt service routine
:=finishes executing, some cleanup code will be executed in the
:=CCS interrupt dispatcher, and then a RETFIE instruction will
:=be executed. The RETFIE instruction will re-enable global
:=interrupts by setting the GIE bit. So, it's all handled for
:=you. You don't have to worry about disabling/enabling global
:=interrupts in your interrupt routines.
:=
:=:=
:=:=You can also read up on interupt prioritization. The compiler allows you to set this, but I haven't bother yet on any of my projects.
:=:=
:=:=Good luck!

He is correct ...

What I meant to explain is often I will use my interrupt routines to set flags and handle the flags in another section of code. This is useful when detecting a button press that then needs to update the display. The display update occurs outside of the button interrupt, but requires that the interupt be manually turned off until the update is complete.

Good luck ;)
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516996

[R.J.Hamlett]

:=I'm new to CCS C.
:=When an interrupt is called, say a serial interrupt or a TMR2 interrupt, is it *automatically disabled* whilst the interrupt routine is still being handled and *automatically enabled* once you finish processing it?
:=
:=What happens if, say the serial interrupt is still being processed and a TMR2 interrupt occurs or vice versa?
:=Or is it that if any interrupt occurs the global interrupt is disabled? If so, is this automatically enabled once finished with the processing?

A device interrupting, sets it's own 'interrupt flag'. When an interrupt flag is set, and that device has it's interrupt enabled, the interrupt routine will be called. As soon as the interrupt routine is called, this does a global interrupt disable, _but does not prevent other interrupt flags from being set_. This routine, then checks the interrupt flags, to see what device generated the interrupt, and calls it's handler. At the end of the interrupt routine, the compiler clears the interrupting devices interrupt flag (hence if there was a second interrupt from the _same_ device, this would now be 'lost'). The interrupt handler, now exits with a 'RETFIE' instruction, which re-enables the global interrupt. At this point, if another interrupt flag is set, the interrupt handler will now be called again.
The interrupt flags in the handler, are checked in the order defined in the '#priority' instruction. Hence even on chips that don't support hardware priorities, it is worth putting the routines that must be handled with least latency at the start of the list for this instruction, since then if two flags get set in the few uSec between the interrupt routine being called, and the checking being done, it will be the 'high priority' routine that gets preferrence.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144517000