Interrupt routine with priority?

[hhoebel]

Hi there,

anyone out there who uses a custom interrupt-routine with the hardware-priority of the 18F?
Any example how to do this and what should be saved/restored inside the #int_global? I know the CCS-example, but it's a really short one. I'm using 3.167

regards,

Heiko
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515846

[R.J.Hamlett]

:=Hi there,
:=
:=anyone out there who uses a custom interrupt-routine with the hardware-priority of the 18F?
:=Any example how to do this and what should be saved/restored inside the #int_global? I know the CCS-example, but it's a really short one. I'm using 3.167
:=
:=regards,
:=
:=Heiko
Yes, I do this. I originally had to write my own int handler, back in the days when the CCS compiler was giving problems, and then tweaked it to do this, when I needed a fast interrupt.
I also 'moaned' to MicroChip, since for the fastest response, it would be nice to be able to specify which interrupt vectored to the 004 address, and which to 008 (the way the fast interrupt currently goes to 004, requires an extra jump instruction to it's handler, whereas the 'low priority' interrupt going to 008, can have it's handler directly starting at this address...).
The 'core' stuff, that I save, is:
W
Status
BSR
FSR0L/H
FSR1L/H
FSR2L/H
TBLPTRL/H/U
and the five 'scratch' memory locations (addresses 0..4 by default).
The 'fast' interrupt in my case, then saves nothing, using RETFIE 1. This is in assembler, and only uses a couple of storage locations, with no use of CCS code at all.
The 'MOVFF' instruction on the 18F family, make saving the registers a very different operation, from that used onthe older chips:

#ifndef INTSTD
#INT_GLOBAL
dum() {
//This is my interrupt handler
static int INT_scratch[18];
#ASM
MOVFF W,INT_scratch+15
MOVFF STATUS,INT_scratch+16
MOVFF BSR,INT_scratch+17
MOVFF FSR0L,INT_scratch
MOVFF FSR0H,INT_scratch+1
MOVFF FSR1L,INT_scratch+2
MOVFF FSR1H,INT_scratch+3
MOVFF FSR2L,INT_scratch+4
MOVFF FSR2H,INT_scratch+5
MOVFF scratch1,INT_scratch+7
MOVFF scratch2,INT_scratch+8
MOVFF scratch3,INT_scratch+9
MOVFF TBLPTRL,INT_scratch+10
MOVFF TBLPTRH,INT_scratch+11
MOVFF TBLPTRU,INT_scratch+12
MOVFF scratch,INT_scratch+13
MOVFF scratch0,INT_scratch+14

I have defines for all the registers (and the 'scratch' memory area).

The reverse is done at the other end. Since the fast interrupt can interrupt the slow handler, I also make my interrupt 'test' code, loop back and retest the interrupts before exiting, which reduces the latency if a second 'normal' interrupt has occured (since the registers don't all have to be saved/restored...).

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

[hhoebel]

Many thanks for your posting.
I've got a answer from CCS too.
They mentioned that i simply can change the #int_xxxx to #int_xxxx fast.
I've tested this and, yes, the compiler enables IPEN, sets the interrupt to high-priority, moves the interrupt-handler from 0x0008 to 0x0018, inserts a jump to the interrupt-routine to 0x0008 and places a retfie 1 at the end of the routine instead of the normal retfie 0.
The interrupt-handler saves all what you've mentioned and the high-priority interrupt uses the automatic context-saving to the fast stack. Due to that i'm only modifying some global variables and two port-pins inside of this interrupt, it seems to that i don't have to add any save/restore-lines in addition to that.

Very nice :-)

regards,

Heiko

B.T.W.: Do you know why microchip always mentions the bank switching when talking about ram-usage (in the 18F1320-datasheet)? IMHO this chip only has 256 Byte ram and therefore the whole ram would be one bank and IMHO i don't need any bank switching for accesing that 256 bytes. Am i wrong?
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515864

[R.J.Hamlett]

:=Many thanks for your posting.
:=I've got a answer from CCS too.
:=They mentioned that i simply can change the #int_xxxx to #int_xxxx fast.
:=I've tested this and, yes, the compiler enables IPEN, sets the interrupt to high-priority, moves the interrupt-handler from 0x0008 to 0x0018, inserts a jump to the interrupt-routine to 0x0008 and places a retfie 1 at the end of the routine instead of the normal retfie 0.
:=The interrupt-handler saves all what you've mentioned and the high-priority interrupt uses the automatic context-saving to the fast stack. Due to that i'm only modifying some global variables and two port-pins inside of this interrupt, it seems to that i don't have to add any save/restore-lines in addition to that.
:=
:=Very nice :-)
:=
:=regards,
:=
:=Heiko
Yes. As I said, I generated this code, when the CCS compiler was still having problems with the interrupt handler. In fact the full code has an 'if' test, which allowed me to switch straight back to using the standard handler once it worked.
:-)
I still use this on one piece of equipment, because of the other change made (retesting the interrupt status bits before exiting), which massively reduces the latency with multiple low-priority interrupts.

:=B.T.W.: Do you know why microchip always mentions the bank switching when talking about ram-usage (in the 18F1320-datasheet)? IMHO this chip only has 256 Byte ram and therefore the whole ram would be one bank and IMHO i don't need any bank switching for accesing that 256 bytes. Am i wrong?

Remember the 'special function registers' are mapped into the RAM address space, up at the top of the memory area. Hence you could need to bank switch to access these. However (furtunately), the 18F family, support the long 'direct access' instructions (like the MOVFF one I used), which largely obviate the need to bank switch.

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

[Gerrit]

I like to get the folowing working:

1. I want to have controle over the low interupts (make my own global interupt)

2. I want to use a fast interupt for one timer.


when I start with:

#int_ad fast
void int_ad_isr(void)
{
char c;

c = 0x55;

}

the next list is availible

0008 EF5F F000 00002 GOTO 00BE
000C 0000 00003 NOP
000E 0000 00004 NOP
0010 0000 00005 NOP
0012 0000 00006 NOP
0014 0000 00007 NOP
0016 0000 00008 NOP
0018 6E05 00009 MOVWF 05
001A CFD8 F006 00010 MOVFF FD8,06
001E 50E9 00011 MOVF FE9,W
0020 6E07 00012 MOVWF 07
0022 50EA 00013 MOVF FEA,W
......

0092 5005 00069 MOVF 05,W
0094 C006 FFD8 00070 MOVFF 06,FD8
0098 0010 00071 RETFIE 0

0000 00418 .................... #int_ad fast
0000 00419 .................... void int_ad_isr(void)
0000 00420 .................... {
0000 00421 .................... char c;
0000 00422 ....................
0000 00423 .................... c = 0x55;
00BE 0E55 00424 MOVLW 55
00C0 0101 00425 MOVLB 1
00C2 6F82 00426 MOVWF x82
0000 00427 ....................
0000 00428 .................... }
0000 00429 ....................
0000 00430 ....................
0000 00431 ....................
0000 00432 ....................
00C4 9C9E 00433 BCF F9E.6
00C6 0011 00434 RETFIE 1





Why is the low priority interupt handler used ?





If is use :

#INT_GLOBAL
void isr() {
#asm
//store current state of processor
MOVWF save_w
SWAPF status,W
BCF status,5
BCF status,6
MOVWF save_status
// Save anything else your code may change
// You need to do something with PCLATH if you have GOTOs
// remember to check to see what interrupt fired if using more than one!!

// code for isr
BCF t0if
INCF counter,F
BTFSC zero_flag
INCF (&counter+1),F

// restore processor and return from interrupt
SWAPF save_status,W
MOVWF status
SWAPF save_w,F
SWAPF save_w,W
#endasm
}

#int_ad fast
void int_ad_isr(void)
{
char c;
c = 0x55;
}

I get an error

Error 92 "C:\Data\Project\LLD-098\Pic\LLD-098.c" Line 115(0,1): Duplicate Interrupt function




How do I setup this interupt interupr handling.



Gerrit

[Gerrit]

Hello,

Can some one point me out how to setup the software
so that I can use a self controled lowlevel interrupt and
use a high priority level interupt via CCS software.

I'm using verion 3.180 of ccs PCHW


Kind regards,

Gerrit