Compiler saving context even with fast keyword present

[Bangheadondesk]

Hello,
Could anyone help me solve this problem. I have several low priority interrupts and the compiler handles the register saving and isr dispatching with no problem. I also have a high priority external interrupt which I declared like so:

#int_ext1 FAST HIGH
void fast_isr( void )
{
//save registers which will be modified
//check what interrupt fired if more than one high int present
//deal with the interrupt and reset its flag if neccesary

//restore original register contents
}

I have also added the following to my header file

#DEVICE HIGH_INTS=TRUE //enable fast interrupts

I am expecting the compiler to not try to save anything for me and just add a branch instruction at the high interrupt vector to my single high routine. When I look at the generated list file I get what appears to be two complete interrupt handlers, each running from the respective vectors. I have included a small portion of the list file below:

CCS PCH C Compiler, Version 3.233, 29143 09-Feb-06 11:36

Filename: main.LST

ROM used: 56360 bytes (86%)
Largest free fragment is 9074
RAM used: 2745 (69%) at main() level
3609 (91%) worst case
Stack: 15 worst case (8 in main + 7 for interrupts)

*
0000: GOTO DA00
*
0008: GOTO 00F0 //high int vector - follow code to address 00F0...
000C: NOP
000E: NOP
0010: NOP
0012: NOP
0014: NOP
0016: NOP
0018: MOVFF FE8,05 //low int vector - expect context saving here
001C: MOVFF FD8,06
0020: MOVFF FE0,07
0024: MOVLB 0
0026: MOVFF FE9,0D
002A: MOVFF FEA,08
002E: MOVFF FE1,09
0032: MOVFF FE2,0A
0036: MOVFF FD9,0B
003A: MOVFF FDA,0C
003E: MOVFF FF3,14
0042: MOVFF FF4,15
0046: MOVFF FFA,16
004A: MOVFF 00,0F
004E: MOVFF 01,10
0052: MOVFF 02,11
0056: MOVFF 03,12
005A: MOVFF 04,13
005E: BTFSS F9D.0
0060: GOTO 006A
0064: BTFSC F9E.0
0066: GOTO 3FE0
006A: BTFSS FF0.4
006C: GOTO 0076
0070: BTFSC FF0.1
0072: GOTO 2C40
0076: BTFSS F9D.5
0078: GOTO 0082
007C: BTFSC F9E.5
007E: GOTO 31E8
0082: BTFSS F9D.4
0084: GOTO 008E
0088: BTFSC F9E.4
008A: GOTO 3266
008E: BTFSS F9D.6
0090: GOTO 009A
0094: BTFSC F9E.6
0096: GOTO 2D50
009A: BTFSS FA0.4
009C: GOTO 00A6
00A0: BTFSC FA1.4
00A2: GOTO 304A
00A6: GOTO 2C02
00AA: MOVFF 0F,00
00AE: MOVFF 10,01
00B2: MOVFF 11,02
00B6: MOVFF 12,03
00BA: MOVFF 13,04
00BE: MOVFF 0D,FE9
00C2: MOVFF 08,FEA
00C6: MOVFF 09,FE1
00CA: MOVFF 0A,FE2
00CE: MOVFF 0B,FD9
00D2: MOVFF 0C,FDA
00D6: MOVFF 14,FF3
00DA: MOVFF 15,FF4
00DE: MOVFF 16,FFA
00E2: MOVFF 05,FE8
00E6: MOVFF 07,FE0
00EA: MOVFF 06,FD8
00EE: RETFIE 0
00F0: MOVLB 0 //this isn't my handler! and why the save?
00F2: MOVFF FE9,1E
00F6: MOVFF FEA,19
00FA: MOVFF FE1,1A
00FE: MOVFF FE2,1B
0102: MOVFF FD9,1C
0106: MOVFF FDA,1D
010A: MOVFF FF3,25
010E: MOVFF FF4,26
0112: MOVFF FFA,27
0116: MOVFF 00,20
011A: MOVFF 01,21
011E: MOVFF 02,22
0122: MOVFF 03,23
0126: MOVFF 04,24
012A: BTFSS FF2.4
012C: GOTO 0136
0130: BTFSC FF2.1
0132: GOTO 2C1E
0136: BTFSS FF0.3
0138: GOTO 0142
013C: BTFSC FF0.0
013E: GOTO 4038
0142: GOTO 2C02
0146: MOVFF 20,00
014A: MOVFF 21,01
014E: MOVFF 22,02
0152: MOVFF 23,03
0156: MOVFF 24,04
015A: MOVFF 1E,FE9
015E: MOVFF 19,FEA
0162: MOVFF 1A,FE1
0166: MOVFF 1B,FE2
016A: MOVFF 1C,FD9
016E: MOVFF 1D,FDA
0172: MOVFF 25,FF3
0176: MOVFF 26,FF4
017A: MOVFF 27,FFA
017E: RETFIE 1

Many thanks

[Ttelmah]

Get rid of the 'high' keyword.
CCS, uses retfie 1, if the 'fast' keyword is present. If the 'high' keyword is present, it adds it's own global interrupt handler for the high priority interrupts. This is what you are seeing. Use the fast keyword only. If an interrupt is set as 'fast', it'll have it's interrupt priority bit set to 'high' automatically.

Best Wishes

[Bangheadondesk]

Hi Ttlemah,
many thanks for the info, I have fixed the issue now.

[Ttelmah]

I like your 'title'. I have a reference here that I often use, to "wall, head impact technology testing", which is used when things get a bit annoying. It is nice when you stop. :-)

Best Wishes

[Bangheadondesk]

Ttlemah,
banging my head on the desk seems nicer at the moment than dealing with this compiler! I must have posted 10's of issues to CCS over the past few months, to there credit they have dealt with them all but where will it end...

You seem like a man who knows his stuff, I wonder if you could look over this and tell me what you think?

My latest whinge:

I have 3.233 (PCWH) and it seems that if #INT_EXT is declared whilst you have a fast interrupt present the compiler generates context saving code for the fast interrupt! See below

#include <18F4620.h>

#device *=16 ADC=10 WRITE_EEPROM=ASYNC
#device HIGH_INTS=TRUE
#use delay(clock= 40000000 )//Tells compiler the crystal speed, used to produce exact delays, rs232 baud etc.
#use rs232(baud=57600,xmit=pin_c6,rcv=pin_c7,stream=debug_port) //set up the RS232 port
#ZERO_RAM //Clear contents of ram at power up.
#priority timer1, EXT, EXT1, EXT2, rda, tbe, AD, EEPROM //define interrupt priority

//function definitions...

//global variables...

#int_default
void default_isr(void)
{
}

#int_ext noclear //with this present the compiler saves registers for #int_ext1 (fast)
void slow_isr( void )
{
}

#int_ext1 FAST noclear
void fast_isr( void )
{
}

void main(void)
{
enable_interrupts( INT_EXT );
enable_interrupts( INT_EXT1 );
enable_interrupts( GLOBAL );
}




PS: I like the phrase purcussive electrical maintenance

[Ttelmah]

I'm afraid this is not CCS's fault, but MicroChip's. If you look through the data sheet, there is no interrupt priority bit for 'int_ext'. The interrupt logic diagram, only show it as having a connection to the high priority 'tree'. Hence as soon as you enable this, you have two high priority interrupts, and the global handler becomes necessary. The same is true on quite of few of the 18 chips, and in some of the data sheets, there is a warning to this effect, but for some reason this is not present in the 4620 sheet.

Best Wishes

[Bangheadondesk]

Thanks for the reply, that makes sense.

The annoying and somehow strange thing is that originally I had my high priority interrupt connected to the external interrupt 0 pin but changed it after looking at the datasheet and noticing it didn't have a priority bit! I should have looked a little harder and discovered that as you say, it is high by default. We live to learn

Again many thanks

[Ttelmah]

Very annoying...
I only knew about this, from other chips where it applies, and had to check through the registers, and diagrams carefully, to be sure that this was the reason. Why Microchip, don't have a warning to this effect I don't know....

Best Wishes