jdowns 
I've noticed that when I compile my code with GCC and view the memory usage report at the bottom, it only seems to reflect global variables. I can introduce a local variable: float temp[500]; and recompile and the memory usage doesn't change at all unless I decide to make that global. I've noticed this a long time ago, and actually got into the habit of making almost all my variables global just so I could know my memory usage. Is there any other way to go about this?
Thanks,
James
dkinzer I've noticed that when I compile my code with GCC and view the memory usage report at the bottom, it only seems to reflect global variables.
I can introduce a local variable: float temp[500]; and recompile and the memory usage doesn't change at all[...]
jdowns Okay, thanks... I didn't know that was how it worked.
Regards,
James
Is there any other way to go about this?
What is strange to me is that there does not seem to be much interest in a tool like that.
Eugene
EDIT: fixed the link.
jdowns Yes, it's strange to me too... I have resorted to making almost all of my variables global just to know what my memory usage is.
James
dkinzer I have resorted to making almost all of my variables global just to know what my memory usage is.
You can determine your stack use empirically at run-time by adding a small amount of diagnostic code to your application. Step 1 is to seed the stack area with a known value, e.g. 0x55. This has to be done early in the your initialization code. Step 2 is to exercise your application thoroughly, with an eye toward ensuring that all executions paths are followed. Step 3 is to examine the stack area to find the lowest addressed byte that is not the seed value. That address can then be compared to the highest statically allocated RAM address (from the .sym file), the difference is the amount of unused stack space.
This topic and this technique have been discussed here several times.
dkinzer So far the only solution I came up with is to write my own utility that does that.
There is some discussion of the static analysis tool for our ZBasic compiler (that uses avr-gcc as a back-end compiler) near the end of the thread at https://www.avrfreaks.net/index.p.... This is a more specific use case but some of the ideas could be employed for a general avr-gcc application.
JohanEkdahl 
Eugene!
The link you supplied to some other thread here is broken. Even if I fix ".ne" to ".net" it eads to a server error. What thread is it that you are talking about?
JohanEkdahl Tell me the consumption of RAM that will come from the factorial function in the sketchy code below..
#includeint factorial(int n) { int temp; if (n==0) { temp = 1; } else { temp = factorial( n - 1 ) * n; } return temp; } int main(void) { DDRD = 0xFF; PORTD = factorial(PINB); while (1); return 0; }
And for the sake of this demonstration, of the difficulties constructing a general tool for calculating at build time the memory consumption at run time, please assume that the compiler is run with no optimization.
There is some discussion of the static analysis tool for our ZBasic compiler (that uses avr-gcc as a back-end compiler) near the end of the thread at https://www.avrfreaks.net/index.p.... This is a more specific use case but some of the ideas could be employed for a general avr-gcc application.
Eugene
Eugene!The link you supplied to some other thread here is broken. Even if I fix ".ne" to ".net" it eads to a server error. What thread is it that you are talking about?
dkinzer Do you translate Basic into C, then use gcc to compile to binary AVR code, right?
Have you instead considered adding stack size options to the gcc itself? Is that really difficult?
I posted a link where some guys seem to suggest that it is doable.
As noted (and as should be obvious) recursion, whether direct or indirect is an intractable problem lacking user guidance. The indirect calls problem can be mitigated with user guidance as well.
Tell me the consumption of RAM that will come from the factorial function in the sketchy code below..
Eugene
clawson 
Surely anyone writing embedded software will be doing a "memory budget" to decide which device is most appropriate/cost effective for the required solution and you'll do a "back of the envelope" dynamic analysis (statically!) by hand anyway?
The real easy asnwer IS to make everything global or at least static in fact. But I guess the "purists" don't like this as it contradicts everything they were taught in "Computing 101"?
dkinzer The real easy asnwer IS to make everything global or at least static in fact.
On the other hand, you could choose not to use interrupts and to have your entire application in main() with no subroutine calls. In that case, making everything statically allocated does solve the problem.
clawson In addition to being wasteful of a relatively scarce resource, that strategy doesn't really solve the problem.
As for then worrying about dynamic usage. Surely you'll have an idea of your deepest stack nesting and the worst case for an ISR would be if it stacked 32 bytes for ALL the registers.
(or are people REALLY mad enough to use recursion in an embedded program or allow for interruptible ISRs?!?)
Cliff
JohanEkdahl
(or are people REALLY mad enough to use recursion in an embedded program?!?)
clawson Well, I hope you know that I was rethorical..
Cliff
Sorry but I don't agree. I mean how many of your automatics are really just a locally used i,j,k loop counter or a general purpose uint8_t buffer[20] or something? So keep one set of i/j/k and a general_purpose_reusable_buffer[40] or whatever and just use the hell out of them.
Eugene
JohanEkdahl
But I guessed that [..] you [...] knew the motive behind your post.
JohanEkdahl
But making i/j/k global? Don't you think this is a bit extreme?
[preparing for the recoil...]
jdowns Well... I'm just glad to know I'm not the only one who programs that way... i.e. globals everywhere including things like i,j,k and one re-usable char buffer array, etc... I do exactly that in my code...
James
EW 
What is strange to me is that there does not seem to be much interest in a tool like that.
There is actually a lot of interest. It just happens to be a very difficult problem.
Search the web for 'stacktool' by John Regehr. He is a Computer Science professor at the University of Utah, which I happened to be acquainted with for several years now.
A few years back he created such a tool for the AVR, for a research paper, which got publish in Embedded Systems Programming (now Embedded Systems Design) magazine. I'm sure you look it up at the magazine's website: www.embedded.com.
This is a very difficult problem to solve, and unfortunately, Dr. Regehr's 'stacktool' program did not work for me on some real-world, large AVR applications. But the code is open source, IIRC.
I have told him (several times) that I would love for the 'stacktool' program to fixed so I could include it in WinAVR.
Search the web for 'stacktool' by John Regehr
BTW, if anyone interested, here is my tool: http://home.comcast.net/~ezstack/ezstack.c
It is kind of messy at this point. It does not support recursions, indirect calls, alloca, long switches. It assumes that interrupts are not re-enabled in the middle of interrupt routines. Most likely it does not support many other things.
I compile it using windows's cl.exe. But I think it should work pretty much everywhere else (well, little endian only). There are no command line options at this point. Just "ezstack file.elf".
Eugene
dkinzer BTW, if anyone interested, here is my tool
I also needed mine to perform stack use analysis for one or more tasks so it is invoked with the address of the root of the call tree that is to be analyzed.
My implementation partially solves the jump table problem by allowing the user to enumerate the possible destinations (either explicitly or by naming a data structure containing the addresses). Moreover, it provides a way for users to specify the stack depth of routines whose stack use would otherwise be indeterminate (due to recursion, presence of ijmp/icall, etc.).
