Example sketches always report the same values?

[locoduino]

Example sketches always report the same values?

[philj404]

FYI I tried using the previous release of MemoryUsage (v2.20.0).

• The examples were found under MemoryUsage as expected (not under INCOMPATIBLE/MemoryUsage/...)
• Otherwise Stack.ino and FreeRam.ino generated the same output was as for the examples in v2.21.0.

[Trusty77]

For the problem of architecture, its fixed with the new lib 2.21.1.
The INCOMPATIBLE folder has been probably caused by this problem ('AVR' instead of 'avr')...
For the incorrect values, the way heap and stack pointers and their exposure to code has probably changed since the development of this in 2015. This code needs probably a refresh....

[philj404]

(Argh... I just lost the longer comment I was typing up. I will break it up to smaller topics.)

Your v2.21.1 release now has its examples listed for Arduino Uno. Thanks.

I will do some more investigation into why the examples have results which do not seem to change.

[philj404]

I cloned the MemoryUsage repository and instrumented the code to learn more about what the examples are doing.

The FreeRam.ino example never calls STACK_COMPUTE. Does this make sense? I think the amount of unused RAM available should change depending on function calls and local variables going into and out of scope.

[philj404]

The Stack.ino example calls STACK_COMPUTE 5 times.

Unfortunately since STACK_COMPUTE only saves the largest value in mu_stack_size, it is hard to tell which calls (if any) change the value. This also can be a bit misleading as the reported "Stack size" is actually the MAXIMUM seen so far, not the current stack size.

I added an extra STACK_COMPUTE call at the beginning of setup(). This should help catch a change that increases stack size.

I think the SP macro might return a good value for the stack pointer, but I may not be interpreting the value correctly. I got type conversion warnings when doing the math between SP, RAMEND and mu_stack_size. It is hard to tell if ANY of them start with the same type! :-)

On my branch I am turning the STACK_COMPUTE macro into an inline function (at least temporarily). This lets me print intermediate values for each call.

[philj404]

I think the library and examples are technically behaving correctly (except for minor issues #6 and #5).

However the compiler optimizer passes make the examples much less interesting. After optimization many expected side effects disappear:

• aggressive inlining of functions means the stack pointer may never change. This can be useful if RAM space is small, and there is plenty of ROM for code -- like the AVR architecture.
• the compiler may keep variables in registers, so again the stack pointer may never need to change
• the compiler seems to detect "unused/unchanged" values and not bother generating code for them.

All good in principle. But the optimizations make it difficult to predict how much stack space is needed, just by inspection. Even for a simple example. Often nothing seems to change, especially for simple examples.

I was able to get more predictable results by:

• declaring functions noinline, for example void __attribute__ ((noinline)) STACK_COMPUTE_function(void) {...};. This ensures the function call will exercise the stack so this library can observe it.
• declaring variables volatile, which hints to the compiler it should manipulate the variable (and put it on the stack), even if it seems unnecessary.

I found it useful to modify the MemoryUsage library to support new (inline) functions to return numeric values for stack size, heap size etc.. This lets me numerically compare measured values against my expectations, measure deltas, print values in hex, etc.. I wrote a unit test to help me ensure my expectations matched what the compiler actually does.
(I will submit a pull request with these changes and my example sketch. It is a significant change, but it should be backwards-compatible. I hope it is useful for you!)

In all, I am VERY happy with how MemoryUsage is working for me. It is a good tool for understanding how much work the optimizers have done to improve performance on your code, and how much memory your code still needs. Thank you for providing these abstractions!

[philj404]

I am going to close this issue out, as I think it is now covered by other, simpler issues (#5, #6, #8, and #9).
The simpler issues should be easier to address one by one.