Hi
I have a few questions about the stack size (LPC2200 controller).
E.g. in my programm is a main function with an array
short example[16][500];
16 * 500 * 4 (short) = 3,9 kByte
In which value will I find this array in the calculation when I rebuild all files (code, RO-data, RW-data, Zi-data)?
Moreover is it true, that the stack size will be configurated in the startup file? And the default value is 0x400 for the user stack - so I would need a much bigger value for the user stack?
After a few minutes I saw the map file where I figured out that the stack is growing from a low base.
In my case at the beginning of the internal ram there's a libspace (atmel-lib and string.h) and after that there's the heap (size = 0) and the stack size...
Is it ok, to increase the stack size up to the highest addr from the internal RAM?
best regards Albert
Why do you assume that short is four bytes large? Have you verified or somehow a strong reason to believe that?
How do you declare a 16-bit variable?
Your global variables will either be initialized (if they assign an initial value) or zero-filled. If you want a variable to keep its contents after a reboot, you have to read up on the linker.
Doesn't the startup file tell you the size of the user stack?
Yes you're right. 4 Bytes is one integer and 2 Bytes is one short variable....
I fill the array with default values using an for-loop (during the main function).
Yes but it seems to me that it is only a default value. But is it ok to increase this value up to the internal RAM?
And the default value is 0x400 for the user stack - so I would need a much bigger value for the user stack?
If you have an array that large, and it's defined in your main function, then you may as well make it static since it will exist for the whole lifetime of your program anyway. That way, the stack stays available for holding things it's meant to hold (huge arrays aren't usually part of this).
If you have an array that large, and it's defined in your main function, then you may as well make it static since it will exist for the whole lifetime of your program anyway. That way, the stack stays available for holding things it's meant to hold
is this also true, if the values for the array will change during the program?
If the array contents does not change, then it contains constant data. Then you should make sure that the array is stored in the code memory instead of consuming your RAM.
the array will change his data during the programm.
static short array[16][500];
Yes. The static qualifier refers to the lifetime of the variable (i.e. it always exists while the program runs, and only ceases to exist when the program ends), not to its value(s).
This is different from the const qualifier, which means that the value(s) of a variable do not change, but says nothing about the lifetime of the variable.
This is very, very basic C stuff and has very little to do with anything that's Keil specific. Consult your copy of K&R for details.
And not creating huge arrays on the stack is a good guideline for any programming language that requires the programmer to think about and influence memory allocation. You will get absolutely no feedback if the allocation on the stack fails except for undefined behavior of the program (a.k.a. it crashes). Creating the array statically, or on the heap (via malloc/etc) at least give you some feedback on whether the allocation of memory was successful (in the former case, the linker will give you an error message, in the latter case, malloc will return a NULL pointer if it fails to allocate the memory).
you got some good advise here. also, be careful not to overflow your stack - you seem to need a lot of space. you can try to fill up an area of RAM just above the stack with a known pattern like "DEADBEEF" of something similar, so that you can detect overflows easier. I don't know your particular chip, but an ARM9 does not have a built in exception in case of stack violations (unless it is equipped with an MMU). generally, stack space is computationally expensive (pushing stuff into it is time consuming) and should be kept for small items only. use RAM for larger items - must you have so much data available to you at any given moment? can't you reuse the memory for different purposes...?