For starter, Im using the C18 compiler for my PIC. When I create the function like high_ISR without any calls in it, my compiler adds code to it, code I can only see in a Disassembly listing view. This makeing my high_ISR function have a cycle time of say 160 cycles (but it appears to be empty looking at the C code).
Instead if I define it as a macro, I will have it empty of “secret” code. Will I somehow have a problem with other functions cause removing code that my compiler secretly puts there, will it cope with that in other ways?
I mean, I want the ISRs to be fast.
Is there a way to make the ISR function fast when writing the function in a c file, could I somehow supress the “secret code”.
See code examples below:
Proper creation of my high_ISR function in a .c file but with a long cycle time
#pragma interrupt highISR
void highISR(void)
{
SomeFunction();
}
Macro created function for instance in my header file (say cycle time of 16 cycles)
#define FAST_INTERRUPT \
void highISR(void) \
{ \
SomeFunction(); \
}
Just for clarification, If I use the macro, I implement it as:
#pragma interrupt higISR
FAST_INTERRUPT
The First highISR declaration produces this:
#pragma interrupt highISR
323: void highISR(void)
12B12 CFDA MOVFF 0xfda, 0xfe4
12B14 FFE4 NOP
12B16 CFE2 MOVFF 0xfe2, 0xfda
12B18 FFDA NOP
12B1A CFE9 MOVFF 0xfe9, 0xfe4
12B1C FFE4 NOP
12B1E CFEA MOVFF 0xfea, 0xfe4
12B20 FFE4 NOP
12B22 CFD9 MOVFF 0xfd9, 0xfe4
12B24 FFE4 NOP
12B26 CFDA MOVFF 0xfda, 0xfe4
12B28 FFE4 NOP
12B2A C1FB MOVFF 0x1fb, 0xfe4
12B2C FFE4 NOP
12B2E C1FC MOVFF 0x1fc, 0xfe4
12B30 FFE4 NOP
12B32 C1FD MOVFF 0x1fd, 0xfe4
12B34 FFE4 NOP
12B36 C1FE MOVFF 0x1fe, 0xfe4
12B38 FFE4 NOP
12B3A CFF6 MOVFF 0xff6, 0xfe4
12B3C FFE4 NOP
12B3E CFF7 MOVFF 0xff7, 0xfe4
12B40 FFE4 NOP
12B42 CFF8 MOVFF 0xff8, 0xfe4
12B44 FFE4 NOP
12B46 CFF5 MOVFF 0xff5, 0xfe4
12B48 FFE4 NOP
12B4A CFF3 MOVFF 0xff3, 0xfe4
12B4C FFE4 NOP
12B4E CFF4 MOVFF 0xff4, 0xfe4
12B50 FFE4 NOP
12B52 CFFA MOVFF 0xffa, 0xfe4
12B54 FFE4 NOP
12B56 CFFB MOVFF 0xffb, 0xfe4
12B58 FFE4 NOP
12B5A EE05 LFSR 0, 0x500
12B5C F000 NOP
12B5E 0E12 MOVLW 0x12
12B60 04E8 DECF 0xfe8, W, ACCESS
12B62 E303 BNC 0x12b6a
12B64 CFEE MOVFF 0xfee, 0xfe4
12B66 FFE4 NOP
12B68 D7FB BRA 0x12b60
12B6A 52E6 MOVF 0xfe6, F, ACCESS
324: {
325: SomeFunction();
12B6C EC48 CALL 0x14090, 0
12B6E F0A0 NOP
327: }
12B70 52E5 MOVF 0xfe5, F, ACCESS
12B72 EE05 LFSR 0, 0x511
12B74 F011 NOP
12B76 0E12 MOVLW 0x12
12B78 04E8 DECF 0xfe8, W, ACCESS
12B7A E303 BNC 0x12b82
12B7C CFE5 MOVFF 0xfe5, 0xfed
12B7E FFED NOP
12B80 D7FB BRA 0x12b78
12B82 CFE5 MOVFF 0xfe5, 0xffb
12B84 FFFB NOP
12B86 CFE5 MOVFF 0xfe5, 0xffa
12B88 FFFA NOP
12B8A CFE5 MOVFF 0xfe5, 0xff4
12B8C FFF4 NOP
12B8E CFE5 MOVFF 0xfe5, 0xff3
12B90 FFF3 NOP
12B92 CFE5 MOVFF 0xfe5, 0xff5
12B94 FFF5 NOP
12B96 CFE5 MOVFF 0xfe5, 0xff8
12B98 FFF8 NOP
12B9A CFE5 MOVFF 0xfe5, 0xff7
12B9C FFF7 NOP
12B9E CFE5 MOVFF 0xfe5, 0xff6
12BA0 FFF6 NOP
12BA2 CFE5 MOVFF 0xfe5, 0x1fe
12BA4 F1FE NOP
12BA6 CFE5 MOVFF 0xfe5, 0x1fd
12BA8 F1FD NOP
12BAA CFE5 MOVFF 0xfe5, 0x1fc
12BAC F1FC NOP
12BAE CFE5 MOVFF 0xfe5, 0x1fb
12BB0 F1FB NOP
12BB2 CFE5 MOVFF 0xfe5, 0xfda
12BB4 FFDA NOP
12BB6 CFE5 MOVFF 0xfe5, 0xfd9
12BB8 FFD9 NOP
12BBA CFE5 MOVFF 0xfe5, 0xfea
12BBC FFEA NOP
12BBE CFE5 MOVFF 0xfe5, 0xfe9
12BC0 FFE9 NOP
12BC2 CFE5 MOVFF 0xfe5, 0xfda
12BC4 FFDA NOP
12BC6 0011 RETFIE 0x1
The Second Function only produce this ->
322: #pragma interrupt highISR
323: FAST_INTERRUPT
13742 CFDA MOVFF 0xfda, 0xfe4
13744 FFE4 NOP
13746 CFE2 MOVFF 0xfe2, 0xfda
13748 FFDA NOP
1374A 52E6 MOVF 0xfe6, F, ACCESS
1374C 0105 MOVLB 0x5
1374E 5140 MOVF 0x40, W, BANKED
13750 1A77 XORWF 0xf77, F, ACCESS
13752 96A4 BCF 0xfa4, 0x3, ACCESS
13754 2877 INCF 0xf77, W, ACCESS
13756 6078 CPFSLT 0xf78, ACCESS
13758 86A4 BSF 0xfa4, 0x3, ACCESS
1375A 7E8B BTG 0xf8b, 0x7, ACCESS
1375C 0011 RETFIE 0x1
1375E 52E5 MOVF 0xfe5, F, ACCESS
13760 CFE5 MOVFF 0xfe5, 0xfda
13762 FFDA NOP
13764 0011 RETFIE 0x1
Further more clarification just to show that the functions them self is written the same:
For the first rutine ->
void SomeFunction(void)
{
if(PIR3bits.TMR4IF)
{
PIR3bits.TMR4IF = 0;
PR4 ^= _SoftPWM_Toggle;
_asm
INCF PR4,0,ACCESS
CPFSLT TMR4,ACCESS
_endasm
PIR3bits.TMR4IF = 1;
SOFT_PWM_PIN ^= 1;
}
}
The Second one in header as a macro ->
#define FAST_INTERRUPT \
void highISR(void) \
{ \
PR4 ^= _SoftPWM_Toggle; \
\
PIR3bits.TMR4IF = 0; \
\
_asm \
INCF PR4,0,ACCESS \
CPFSLT TMR4,ACCESS \
_endasm \
\
PIR3bits.TMR4IF = 1; \
\
SOFT_PWM_PIN ^= 1; \
\
_asm \
RETFIE 1 \
_endasm \
}
I don’t think its garbage in your runtime. Remember that an interrupt can occur anywhere in your main line code. When you return from the interrupt, you would expect your code to pick up in the same state where it left off. What the compiler is adding is code to save that state at the start of the ISR and then restore the state at the end of the interrupt. If it does not do that, and you modify a register or memory location in the ISR that the main line code was using, then odds are good that the code is not going to execute as exepected when the ISR returns. By elminating the compiler generated code, you have turned over the resposibility to your ISR to save, and then restore, the state of the mainline code. If you can gurantee that you will be ok (an empty ISR would be an example, it never changes the sate). If you can not, weird code execution is going to happen when you return to the main line code from the ISR. If you are using a high level compiled language, its hard to know what it is using under the covers, so having the compiler generate the state saving code for you ISR is safer than trying to do it on your own.
I suggest you take a look in the MPLAB® C18 C Compiler User’s Guide docs. There are aditional parameters to the #pragma interupt directive that allow you to somewhat customize what state information gets saved.