Go Down

Topic: Stack size and sub-methods (Read 3 times) previous topic - next topic

BKnight760

Hi Folks,
   I've been writing a fairly large sketch which has functions that call other functions several times deep.  They're not recursive, but say about 7-subroutines deep.  From what I understand about the stack, is that all the register values are pushed onto the stack each time a new method is called.  Are all the local variables from the calling method also pushed onto the stack as well?  They must-- I don't see how we'd keep track of local variables otherwise.

I understand that the stack starts at the highest SRAM address and grows downward, whereas the regular Data Memory starts just after all the External IO Registers and grows upward.  Eventually, as SRAM usage grows, the heap space and the stack space collide.

The reason I ask is because once I reached a certain method-depth, the program ceases to function correctly... if at all.  I assume that the heap data has over-written part of the stack, and thus a return value is no longer valid.  From my previous programming experience, it was good practice to use local variables wherever possible... but with such limited stack space, and no warning that stack corruption is taking place, I'm unsure if there's a better way to handle this.

Is there a way to set a maximum stack size?  Or to limit the area of SRAM which can be used for the heap?  How do the advanced users out there deal with these issues?






CrossRoads

What are you using for a uC now? Have you considered one with more memory? If Flash size is not a problem, what about just putting some of the functions in the code, vs using them as functions?
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Coding Badly

Hi Folks,


Quote
From what I understand about the stack, is that all the register values are pushed onto the stack each time a new method is called.


Nope.  It's a question of usage.  Calling l1 only uses 10 bytes of stack space (return addresses)...

void l5( void ) {}
void l4( void ) { l5(); }
void l3( void ) { l4(); }
void l2( void ) { l3(); }
void l1( void ) { l2(); }

Quote
Are all the local variables from the calling method also pushed onto the stack as well?


Still a question of usage.  The compiler first uses registers for local variables.  If a local register-based variable is not used after a call, the value is very likely discarded (meaning zero stack space used by it).

Quote
Is there a way to set a maximum stack size?


No.

Quote
Or to limit the area of SRAM which can be used for the heap?


Yes...
http://www.nongnu.org/avr-libc/user-manual/malloc.html

Quote
How do the advanced users out there deal with these issues?


Don't use the heap.

BKnight760

#3
Sep 10, 2011, 07:34 am Last Edit: Sep 10, 2011, 07:38 am by BKnight760 Reason: 1
Currently I have two Arduinos.  One is a Duemilenova DIP the other is an Uno SMD.  Both are using the ATMega328p.  2kB SRAM, 32kB Program Mem.  The Program Mem doesn't seem to be a problem, it's more the SRAM...  It looks like the stack is getting pretty large.


End of SRAM = 0x08FF
End of Regs = 0x00FF
SRAM Size = 0x08FF-0x00FF = 0x0800 = 2048 Bytes (2kB)

Stack Pointer = 0x0606
Stack Size = 0x08FF- 0x0606 = 0x0259 = 761 Bytes
Heap Space = 0x0800-0x0259 =  0x05A7 = 1447 Bytes

Why isn't there some sort of protection to prevent the heap and stack from overlapping?  Don't they protect against this on other processors?  You'd get some sort of error like a stack-overflow or something on a PC.  Is that too much work on a uC?

Coding Badly

Quote
Is there a way I can program this to avoid having such a large stack?


Let's see what the crystal ball has to say... Tomorrow's weather will be slightly warmer but still nice.  Huh.  Nothing about your sketch.  Maybe next time.

Or, as PaulS has been saying lately, move just a bit more to the right.  I can't quite see your code.

Go Up