Any way to test stack size needed?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay... I know that this depends on a whole lot of variables... But do you know any way to determine an approximate stack size needed? Maybe use stimuli, and run the simulator through, and determine the maximum size of stack reached during running?

Or any other ideas? (Besides, do the math :) )

Thanks

axos88

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be nice to have a bit more information. Let's guess that you are programming in C. I think that you'll agree that this is a vital piece of info; the discussion for FORTH or LISP or JAVA or ASM may be quite different than a C discussion.

If it >>is<< C, then which flavour are you using? That might be somewhat vital, as most AVR C implementations have twin stacks, except for that C compiler TMNBN that uses 1.

Some compilers have provisions for, or you can roll-your-own, pre-loading the stack with a signal value, make a "normal" run, dump the SRAM, and see how deep it got.

My compiler makes an estimate of stack size for me, using a straight-forward analysis. If you nest your interrupts or have functions invoked by function pointers via function pointers, it won't catch it all.

Then there is the matter of coding style. I have few local variables in my apps, don't pass many function parameters, never next interrupts, and only call a couple levels deep. My stack needs are minimal. But I've seen posters here with big arrays as local variables, parameter lists up the ying-yang, virtually no global variables. Lots of stack usage.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Uh oh... sorry about that... I am programming in assembly... Totally forgot about the existance of C

axos88

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know from testing out free imagecraft a long time ago there is a stack check function you could use.

I took that idea to assembly and reserve a lower register for this. During init I load the upper boundary for ram that is used. Put this macro where it seems like the stack might be deep and overflow, like at the beginning of subroutines that are called by other subroutines, or on irqs that will be called from anywhere. Usually this will catch stack errors before they cause strange symptoms.

.macro check_stack
in r16, SP
cp r16, r13
brsh PC+2
rjmp stack_error
.endmacro
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you clear ALL you ram at start up and then set the stack pointer to ramend? If so you could get an idea of how far the stack has grown by looking at the 0 value bytes between your data ram (usually starting at low ram and you would know it's highest adress) and the stack, then run your program. I'm ASS U MEing that you have some ICE that allows you to stop execution and look at the ram or you could run in the simulator and it MAY give you and indication also. It depends if the worst case of stack usage is reached in the simulator...but that's an idea at least :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

for a complex program where stack size by analysis isn't practical, I've used this approach: Within an interrupt service routine for something like a timer that interrupts very frequently, put a little code in to store in RAM the deepest ever seen stack pointer at the time of interrupt - i.e., the low watermark.
Run the application for a long time, stress the I/O, and hope that the watermark is a good indicator of near worst case use of stack for interrupts + subroutine calls and local (stack resident) variables.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aham, thanks, I'll consider these ideas

axos88

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While I do this in C it works just as well in Asm. Just have the very start of your program flood SRAM with a recognisable value such as 0x5A. Then (in C at least) variables are positioned from the start of SRAM upwards while the stack grows down from RAMEND downwards. After running for a while the existence of some 0x5A's in the middle is a pretty fair indication that the two haven't bumped into one another yet.

Cliff