I have variables which are to be used in interrupt only should they be volatile also
but I have defined them above ISR routine as I want to retain their value.
Nested interrupt can come in my case, but I don't use these variables in nested interrupt.


uint8_t x;
volatile uint8_t y;

void isr(void)
{
y = x;
x++;
}

main()
{
x = 0;
configure_isr();

while( y < 300);

///statrements

}

 

I think you better to declare them both volatile, if not (and depending on the compiler setting), your while() statement may be always true or always false.

declaring volatile variable stop the compiler optimize away the variable y.

 

is it necessary to declare x also as volatile

 

is it necessary to declare x also as volatile

Yes, if x is read or modified outside the isr. If x is not then I would declarable it inside the isr as a static variable with initializer.

 

The compiler should automatically make the var volatile if it is used in an interrupt (or hardware module).

 

"volatile" is used to mark any variable that may change "unexpectedly," meaning outside of the normal code flow. Variables that change inside ISR, and many hardware registers typically need to be marked such.

Additionally, when using such a variable outside of the ISR you need be careful as the value can change (and corrupt) while you are attempting to use it. For example, anything larger then a byte in an 8 bit processor cannot be read in 1 machine instruction; a 2 byte integer cannot be read in one step so the bytes may not be from the same number. This will introduce the occasional hard to find error.

One way that works to safely use a ISR value is to turn off the ISR while you access it. Another is to loop, copy it to another variable, then insure equality. There have to be more methods as well.

There is no such thing as an automatic volatile, it is your job (not the compilers) to determine volatile variables.

 

Volatile information:
http://blog.regehr.org/archives/28

Nine ways to break your systems code using volatile
....

 

...
There is no such thing as an automatic volatile...

That might be true for pure ANSI C but a C compiler for a microcontroller will treat hardware registers as volatile automatically, and if the compiler is any good it will check any variables used in interrupts and make them volatile too.

We've had a similar argument before Ernie, you should know this stuff by now.

 

That might be true for pure ANSI C but a C compiler for a microcontroller will treat hardware registers as volatile automatically, and if the compiler is any good it will check any variables used in interrupts and make them volatile too.

We've had a similar argument before Ernie, you should know this stuff by now.

To the world: Any compiler needs to be told specifics about the environment where the code it produces will run. There are various ways to handle this. The Microchip compilers use a dot H file that is included in the source code to provide these critical definitions, as does the SourceBoost C compiler, while the Microelectronica compiler uses a dot C file which is silently linked into the build by the IDE environment; it is selected based on the device you choose.

So some C compilers will have a line of code to include the processor specifics, some do this "in the background." But they all do this without any exception I am aware of.

It would be absurd for the compiler itself to hold these definitions, as the compiler would need to be recompiled every time a new device is announced and we'd all be running version 5001. Instead just the include files get updated (with additions)

Here's how each of these compilers defines the INDF indirection register (it's the first one in memory):

// Register: INDF
extern volatile unsigned char INDF @ 0x000;

#define INDF 0x0000
...
volatile char indf @INDF;

sfr unsigned short volatile INDF absolute 0x0000;

You can easily see ALL are marked "volatile."

It's a good idea to get to know these files as they contain all the names of all the registers and such you will need.

To conclude, I am reminded of a quote I like:

You can always tell a Harvard man,
but you can't tell him much.