Go Down

Topic: Question about variable scope and processor load (Read 653 times) previous topic - next topic

ohnoezitasploded

Hi all,
     I have a question about how variable scope works.  As I understand it, if you define a variable in the setup() loop, it's only accessible within setup().  Ditto for the loop() functions, or interrupt routines.

Say that I put a variable declaration within loop(), like so:

Code: [Select]

void loop() {
int myvariable;

//some other code here...
.
.
.

} //end loop()


does that mean that the processor will spend time finding a spot in memory for that variable every time it rolls through loop(), or is it smart enough to skip that instruction after the first time?

What if I define and initialize the variable, e.g.


Code: [Select]

void loop() {
int myvariable = 24; //now I have set an initial value

//some other code here...
.
.
.

} //end loop()

RuggedCircuits

Interesting questions.

For your first case (uninitialized local variable), yes, the processor will "spend time" making room for your variable, but it's not very much time at all. It doesn't have to 'find' a spot...it knows exactly where to put it (on the stack, if that helps at all).

If you define and initialize the variable it does the same thing, but requires an extra step to set the variable to its initial value. A little extra time compared to the previous case, but still not very much time at all.

ohnoezitasploded

Thanks for the info.  Do you know a method or reference for evaluating processor load on the Arduino?  

I keep finding myself in situations (like receiving serial at 250Kbps, or real-time audio generation)  where I would like to squeeze just a little more performance out of the processor, and so it would be nice to know exactly how many clock cycles I'm saving by going to direct port manipulation vs. digitalWrite(), for example.

RuggedCircuits

The most instructive and accurate way to do it is to study the assembly-language output of your code, compute the number of clock cycles taken up by each approach, then compare.

That's a lot of work. An approach I often take is to set a digital I/O pin high when some piece of work starts, then set it low when it ends, and use a logic analyzer or oscilloscope to measure the width of this I/O pin pulse. This tells you how long your code takes to execute.

The coarsest but simplest way when you have a repetitive "long" task is to increment a counter when the processor is idle, in the main loop. Then, every second or so print out its value. Comparing how many "counts per second" you get with one approach vs. another gives you a relative measure of efficiency.

ohnoezitasploded

Uf.  I was afraid the answer had something to do with assembly code.  But banging a pin and looking at the pulse length on an o-scope is a great work-around, thanks for the tip.

Go Up