Stack&Heap vs IRAM&DRAM

[Gfast2]

Hi ESP-IDF,

I wanna know how to understand these two type of concepts like the title described.
I do know what is stack and heap, and other parts like the following images drawn.

383f472.png (45.73 KiB) Viewed 15620 times

But if I read the docu about Heap Memory Allocation, IRAM and DRAM jumped out.

In my understanderation, the difference between them is: Stack&Heap are on the Software Abstraction level and IRAM&DRAM(&RAM) are on the Hardware Abstraction level. That means, the concept in second group are hardware difference. And they are not changeable.

Am I right? If I'd wanna log out IRAM/DRAM usage, is there any API to call?

LG

Gfast2

[kolban]

I'm far from an expert in this field ... but I'll have a bash. The ESP32 uses what is known as a harvard architecture. This means that there are two buses over which data flows. One is called the instruction bus and one is called the address bus. What this loosely means is that data can flow from RAM/ROM to/from the CPU at the same time as the next instruction is being fetched from RAM/ROM for subsequent execution. This enables potential extra performance resulting from overlapping operations and actions. However, there must be some "mechanism" that allows the processor to know to fetch data using the instruction bus as compared to the data bus. My understanding (loosely) is that addresses in the address space of the ESP32 less than 0x4000 0000 are fetched through the data bus while addresses north of 0x4000 0000 are fetched through the data bus.

Now imagine a chunk of 64K of RAM. Real RAM. What is the address of this arbitrary chunk of RAM? The answer is that it is configurable through hardware using a component of the hardware of the ESP32 called the Memory Mapping Unit (MMU). Using the MMU we can define that the chunk of RAM can appear (be addressable) either below 0x4000 0000 (and hence be retrieved as data) or it can appear above 0x4000 0000 and hence appear as instructions.

With this notion, we can now associate an additional "attribute" with a piece of RAM ... it is either bellow 0x4000 0000 and hence is Data RAM (DRAM) or it is above 0x4000 0000 and is Instruction RAM (IRAM).

[Vader_Mester]

The main difference between IRAM and DRAM, is that the ESP can run programs from IRAM, and that IRAM is only 32bit accessible, whereas DRAM is byte-addressable.

Also, when you use the IRAM_ATTR attribute for functions (that are frequently used), the ESP will put these functions into the IRAM, and executes them from there, so they will be quickly done, without additional flash read and chache usage of the cores.
(also the interrupt functions you can only put into IRAM, as it can cause problems, if you don't do so).

Read this part from the Heap Memory allocation part from http://esp-idf.readthedocs.io/en/latest ... alloc.html

32-Bit Accessible Memory
If a certain memory structure is only addressed in 32-bit units, for example an array of ints or pointers, it can be useful to allocate it with the MALLOC_CAP_32BIT flag. This also allows the allocator to give out IRAM memory; something which it can’t do for a normal malloc() call. This can help to use all the available memory in the ESP32.

Memory allocated with MALLOC_CAP_32BIT can only be accessed via 32-bit reads and writes, any other type of access will generate a fatal LoadStoreError exception.

[Gfast2]

Hi Vader_Mester,

Thanks for your "IRAM_ATTR" and its declaration!
I've greped the eps source, ESP-IDF did have ten thausand function add this macro. Since the xtensa core is a 32bit core, ist that means all defined functions I used can add this macro (If there is always IRAM available) to accelerate the performance? How to track my usage of IRAM specifically on-the-fly? Or is that even possible? Or just a every expertised experience thing at all?

Cheers

Gfast

[Gfast2]

Hi kolban,

Thanks for your declarations! It helps me a lot. But I'm afraid I can't understand the data flow inbetween IRAM, DRAM and Control Unit 100% clearly. But I'll try to dig deeper by check out some posts & youtube vids. (Sorry, I'm still very dumb in this level )

Cheers

Gfast2

[Vader_Mester]

Hi Vader_Mester,

Thanks for your "IRAM_ATTR" and its declaration!
I've greped the eps source, ESP-IDF did have ten thausand function add this macro. Since the xtensa core is a 32bit core, ist that means all defined functions I used can add this macro (If there is always IRAM available) to accelerate the performance? How to track my usage of IRAM specifically on-the-fly? Or is that even possible? Or just a every expertised experience thing at all?

Cheers

Gfast

I suggest you use the IRAM_ATTR attribute for interrupt functions and very frequently used but simpler functions, so they run smooth.

The best is that you look at the examples, they are very nice source of info in this case.

I use IRAM stuff for I2C polling, bit banging, delays, GPIO input checks, simple Wifi stuff.
For example for init functions don't use it, because you only use it once in a while in an application. For functions that write data frequently to flash or SD card, definitelly use it!
If you need to send data frequently, then you can also use it.

Make sure you don't use it too much, as it can pretty much run out of IRAM, because it's also used for other things, like Core cache (32kB cache/core for storing instructions read from flash) and of course the stack.

I still did not get my head around it fully, and currently experimenting with it only, and reading a lot.... I mean a lot
(Like look at Kolban's book, it's over 1000pages loooots of reading and research ahead).

[Gfast2]

Hi Vader_Mester,

Thanks again for your more detailed answer. I'm big fan of Kolban's esp32 bible, too. My tiny esp32 told me really really much more then what my expensive Game PC did.

I hope I can keep on looking forward and learn more from you guys, and even do some contribution later some how.

Cheers

Gfast2