So you're a Noob? Post your questions here until you graduate! Don't be shy.

User avatar
By McChubby007
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.
User avatar
By McChubby007
#80023 Also : This is a bit more complicated, potentially : You should also locate all functions that are called by the system sdk functions as a result of an interrupt (even if you don't know that they are called that way) !! Anything that is a 'callback' function which you provide to an API/SDK call might get called during an interrupt and the API/SDK documentation should tell you. An example is the ostimer (periodic timer) API : Your function which gets called should be locked into RAM.
User avatar
By McChubby007
#80025 Why do isr functions need to be in RAM? See here for some info :

I don't think I ever read a definitive explanation, but my gut feeling tells me that if the isr is in flash then flash has to be read which itself causes interrupts (or needs interrupt servicing), but at that point NMI has disabled interrupt servicing so the esp8266 just hangs and wdt ensues.

I bet rudy knows the answer?!

As to the definitive answer for when do RTOS/SDK callbacks need to be in RAM? Well the link above seems to indicate some cases do and some do not need it. So treat with caution.