Limit of size of array and functions of STM32 chip

[rwmao]

Posted on December 13, 2015 at 06:25

When we use STM32 chip, is there a limit for the size of array and subroutine?

For example, if the chip has 128k ram, can I allocat 100k to an array(or buffer) or define an array as char chs[100k]? 

Certainly we need to leave some space for the algorithm and other variables.

how about subroutine(function)?

May I define a very long subroutine? For example main(). 

sometime the main() function is really very long.

What is the limit?

I just need a basic guideline.

Thanks

[Tesla DeLorean]

Posted on December 13, 2015 at 15:23

The memory available is described to the linker in the target options or scatter file. The size of the heap is defined in the startup.s file, and is probably a better approach for large empty allocations. With tricks this memory can be pulled from multiple arena. The things that would break large dynamic allocations would be fragmentation. Do them early. Even in systems that generally eschew dynamic memory it can be effective for configuration defined resource allocations, and when done early/once during start up.

Eval version of Keil have a 32KB limit on static allocations and code, other versions I've seen people complain at 8MB. To be honest if you have static allocations of that size you might want to consider separating those resources from the compile/link stage and deliver them in a file system or binary blob. The compiler may have limits on brace depth and function size. These numbers are likely to be impractically large, and if you really hit them you should refactor your code, as there's almost certainly repetitive code that could be more efficiently parked in subroutines. Keil's support can no doubt provide you with specifications/limits. Microsoft's older compilers had command line options to expand resources the compiler defaulted too if you hit certain limits.

http://www.keil.com/support/man/docs/armcc/armcc_chr1359125037582.htm

[rwmao]

Posted on December 13, 2015 at 22:34

Thanks. the limit is really large enough nothing to be worried.