Does a delay take into account an interrupt? If I had a simple loop flashing an LED using delays - for visual monitoring of a running program, and an interrupt starts, does the delay have an effect on the stack?
Also, if the reverse is true, and a delay is in the interrupt routine, will that mess up the stack? Even if I disable interrupts while performing the interrupt?
Delays and interrupts
-
alanwms
- Posts: 133
- http://meble-kuchenne.info.pl
- Joined: Fri Dec 04, 2020 2:29 pm
- Has thanked: 26 times
- Been thanked: 7 times
-
mnfisher
- Valued Contributor
- Posts: 1453
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 135 times
- Been thanked: 707 times
Re: Delays and interrupts
Interrupts can occur while a delay is 'running'
So
Delay 1s
- UART Rx interrupt(s) - add chars to circular buffer....
..
Delay finishes - process input..
The delay does (in effect)
while (ms < 1000) ms = Getms();
On an interrupt - the processor saves the current context - performs the interrupt code - then restores the current context and resumes where it left off. (Note that an interrupt can only occur after an instruction completes - and the 'context' (registers, program counter and flags) are usually stored on the stack..
The opposite is not true - and it is a mistake to have a delay in an interrupt handler. Interrupt handlers should always be as fast as possible - and using code that might rely on interrupts in them (timing or i.o. for example) will result in heartache...
Martin
So
Delay 1s
- UART Rx interrupt(s) - add chars to circular buffer....
..
Delay finishes - process input..
The delay does (in effect)
while (ms < 1000) ms = Getms();
On an interrupt - the processor saves the current context - performs the interrupt code - then restores the current context and resumes where it left off. (Note that an interrupt can only occur after an instruction completes - and the 'context' (registers, program counter and flags) are usually stored on the stack..
The opposite is not true - and it is a mistake to have a delay in an interrupt handler. Interrupt handlers should always be as fast as possible - and using code that might rely on interrupts in them (timing or i.o. for example) will result in heartache...
Martin
-
kersing
- Valued Contributor
- Posts: 192
- Joined: Wed Dec 02, 2020 7:28 pm
- Has thanked: 77 times
- Been thanked: 64 times
Re: Delays and interrupts
Delay executes a number of ‘no operation’ instructions, an instruction that tells the controller to just wait a for small amount of time. To get the delay correct flowcode calculates the number of these instructions to execute and constructs a loop to call the right number of them.
If an interrupt occurs during the delay the total delay will increase by the amount of time spend in the interrupt routine. If the interrupt takes 1 second (not a good idea, interrupt routines should finish fast) and the delay was 1 second the delay will finish after 2 seconds.
Delay can not correct for time spend in an interrupt routine because most of the controllers do not have a realtime clock providing timing information required for such timing corrections.
Calling any macro (including delay) from an interrupt routine might create issues because some macros are constructed in a way that does not allow it to be called twice in parallel. The PIC compilers will display a warning in cases where this might occur in the code. If such a warning is displayed the code requires restructuring to remove the potential parallel calls.
If an interrupt occurs during the delay the total delay will increase by the amount of time spend in the interrupt routine. If the interrupt takes 1 second (not a good idea, interrupt routines should finish fast) and the delay was 1 second the delay will finish after 2 seconds.
Delay can not correct for time spend in an interrupt routine because most of the controllers do not have a realtime clock providing timing information required for such timing corrections.
Calling any macro (including delay) from an interrupt routine might create issues because some macros are constructed in a way that does not allow it to be called twice in parallel. The PIC compilers will display a warning in cases where this might occur in the code. If such a warning is displayed the code requires restructuring to remove the potential parallel calls.