About Stack Pointer

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

I would like to ask about stack pointer in avr devices with sram.Is there any limitation in the number of registers that pushed on the stack while new callings inside a routine are made to other routines and an interrupt may occur.If this all thing may lead the program to crash.

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

You set the stack pointer at startup (or the C compiler's standardized startup code does - per your IDE settings).

that done, the stack size is limited by the size of the RAM minus the amount of RAM used for variables by your code.

From an interrupt handler/service, it is best practice to run a very short set of code, call no functions, or only your own specially coded functions, then exit the interrupt. The AVR can but rarely needs to nest interrupts - and will not unless you code for such.

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

There is certainly a limit on the total SRAM used (set by your choice of processor). If your stack intrudes onto declared variables, then you have problems - BIG problems. There is no runtime check on stack size in gcc, AFIK, and probably not in other flavors of c.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Short of using recursive functions there's little chance of using too much stack on most AVRs. It's still possible though if you declare too many/too large arrays etc.

In a recent thread on the Arduino forum someone had this problem because of too many print("some string") calls because the strings are copied to RAM, so it can happen.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

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

Quote:
Is there any limitation in the number of registers

You can use push pop as many times as you wish, till the moment you overwrite some important SRAM data or reach IO space with SP.

Quote:
There is no runtime check on stack size in gcc,

What a pitty.. Instead one can use hardware data breakpoints to make a runtime check when in debug mode.
This is an AVR forum and we are talking about push/pops so I guess I can recommend testing stack depth runtime before the reti of the ISR, as it is an ISR which typically damages data through the stack.

Upon ISR entry/exit check the value of a high water mark or SP. Report error if incorrect.

No RSTDISBL, no fun!

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

Hi,

I agree with the other posters. I can't remember seeing a C compiler check for stack overflow or underflow. As you can imagine, there would be a lot of overhead.

Two things might be worth noting.

High end CPU's, say those with a protected mode have hardware support which detects stack overflow and generates a trap (sort of like an interrupt). The advantage is there is no runtime penalty.

Second, old Pascal compilers used to support all kinds of bounds checking, including recursion depth. These days, especially in the embedded world we're expected to not need that kind of protection.

Michael Jamet

Michael Jamet