How I can calculate the maximal Stack-Size of my program. => Based on the Source-Code ( + RTX-Tiny ), ( For User- and System-Stack ) : -> Is there a Software-Tool ?
Hi Steffen. If you are intrested in your program's stack utilization, the direct approach is to fill the stack area with a known byte pattern (for example, all zeros), then run your program with debugger and stress it to make it use as much stack as possible, then stop the program and inspect stack area to see where the CPU has touched it. This way you will get the idea of how much stack your program uses. It is hardly possible to predict a program's stack utilization based solely on the source code, unless it's a very simple program. The stack sizes are set in Startup.a66, of course. Regards, - mike
It is hardly possible to predict a program's stack utilization based solely on the source code The Keil compiler has to do this very job in order to perform its overlay analysis and assign overflow parameters and locals to memory addresses. Even in the cases where pure automation will fail (such as recursion), a tool could still output useful information that would save the programmer a lot of time. (Say, "763 bytes + (122 * depth(MyRecursiveFunc)") Breakdowns by function, as in the Keil map file for the data segments, would help the programmer find the worst offenders and identify paths in the call tree that have high stack usage. You don't have to solve the entire problem perfectly to still get value. It does seem to me that such a tool would be closely tied to a particular compiler. You would have a harder time writing a general purpose tool that just uses knowlege of C source. I suspect that the reason we don't see such tools is simply lack of demand by users, which would translate into effort by the compiler writers, to develop and maintain such a tool. It's not so much that it's too hard to do, but that the compiler vendors don't perceive a good return on their investment for doing so. The drawback to the usual "fill and test" method is knowing whether or not you actually exercised the code path that uses a lot of stack. And knowing which path of the call tree generates the most stack usage, so that you know what input is needed to exercise that path in a test case, is the original question. You're left hoping your test was thorough enough to have gotten the worst-case path.