Some unnecessary codes are also available in it, written to test.
Anyway, I have just started a test by commenting the following lines, will see what will happen:
Usually interrupts are disabled automatically during an ISR.
So "disabling Interrrupts" is useless.
But "enabling interrupts" causes other pending interrups to be processed... immediately...before the actual ISR is finished. This may create problems with variables, stack, ...
Hello,
After the last changes (disabling the enable_interrupts(GLOBAL) and #device HIGH_INTS = TRUE), the tests are running without problem. The issue seems to be solved, thank you very much. I want to ask one more question. Should I disable_interrupts(GLOBAL) while sending data by rs485? The library disables only int_rda, but I am also using the timer interrupt.
Thanks again.
I see no need for disabling the interrupts during UART operations.
Generally ... why one disables interrupts:
* either, if you expect an ISR to change data you are just processing.and you don't want this
* or you have a timing critical process, where you don't want to be interrupted.
Else don't disable the interrupts.
You should always be aware of
* what variables are use in an ISR
* how often an ISR is executed
* and how much time an ISR needs ( here i often use one port pin switched HIGH at the beginning of an ISR, and switched LOW at the end of an ISR. Measure time with a scope and add some overhead for saving data)
Hello again,
My problem doesn't happen any more, so the problem cause was the enable_interrupt(GLOBAL) just before exiting the interrupt.
I have another small problem:
I was previously using 2ms delay instead of while(!PIR1TXIF), after I started waiting TXIF, it seems to stuck sometimes. If I use 2ms delay between every character sending, the problems doesnt seem to happen.