When safe to use enable_interrupts() ??

[Al Boulton]

I'm using a 16F877 with #INT_RDA & #INT_EXT and need to disable
& enable irqs within the service routines. Having read p157 of
CCS compiler Manual (July 2001) - "What are the restrictions on
function calls from an interrupt function" and get the impression that I can do this :

#INT_RDA
void ext_isr() {
enable_interrupts(#INT_EXT);
disable_interrupts(#INT_RDA);
}


but not this :

void disableEnable_irqs() {
enable_interrupts(#INT_EXT);
disable_interrupts(#INT_RDA);
}

#INT_RDA
void ext_isr() {
disableEnable_irqs();
}

***NOTE : I need to call disableEnable_irqs() from main() as well.


My confusion lies in the fact that the manual says the problem is in the context switching between functions so I assumed I could get around the problem by defining disableEnable_irqs()as #INLINE.
This would avoid a function call, but enable_interrupts()
is compiled as a called function, not inline so isn't there going to be a problem there as well?
Any guidance would be much appreciated.

Confused of England

Al
___________________________
This message was ported from CCS's old forum
Original Post ID: 13527

[Tomi]

You don't have to disable ITs from your ISR. The hardware does it for you.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13528

[R.J.Hamlett]

:=You don't have to disable ITs from your ISR. The hardware does it for you.

I don't think this is what he is doing.
The behaviour seems to be to 'toggle' interrupts, so that (for instance), an incoming signal on the RS232 interrupt line, enables the external interrupt.
What is described should work, and would probably work OK in either form, since the amount of code is so small, that the compiler would probably make it 'inline' by default. However there are quite a few other things that should be done to make the code reliable. For instance, if the receive data interrupt has been disabled, then it is necessary to ensure that the serial routine can also handle the situation that there has been an overrun error.
Given the small size of the code needed to set/reset the interrupt bits, you could handle the configuration manually, by defining the bits directly, and having one routine (called say 'DisableEnable_irqs', that is only called from the main code, and another called 'IDisableEnable_irqs', that does exactly the same, and is only used inside the interrupt code.
The version called from the main code, should also disable the global interrupt before changing the interrupt state, since otherwise there is the possibility of the 'enable interrupt' setting, immediately resulting in an INT_EXT, which if it then changes an interrupt setting inside the routine, could result in unexpected behaviour...

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

[Richard Tinley]

I have just written a program that does a very similar task using int_ext and int_tmr2 controlling each others enable/disable, (as well as int_rda running independentally). After about a week of not being able to make it work reliably I updated my compiler to 3.149 from 3.107 and found the bugs were in the compiler and not my code! My guess is that the compiled code was not looking after the stack correctly.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13534

[R.J.Hamlett]

:=I have just written a program that does a very similar task using int_ext and int_tmr2 controlling each others enable/disable, (as well as int_rda running independentally). After about a week of not being able to make it work reliably I updated my compiler to 3.149 from 3.107 and found the bugs were in the compiler and not my code! My guess is that the compiled code was not looking after the stack correctly.

Was this on a 18Fxxx?. If so, then it is the known problem with handling the enable/disable interrupt bit, which can result in this becoming incorrectly set/cleared. It was fixed in about version 3.130
The problem in this case, is with the chip, with an 'errata' having now been issued by MicroChip about it. The newer compilers include the 'bodge' to fix it...

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