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.
Perhaps someone can tell me why the line "while(EE_busy & 0x01);" is not compiled? volatile UINT8 EE_busy; EE_busy = 0x01; do EE_busy = hs_NvmRDSR(); while(EE_busy & 0x01); Thanks Rich
What makes you say that it "is not compiled"? How did you reach that conclusion? Remember that the 'C' compiler looks at statements - not lines. You could equally have written:
do EE_busy = hs_NvmRDSR(); while(EE_busy & 0x01);
When debugging (Ulink) the debugger indicates which lines of code were compiled and which were optimized out. Rich
It is notoriously difficult for a source-level debugger to be 100% correct in identifying the C source line for a given instruction after the optimizer is done rearranging code, as well as eliminating it. Optimization is not quite as simple as completely eliminating individual lines in the C source. After optimization, a particular single instruction might "belong" to many lines of source, or even directly to none. The usual two options for dealing with this problem are to build the code without optimization, or to switch to assembly-level debugging in the problem spots. Does the code work correctly? Can you post the generated assembly code for this snippet?
"the debugger indicates which lines of code were compiled and which were optimized out" Not exactly. The debugger doesn't know aything about optimisation. In 'C' source, 'do...while' is a single construct In this particular case, you will almost certainly find that all the code associated with the do...while control construct has been associated with the 'do' source line. It's not that the 'while' has been optimised out or not compiled; it's just that all the functionality of the 'do...while' construct has been associated with the 'do' source line, rather than the 'while' source line. You will probably find similar effects with 'for' loops...