• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 896 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Variables Defined in Functions Not Working

Jonthornham
Expert 1490 points


Hello,

I am kicking the dust off of a few old projects as I get back into MSP430 programming.  I noticed that the function below did not work when the variable "count" was defined in the function.  If I define the variable globally the program executes.  It seems that the latest build of CCS has made the change.  

I am not a master in C programming but this seems odd.  I can't see having to define all function variables globally in order for them to work.  Larger projects would become messy quickly.  Is there a setting I have turned off or am I messing something up?  The function is declared before main incase you are wondering.

void delay (void)

{

unsigned int count;

for (count = 0; count < DELAY; count++);

}

Take care,

Jon

  • 0
    Guru 16361 points

    Hi Jon,

    When you say "the function below did not work" do you mean that it caused no delay?

    If so then the compiler probably optimised the function out of existence. As far as it's concerned the function doesn't do anything - it just increments a local variable which gets discarded at the end of the function. Making the variable global tricked the compiler into thinking the loop was necessary, but that's not guaranteed to always work. A future compiler upgrade might cause the function to go wrong again.

    If you really want to make the CPU busy-wait it's safest to use the _delay_cycles() instrinsic:

    _delay_cycles(20000); // Make the CPU busy wait for 20000 instruction cycles

    That has the advantage of ensuring the compiler understands what's going on, so it won't be optimised out. Also the delay is a specified number of clock cycles so it's easier to know how long (in real time) the delay will be.

    Hope that helps, Rob

  • 0 in reply to Robert Cowsill
    Expert 1490 points

    Rob,

    Thanks for the info.  I find it funny how the compiler would choose to optimize something out and I don't think it's a great idea.  Regardless the delay function you've mentioned is the right way to go.  I appreciate the response.

    Take care,

    Jon 

  • 0 in reply to Jonthornham
    Guru 35595 points

    Jonthornham said:
     I find it funny how the compiler would choose to optimize something out and I don't think it's a great idea

    It is perfectly standard and normal behaviour for any high-level language (HLL) compiler:

    http://bit.ly/Vv8fFg

    http://bit.ly/YPhiRO

  • 0 in reply to Andy Neil
    Expert 1490 points

    Thank you for the links.  I am not saying it's not normal it just isn't something I would have predicted.  Guess that makes me the odd one =].

    Take care,

    Jon

  • 0 in reply to Jonthornham
    Guru 35595 points

    Jonthornham said:
    Guess that makes me the odd one

    Not really - as noted, it is a very common misconception.

    Must be a major omission in 'C' teaching materials...

  • 0 in reply to Jonthornham
    Guru 227245 points

    Jonthornham said:
    I find it funny how the compiler would choose to optimize something out and I don't think it's a great idea.

    Well, the compiler only cares for one thing: that after leaving the function the memory is in a defined state. How it goes there is unimportant. And the compiler is written to optimizes code size and speed without changing the outcome. An din this specific case, the outcome is that all system memory is unchanged., SO the whole function body can beoptimized away.

    Using a global variable only changes oen thing: that after leaving the funciton the content of this variable is the end value of th eloop. So the loop can be replaced by an assignment without any impact on the code.
    If you mark the global(!) variable as volatile, you tell the compiler that the access to the variable has side-effects not seeable by the source code alone. In this case the compiel rwill generate exact as many accesses to the variable as teh source code shows, even if this seems to be useless. However, it still doesn't tell you how the compiler will structure the code. it may be an endless row of increments (taking three clock cycles each), or a loop with one increment inside (taking 7 clock cycles per loop) or a mixture of both. Dependign on the compilers judgement of speed/size tradeoffs. And it may change with each compiler revision. So busy-waiting loops are really not suited for timing purposes.

    Note that the compiler doesn't care for intended side-effects like wasting time. After all, it isn't the purpose of a program to waste time and do nothing. if you need some sort of timing, use a timer. Or tell the compiler that you want to generate time-wasting code (which the delay intrinsic does).

  • 0 in reply to Jens-Michael Gross
    Expert 1490 points

    Thanks to everyone for the responses.  I appreciate the help.

    Take care,

    Jon

**Attention** This is a public forum