We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
There is a string buffer referenced by both an ISR and the main(). The ISR collects a sentence from UART and put it into the buffer. Once the received sentence is completed a flag is raised. The main() checks the flag and copies the sentence to another buffer. The code is like
unsigned char xdata RxBuffer[]; unsigned char xdata buffer[]; bit RxFlag = 0; void uart( void ) { //receive data from sbuf RxBuffer[] = sbuf; //if done RxFlag = 1; } void main( void ) { while( 1 ) { if( RxFlag ) strcpy( buffer, RxBuffer ); } }
"Not quite. volatile applies specifically to reloading a variable rather than using a possible cached copy in registers." That's pretty much exactly how I see volatile. I was trying to offer a simple explanation in the context of the OP's situation. Perhaps I should have said: "don't perform any optimisations that will screw up what I'm trying to do here" "It has no effect on other optimizations." Having re-read the section on volatile in H&S I'm not convinced about this, but I found the explanation a bit unclear. Maybe someone can quote the text from the standard if that makes it any clearer? Stefan
The standard's wording boils down to this: all operations on an object qualified as "volatile" must happen in exactly the same way and order as expressed by the standardized semantics of the source code. They define the effects of all C statements and operators in terms of some virtual machine executing the C program, and the effect of "volatile" as making the behaviour of the C program on the actual execution machine the same as that of the virtual machine, as far as "volatile" objects are concerned. In practice this forbids all register-caching and code reordering optimizations. It still allows optimizations like, e.g., common exit code unification to save space, or function inlining, and quite some others.