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.
Stack/Thread Profiling
Moderators: RoccoMarco, lbednarz, utzig, tfAteba, barthess
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Stack/Thread Profiling
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
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
Re: Stack/Thread Profiling
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.
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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Stack/Thread Profiling
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
Giovanni
Re: Stack/Thread Profiling
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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Stack/Thread Profiling
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
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
Re: Stack/Thread Profiling
barthess wrote: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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Stack/Thread Profiling
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
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
Who is online
Users browsing this forum: No registered users and 53 guests