When or why we must use the key word "volatile" in our embedded program?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Can give some small example?


Re: When or why we must use the key word "volatile" in our embedded program?
Quoted text here. Click to load it


This should explain all - http://www.embedded.com/story/OEG20010615S0107

cheers,

Al


Re: When or why we must use the key word "volatile"

Quoted text here. Click to load it

That's a very useful article.  Thanks! (and i'm not even the OP!)

--buddy


Re: When or why we must use the key word "volatile" in our embedded program?
Quoted text here. Click to load it

Do not rely on the subject to be part of your message.  In many
newsreaders it is not even visible.

Imagine a system where the hardware signals new data ready on the 1
bit of an address called DREADY.  This would be checked by
something like:

  int *dready = whatever;  
  ...
  while (!(*dready & 1)) continue;
  /* go get the data */

and any optimizer worth anything will change that to:

  if (*dready & 1) /* nothing */;
  /* go get the data */

The solution is to define dready as pointing to a volatile object

  volatile int *dready = whatever;

and the code will continue accessing *dready until the bit comes
true.  volatile means that something other than the actual code can
change this object.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: When or why we must use the key word "volatile" in our embedded program?
Copy of Subject:
When or why we must use the key word "volatile" in our embedded program?

In a nutshell: Whenever a data object does something that C doesn't
know about.

Like: change all by itself, or change by some other part of the C
program that doesn't conform to the standard flow of control in a C
program (multi-threading, interrupts, you name it).  

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: When or why we must use the key word "volatile" in our embedded program?
Quoted text here. Click to load it

OR, when you want to make sure the compiler generates a write
operation every time the variable is assigned a value.

OR, when you want to make sure the compiler generates a read
operation every time the variable is referenced.

You may wish to force a read operation because the value
changes "behind-the-scenes" as mentioned above.  Or there may
be desired side effects of the read operation regardless of
whether it's value is changing or not.

--
Grant Edwards                   grante             Yow!  Hey, I LIKE that
                                  at               POINT!!
We've slightly trimmed the long signature. Click to see the full one.
Re: When or why we must use the key word "volatile" in our embedded program?
Quoted text here. Click to load it

The "volatile" keyword means that the memory
location in question can be affected by something
outside the running program and/or that the act of
reading/writing that location has a side effect.

E.g. supposed padc is the pointer to an ADC control register: you write 0 to
it to start it, and wait for
it to become non-zero to indicate "conversion complete".

char * padc = (char*)<address>;
*padc = 0;
while ((*padc)==0)
{
  // wait
}
.. do something with the data

Any decent compiler will see that *padc gets set to 0
once, and never gets changed BY THE PROGRAM. Thus, it will
treat the while() as an infinite loop and optimise it away.

Change the declaration of padc to
volatile char *padc = .... whatever
and this will force the compiler to make an explicit read
of that location at each time (in this case, each iteration
of the while loop), knowing that it may change at any time.

Some compilers treat everything as volatile anyway. Depending on your
politics/religious convictions, this is
either good or bad.

Richard [in PE12]



Site Timeline