Stack/Thread Profiling

[Tabulous]

what are peoples thoughts on this

dont ant to wast memory, but i also dont want to leave threads short ?

is the some way like a water line to know the absolute high point of a thread stack ?

at the moment ive got around 6 threads varing stack sizes, but all have around 30-40 bytes free when i look at the thread viewer in chibios studio.

[Giovanni]

Hi,

The only way to be sure is to have some kind of coverage test for your code in order to make sure that all code paths have been executed, then inspect the threads and get the real maximum usage.

Giovanni

[Tabulous]

could we not have a CH_DBG_ define that adds and extra var to the thread and this would show the highest water line of the stack the thread reached ?

Thus if you then test all code paths, you can break the debug and inspect and this would give results

once you have done this you can then adjust the working areas accordingly.

[Giovanni]

I don't see how that could be implemented, it is not like the OS inspects stacks instruction by instruction. Examining fillers is the closest thing.

Giovanni

[barthess]

Setting stack size "just to the water line" is very bad idea. When you update compiler of just change its settings than all project may be broken.

[Giovanni]

In RT4 there is "hard" detection of overflows using MPU, it is about all that can be done on Cortex-M devices.

New ARMv8-M devices will have stack boundary registers, that will be a definite improvement but it is still a detection mechanism, not a measurement.

Giovanni

[Tabulous]

Setting stack size "just to the water line" is very bad idea. When you update compiler of just change its settings than all project may be broken.

Totally agree, but also im not into wasting hundreds of bytes on stacks for the fun of it. What would you recommend is safe ?

Ps things are very tight ram wise on my current project only have 16k and its nearly all gone hence why im trying to opimise the system. If i had more ram I would not be that bothered.

[Giovanni]

I recommend, at the END of the development cycle:

1) Freeze the compiler version.
2) Freeze the compiler options.
3) Compile the SW using the final code, compiler and options.
4) Stimulate the device making it cover as much code as possible, if using dynamic allocation (bad in itself), make it run for a long time.
5) Measure the stacks unused area, using the ChibiOS debug plugin or looking at the stack areas directly.
6) Trim down stacks to the minimum and align size to the next 8 bytes boundary.
7) Recompile and what you get should be final.
8) Stress test.

If you make changes then stack requirements may change and you are back to point 3.

Giovanni