CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com
No context-saving when using FAST for interrupt priority

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
schmobol
Guest
No context-saving when using FAST for interrupt priority
PostPosted: Thu Oct 30, 2003 4:19 am     Reply with quote
Hi everybody,

I need to decode a RF telegram coded in manchester using PIC18F458. I use INT_EXT for that purpose. To put it in the higher priority versus other interrupt, I use the FAST keyword.

Reading the .lst file, the interrupt vectors are correctly set but the problem is that the hgi priority interrupt, INT_EXT, doesn't have anymore context-saving.

#INT_EXT FAST
void external_interrupt_0_processing()
{
Blablabla...
}

Any idea to have a context-saving automatically done by the compiler with a high priority interrupt.

Thanks
Ttelmah
Guest
Re: No context-saving when using FAST for interrupt priority
PostPosted: Thu Oct 30, 2003 5:34 am     Reply with quote
schmobol wrote:
Hi everybody,

I need to decode a RF telegram coded in manchester using PIC18F458. I use INT_EXT for that purpose. To put it in the higher priority versus other interrupt, I use the FAST keyword.

Reading the .lst file, the interrupt vectors are correctly set but the problem is that the hgi priority interrupt, INT_EXT, doesn't have anymore context-saving.

#INT_EXT FAST
void external_interrupt_0_processing()
{
Blablabla...
}

Any idea to have a context-saving automatically done by the compiler with a high priority interrupt.

Thanks

At the end of the day, it depends what you are going to do in the interrupt routine.
You can use 'RETFIE 1', to restore the W reg, STATUS, and BSR registers in a single instruction. 'Simple' functions (like adding values to a simple - not array - variable), and basic logic tests, only affect these registers. If you avoid complex arithmetic (uses the scratch area), array accesses (use the table pointers) etc., you can use FAST with RETFIE 1, and things will be OK.
However there is a big 'coda' to what you are showing. Read the data sheet errata. The 18Fxx2, has a major problem with the fast interrupts, if they are coming from an asynchronous source (an external interrupt will be). Generally, it won't work, and will lead to program problems...
Because of this, I have used a 'psuedo fast' interrupt in one application, with the following code:

#int_global
void myint(void) {
static int INT_scratch[10];
#ASM
//Here for maximum speed, I test the RB interrupt - since it is allways
//enabled, I don't have to test the enable bit
BTFSS INTCON,RBIF
GOTO NXT
#endasm
change(); //change handler.
#asm
BCF INTCON,RBIF
GOTO FEXIT //Use the fast stack for exit
NXT:
//Now I save the registers for the other interrupt handlers
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 scratch,INT_scratch+6
MOVFF scratch1,INT_scratch+7
MOVFF scratch2,INT_scratch+8
MOVFF scratch3,INT_scratch+9
//Test for the external interrupt (power fail).
BTFSS INTCON,INT0E
GOTO NEXTA
BTFSC INTCON,INT0
#endasm
pfail(); //Power fail handler
#asm
NEXTA:
//Now for Timer 2
BTFSS PIE1,TMR2
GOTO NEXT1
BTFSC PIR1,TMR2
#endasm
TIMER2_isr();
#asm
NEXT1:
//Receive data available
BTFSS PIE1,RCIE
GOTO NEXT2
BTFSC PIR1,RCIE
#endasm
RDA_isr();
#asm
NEXT2:
//Transmit buffer empty
BTFSS PIE1,TXIE
GOTO EXIT
BTFSC PIR1,TXIE
#endasm
TBE_isr();
#asm
EXIT:
//Restore registers
MOVFF INT_scratch,FSR0L
MOVFF INT_scratch+1,FSR0H
MOVFF INT_scratch+2,FSR1L
MOVFF INT_scratch+3,FSR1H
MOVFF INT_scratch+4,FSR2L
MOVFF INT_scratch+5,FSR2H
MOVFF INT_scratch+6,scratch
MOVFF INT_scratch+7,scratch1
MOVFF INT_scratch+8,scratch2
MOVFF INT_scratch+9,scratch3
//Here the 'fast' exit.
FEXIT:
RETFIE 1
#ENDASM
}


This uses the normal interrupt (to avoid the problems with the chip), and simply tests the 'high priority' routine straight away. If the interrupt flag for this is set, it branches to the handler, which only uses functions that don't affect other registers. It returns from this, and immediately uses RETFIE 1 for a fast exit. The latency on this is about 30 instructions 'better' than the standard handler, even when this is set as the highest priority source.
I then save the resgisters needed, and test for three other interrupts (INT_EXT for power fail, Timer2, and INT_RDA), and branch to my own handlers for these. Each then restores the registers, and again uses INT_RDA (the total latency is about 3 instructions better on these, because of using RETFIE 1).

Best Wishes
schmobol
Guest
Re: No context-saving when using FAST for interrupt priority
PostPosted: Fri Oct 31, 2003 3:05 am     Reply with quote
Thank you very much for your help.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group