Embedded systems using AVR ATmega controllers are usually (best) implemented in pure C with a (WIN-avr) GCC toolchain. With AVRs RAM is often the tightest resource and sometimes developers fear the stack might collide with the variables.
Analysing tools calculating the minimal stackpointer on assumed call hierarchy and local variable definitions are a bit hard to find and to use in a non quite standard C-toolchain (using e.g. AVR-GCC inline ASM). And they tend to quite pessimistic outcomes.
Alternatively one might sample the stackpointer, i.e. its minimal value, in the life system — at least while in the lab — and display the result on command. Here’s a recipe:
The sampling “tool”
The sampling set-up
What remains is to scatter SAMPLE_MIN_SP(1) in the bodies of some few functions. Choose
- (a) those deepest in the call hierarchy and
- (b) those defining lots of local variable space (e.g. buffers) if not yet covered by one of the (a).
Display the results
To display the result do something like:
In this weAutSys excerpt the RAM address range available for stack and the sampled minimal stackpointer is displayed to a human operator, who gave the “runInfo” command on a serial terminal or a Telnet session.
If the minimal stackpointer fits in the range displayed one line above all is well — as, hopefully, no one uses heap (malloc) on an embedded system.
Comments
Want to leave a comment? Visit this post's issue page on GitHub.For commenting you will need a GitHub account.