IU have a variable which can be chyanged outside the interrupt but inside the ISR it is only read. Its value don't change in it. Should it be volatile.
The ISR always needs to read the variable - there are no cache somewhere for the processor to keep the value since previous interrupt.
So you don't need "volatile" to make sure the ISR will pick up the current value. Unless you have nested interrupts that both uses the variable and the higher-prio interrupt may change the value.
You do need "volatile" if the ISR changes a variable, to make sure the main loop will pick up the changes.
Thanks for answer.
One more similar question:
Suppose i have a variable which is only accessed inside ISR. So I think there no need to declare it volatile. Right???
Also suppose if the code of ISR, I write it in function & declare the function with following statement: Now is there need of declaring a as volatile.
void __isr(void) { code_of_isr(); } __attribute__( ( always_inline ) ) __STATIC_INLINE code_of_isr(void) { int a; /* a is only used here. Not outside in main or anywhere */ a= 10; //////////////////next code parts }
volatile is never needed for auto variables.
They have a lifetime corresponding to the lifetime of the stack frame for that function call.
Errrm. never is a little too strong. It is possible for the address of that variable to be passed to something that is processed by an ISR.
Well, volatile isn't needed for auto variables. But a developer can manage to create aliasing to that variable by taking the address of it. But the question is if it should be seen as an "auto" variable when people accesses it using pointers. Aliasing, by the way, is one of the better known methods to create truly broken code.
But the question is if it should be seen as an "auto" variable when people accesses it using pointers
Yes.
You disappoint me. I have nothing further to say on the matter. Goodbye.
View all questions in Keil forum