Guru meditation errors

[filipekerplunk]

I'm a beginner in the Arduino world and other microcontrollers, so excuse my ignorance, but what is this IRAM_ATTR?

[Idahowalker]

@filipekerplunk

IRAM_ATTR

A simple internet search on the words IRAM_ATTR would have answered this question already but...

When we compile a C source file we end up with an object file that is then linked to produce an executable. During compilation, the different "sections" of the compiled C are placed in different "sections" of the object file. For example, code goes into the ".text" section and initialized data goes into the ".data" section. By flagging a piece of code with the "IRAM_ATTR" we are declaring that the compiled code will be placed in a section called ".dram.text" (I'm making that up as I don't have a reference to hand). What this means is that instead of an executable having just ".text" and ".data" sections, there are additional sections. The ESP32 bootloader, upon startup, will copy those ".dram.text" sections into real RAM at startup before giving control to your application. The RAM is then mapped into the instruction area address space (> 0x4000 0000). This means that control can be passed to this code (as normal) from within your running app and it will "work" because the code lives in the instruction bus address space.

What now remains is "why" you would want to do this? The answer is to consider the alternative. If the code you want to run is NOT in RAM, then where else could it be? The answer is "flash" ... if it is in flash, then when a request to execute that code is received, the code has to be executed from there. Flash on the ESP32 is much slower than RAM access ... so there is a memory cache which can be used to resolve some of that ... however we can't be assured that when we branch to a piece of code that it will be present in cache and hence may need a slow load from flash.

And now we come to the kicker ... if the code we want to run is an interrupt service routine (ISR), we invariably want to get in and out of it as quickly as possible. If we had to "wait" within an ISR for a load from flash, things would go horribly wrong. By flagging a function as existing in RAM we are effectively sacrificing valuable RAM for the knowledge that its access will be optimal and of constant time.

From https://www.esp32.com/viewtopic.php?t=4978

[filipekerplunk]

Thanks for the answers!

I put the IRAM_ATTR in the callback function, but when compiling I get the error

"callback was not declared in this scope"

When I remove the IRAM_ATTR from the function, it is compiled.

Do you know what they could be?

Thanks!

[Idahowalker]

The code that makes the problem?