- Fri Jan 11, 2019 12:27 pm
#80022
Obviously there is only a small amount of RAM (Less than 64k), and when you specify that the function be loaded into RAM then it will be locked there, thus consuming that RAM forever (it is done by the linker when constructing the executable). If you have too many functions in RAM then there will be no RAM for general storage, stack, heap etc. The linker/loader will produce an error if you have exhausted RAM, but in the event that you use a lot but not all of it, then you may get a stack overflow during execution. I think the linker/load map gives ram utilisation, but I have never needed to use it. The map only shows fixed ram utilisation, of course, and not any runtime dynamic allocations.
The rule of thumb is : All isr functions (and child functions) in RAM, and any other functions which need to execute fast (non-ram functions have to be read from flash into ram cache before executing and so this takes a lot more time as it has to access slow speed flash). You would have to decide and select those functions according to your requirements.
Generally speaking all other functions can be in flash (and are put there by default). You need to identify slowness issues and then put those functions into RAM (you need my profiling tool for that I'm afraid !!).
If you know ahead of time that you want to really speed some things up (like my performance profiler which needs to run fast) then put them into RAM, but try not to use up too much RAM in the process.
This, in essence, is why I call programming an 'art' as well as 'science' and 'engineering' : you sometimes need a gut feeling if you don't have the experience and have to be creative.
lucasromeiro wrote:McChubby007 wrote:
Yes! Yes! You MUST set the isr to be located in RAM. Otherwise it will go into flash and that's not good at all. I hadn't even thought to mention that, sorry.
In fact I tend to audit my code and set all critical functions to be RAM located. Be careful though as you'll run our of RAM with too many functions stored there.
That solved my problem!
Can using the function in RAM cause any problems?
Can you tell me when to use RAM?
I did not even know it existed.
I do not know when to use it.
Obviously there is only a small amount of RAM (Less than 64k), and when you specify that the function be loaded into RAM then it will be locked there, thus consuming that RAM forever (it is done by the linker when constructing the executable). If you have too many functions in RAM then there will be no RAM for general storage, stack, heap etc. The linker/loader will produce an error if you have exhausted RAM, but in the event that you use a lot but not all of it, then you may get a stack overflow during execution. I think the linker/load map gives ram utilisation, but I have never needed to use it. The map only shows fixed ram utilisation, of course, and not any runtime dynamic allocations.
The rule of thumb is : All isr functions (and child functions) in RAM, and any other functions which need to execute fast (non-ram functions have to be read from flash into ram cache before executing and so this takes a lot more time as it has to access slow speed flash). You would have to decide and select those functions according to your requirements.
Generally speaking all other functions can be in flash (and are put there by default). You need to identify slowness issues and then put those functions into RAM (you need my profiling tool for that I'm afraid !!).
If you know ahead of time that you want to really speed some things up (like my performance profiler which needs to run fast) then put them into RAM, but try not to use up too much RAM in the process.
This, in essence, is why I call programming an 'art' as well as 'science' and 'engineering' : you sometimes need a gut feeling if you don't have the experience and have to be creative.
