| View previous topic :: View next topic |
| Author |
Message |
subkron
Joined: 05 Mar 2013
Posts: 3
|
| #priority on 16F does not work |
 Posted: Tue Mar 05, 2013 10:02 am |
 |
|
Pretty straightforward, I have a design using a 16F1829 and I want to set the CCP2 interrupt as the first to be checked in the handler. No matter what I do (changing the order of the int_xx functions or assigning the order using #priority) the hander always goes in the order of T0, T1, CCP2 and RA when I check the list file. Compiler version V4.135.
Does this directive (#priority) actually work?
| Code: | #priority int_CCP2, int_TIMER0, int_RA, int_TIMER1
#int_CCP2
void CCP2_isr(void)
{
process_c();
}
#int_TIMER0
void TIMER0_isr(void)
{
process_a();
}
#int_RA
void RA_ioc_A_B(void)
{
process_d()
}
#int_TIMER1
void TIMER1_isr(void)
{
process_b();
} |
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19253
|
|
| Posted: Tue Mar 05, 2013 10:51 am |
|
|
It does work.
You can easily tell by looking at the assembler listing, where you will see the order the flags are tested.
Unless the interrupts are triggering at almost exactly the same time, the first triggered _will_ be the first serviced. I'd suggest that T0 is triggering first.
Best Wishes |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Tue Mar 05, 2013 11:01 am |
|
|
| Quote: | | Pretty straightforward, I have a design using a 16F1829 and I want to set the CCP2 interrupt as the first to be checked in the handler. No matter what I do (changing the order of the int_xx functions or assigning the order using #priority) the hander always goes in the order of T0, T1, CCP2 and RA when I check the list file. Compiler version V4.135. |
How do you KNOW?
Mike |
|
|
subkron
Joined: 05 Mar 2013
Posts: 3
|
|
| Posted: Tue Mar 05, 2013 11:04 am |
|
|
| That's exactly what I did (looked at the assembler listing). If I re-arrange the interrupt routines the compiled address changes. However, the hander (starting at address 0x004) readjusts such that the order of the pollng for the 4 interrupts is always t0, t1, ccp2, ra. If I rearrange the order defined in #priority the handler does not change. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Tue Mar 05, 2013 3:15 pm |
|
|
Perhaps you were looking at the wrong part of the assembly listing?
I don't have v4.135 installed but tried v4.137 and there it works, when I change the priority order the interrupt flags are tested in the sequence as mentioned in the #priority statement.
| Code: | #priority int_CCP2, int_TIMER0, int_RA, int_TIMER1
000F: CLRF FSR0H
0010: MOVLW 92
0011: MOVWF FSR0L
0012: BTFSS INDF0.BOR
0013: GOTO 016
0014: BTFSC PIR2.CCP2IF // CCP2
0015: GOTO 032
0016: BTFSS INTCON.T0IE
0017: GOTO 01A
0018: BTFSC INTCON.T0IF // Timer0
0019: GOTO 02E
001A: BTFSS INTCON.IOCIE
001B: GOTO 01E
001C: BTFSC INTCON.IOCIF // INT_RA
001D: GOTO 034
001E: CLRF FSR0H
001F: MOVLW 91
0020: MOVWF FSR0L
0021: BTFSS INDF0.BOR
0022: GOTO 025
0023: BTFSC PIR1.TMR1IF // Timer1
0024: GOTO 030
0025: MOVF 20,W
0026: MOVWF @77
0027: MOVF 21,W
0028: MOVWF @78
0029: MOVF 22,W
002A: MOVWF @79
002B: MOVF 23,W
002C: MOVWF @7A
002D: RETFIE
002E: MOVLP 00 <<-- Perhaps this is the part you were looking at?
002F: GOTO 03A // The sequence here stays the same
0030: MOVLP 00 // Don't understand why this in-between jump table is here.
0031: GOTO 042
0032: MOVLP 00
0033: GOTO 036
0034: MOVLP 00
0035: GOTO 03E |
Note the last part of this listing, there is an intermediate jump table of which the sequence does stay the same when the #priority line is changed.
I don't understand why this extra jump table is there. It doesn't seem to add extra functionality. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19253
|
|
| Posted: Tue Mar 05, 2013 3:43 pm |
|
|
That secondary table is a fix for one of the PIC erratas. Only exists on some chips.
Best Wishes |
|
|
subkron
Joined: 05 Mar 2013
Posts: 3
|
|
| Posted: Wed Mar 06, 2013 10:38 am |
|
|
From CCS support:
"The problem you reported has been fixed and will be in the next compiler release. "
Oh well... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
