Volatile keyword

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.

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.

volatile is never needed for auto variables.

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.

No, I don't think there's any question about that.

Whether a variable is automatic or not doesn't depend on how you use - or abuse - it.

Note that the function that gets a pointer to a variable will not be able to generate any code based on any "auto" optimization rules. From a code perspective, it will just be a pointer to memory - and the majority of processors don't have any special, magic, memory reserved for "auto" variables.

But the compilers do have sets of optimization rules that looks different, depending on what is known about a variable at the point of access. So the optimizers have different rule sets if they see a variable as auto, or global or indirectly accessed.

Unless the function call is inlined, the variable will no longer be seen as an auto variable - but the pointer to it will be - when the execution enters the receiving function.

volatile can also be useful on auto variables in functions that call setjmp