Problem with HIGH Interrupts

galatar · Joined: 01 Oct 2008 Posts: 2

My code was working fine till I place next lines for HIGH interrupt on EXT1.

Previously my code starts like that:

Ttelmah · Guest

You need to place the interrupt handler routine, immediately after the line declaring the interrupt. The next 'instruction block', becomes the interrupt handler. Your next instruction block, is the #rom statement, not a function, hence won't work...

So:

n-squared · Joined: 03 Oct 2006 Posts: 99

Hi
You need to put the #int_EXT1 HIGH line just above the interrupt function itself.
Your sample code does not show enough detail to see the problem.

BR
_________________
Every solution has a problem.

Guest · Posted: Thu Oct 02, 2008 3:08 am

Thanks to Ttelmah and n-squared. Thank you very much! I

meereck · Joined: 09 Nov 2006 Posts: 173

it should be also noted that if you define

csanders · Joined: 23 Apr 2005 Posts: 16

Is it possible to have more than 1 ISR marked as 'HIGH'?

Ttelmah · Guest

Yes.

The behaviour of the system is fairly complex, but 'here goes'. There are two words that trigger moving the interrupt to the high priority vector, 'HIGH', and 'FAST'. When 'HIGH' is used, the compiler creates exactly the same code, as is used for the low priority handler. It automatically adds data saving code, tests for multiple interrupts if used, and jumps to the right handler. In fact on most chips this will _always_ happen, if you select as a 'HIGH' interrupt any interrupt other than INT_EXT, and then use INT_EXT as well, without adding the flag. If you look at the data sheet, there is no interrupt priority bit for INT_EXT, and if priorities are enabled, this interrupt always becomes a high priority source. This is very much a 'caveat' of the PIC. The compiler will handle this, automatically adding the test for this interrupt to the high priority code, even though it is not flagged as 'HIGH' by you.

If you instead use 'FAST', the compiler flags the selected interrupt as a high priority one, but does not add any data saving code, or tests for other interrupts. You can in fact use this as an alternative for 'INT_GLOBAL', with high priority interrupts. What you do, is flag one interrupt as 'FAST', and have it's handler save the minimum number of registers, then if necessary test for any other interrupts being triggered. All you then do is set the high priority bit, on any other interrupt you want as high priority, and this one handler will be called for all the interrupts. However remember to check for INT_EXT, if using this route.

The automatic behaviour of the chip, in making INT_EXT high priority, if priorities are enabled, is the core reason for problems if you set 'HIGH_INTS=true', and then don't use any interrupts as high priority. The compiler only adds the handler code, once one interrupt is flagged as 'HIGH' but as soon as the priorities are enabled, INT_EXT, will be vectoring to the high priority handler. Since there is no handler present, disaster....

Best Wishes