source: click here & here
The 'warning', about 'condition always true', is just that, a 'warning', to make sure you realise the test will never be false.
A search here, would have found a huge number of threads explaining the 'reentrancy' error. This is because you are using delays in both your main code, and in the interrupt. A function _cannot call itself_. This is a hardware limitation of the PIC, since it does not have a 'stack' for variables. If an interrupt occured _inside_ one of the external delays, you would get a delay, called inside a delay. hence the compiler disables interrupts in the external delays.
Seriously, the use of delays in the interrupt should be avoided anyway. If you want a delay, and then re-test of the pin, setup a hartdware timer, in the interrupt, and check the pin when _this_ expires, and interrupts. Follow the 'mantra' (not always right, but close enough for most things), _keep interrupt handlers as fast as possible_. Do _not_ sit in a delay inside the interrupt.
above solution solves the warning.
-----------------------------------------------------------------------------------------------------------------------------------------
delay_us() and delay_ms() probably share a common delay function in the library, or at least a common variable, so you cannot get around it that way. It you really need to get around the problem, then write your own delay function for the interrupt code that does not use any library functions at all. However, let me add my voice to the chorus of others who have said that it is bad, bad practice to use delays inside of interrupt code!
---------------------------------------------------------------------------------------------------------------------------------------
I assume you want to know why you get the warnings? It is because those functions can be called both from the RDA interrupt, indirectly through stop(), and the main code. This could cause re-entrancy which messes up the compilers call tree.
The best way to fix this is to absolutely minimize the code in your interrupt routines. Have the interrupt quickly set a status word and exit. Let the main code check the status word on its own schedule, and if the status has changed, then the main code does the work needed for the new status. It looks like your Rx_data could be that status word.
========================================================================================
If you feel that you must put a delay inside an isr, and you don't
want to see that warning message, then tell the compiler to create
a 2nd instance of the delay library by adding a 2nd #use delay()
statement as shown in bold below. That way, the isr and the
code in main() (and beyond) will each have their own separate
delay routines.
Quote: |
#include <16F877.H> #fuses XT, NOWDT, NOPROTECT, NOBROWNOUT, PUT, NOLVP #use delay(clock = 4000000) #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS) #int_ext void int_ext_isr(void) { delay_ms(1); } #use delay(clock = 4000000) //====================== void main() { enable_interrupts(INT_EXT); enable_interrupts(GLOBAL); while(1) { printf("Hello World\n\r"); delay_ms(100); } } |