ESP32 Forum

finally got the board run.
with the example running there is 78324 bytes ram left.

Fyi, do not take this as an indication on the amount of memory that will be available in the final SDK and on the final ESP32 chip. Because of the memory map of the ESP31, we only use a specific bit of memory (the shared RAM) as heap. Don't quote me on this, but I estimate the free heap in the ESP32 to be at least 3 times this amount, if not more. (For example, on the esp31, with the 2nd cpu unused, there's another 90K which would be usable with some work.)

Sprite_tm wrote:Fyi, do not take this as an indication on the amount of memory that will be available in the final SDK and on the final ESP32 chip. Because of the memory map of the ESP31, we only use a specific bit of memory (the shared RAM) as heap. Don't quote me on this, but I estimate the free heap in the ESP32 to be at least 3 times this amount, if not more. (For example, on the esp31, with the 2nd cpu unused, there's another 90K which would be usable with some work.)

Can you give us more details about the memory map?

Sure. I have no docs I can release of that, but very quickly: The ESP31 has three regions of RAM: an IRAM for the first cpu at 0x40040000 (which is 128K), an IRAM for the second CPU at 0x3ffa8000 (64K) and a shared RAM at 0x3FFD8000 (192K). The IRAMs actually are 32K bigger than that, but if SPI cache is enabled on the corresponding CPU, that region is not usable. (The addresses I mention are the addresses I know of by which the 1st CPU can addres the memory; they're slightly different for the 2nd CPU and they're also not the only address ranges the RAM is mapped to.)

The SDK puts most of the program code in the IRAM of the first CPU, and the heap+stack in the shared RAM. This means there is still some memory that isn't used by default on the end of the IRAM segment of the 1st CPU. Also, with the 2nd CPU not used as it is in the current SDK, there is 92K of RAM in its IRAM region that is usable but not used by default.

This is the status on the current SDK, by the way. We may change the use of RAM in future SDKs; either we may add it to the heap or use it for the 2nd CPU. In the final ESP32 everything will change a bit more; we're striving for more simplicity and flexibility which will mean some slight tweaks to the memory map. Can't give any details, but I'm pretty sure you will like the results.

Sprite_tm wrote: ...This is the status on the current SDK, by the way. We may change the use of RAM in future SDKs; either we may add it to the heap or use it for the 2nd CPU. In the final ESP32 everything will change a bit more; ...

this is the right sound for my ears. i hope we can work all together on this and mutually benefit from technology. thanks Jeroen.

Sprite_tm wrote:Sure. I have no docs I can release of that, but very quickly: The ESP31 has three regions of RAM: an IRAM for the first cpu at 0x40040000 (which is 128K), an IRAM for the second CPU at 0x3ffa8000 (64K) and a shared RAM at 0x3FFD8000 (192K). The IRAMs actually are 32K bigger than that, but if SPI cache is enabled on the corresponding CPU, that region is not usable. (The addresses I mention are the addresses I know of by which the 1st CPU can addres the memory; they're slightly different for the 2nd CPU and they're also not the only address ranges the RAM is mapped to.)

The SDK puts most of the program code in the IRAM of the first CPU, and the heap+stack in the shared RAM. This means there is still some memory that isn't used by default on the end of the IRAM segment of the 1st CPU. Also, with the 2nd CPU not used as it is in the current SDK, there is 92K of RAM in its IRAM region that is usable but not used by default.

This is the status on the current SDK, by the way. We may change the use of RAM in future SDKs; either we may add it to the heap or use it for the 2nd CPU. In the final ESP32 everything will change a bit more; we're striving for more simplicity and flexibility which will mean some slight tweaks to the memory map. Can't give any details, but I'm pretty sure you will like the results.

Great news, thanks.
is esp31 go production? or it's just a beta version before esp32.

zeroday wrote:is esp31 go production? or it's just a beta version before esp32.

The ESP31 is a sort of engineering sample; we use it to figure out bugs and test most of the hardware. 99% of the things inthere will also be the same in the ESP32; there will be some small tweaks like the aforementioned memory map where we think we can improve the design without taking too much risk. For what I know, the ESP31 as is will not go into mass production, but everything you can do with the ESP31 will be possible on the final ESP32 as well.

i am also very interested in dram vs iram configuration.

thanks for the explanation of the memory map Jeroen, it makes sense, except for this:
in your reply you mention that the region at 0x3FFD8000 is the shared 192K segment.
but there's only 144K between 0x3FFD8000 and 0x40000000 which is where ROM starts.
does it mean that there is 48K before that that can be used?

also,

iram1_0_seg : org = 0x40040000, len = 0x20000

that's 128K of IRAM goodness and i'd like to get my grubby fingers on that
for our app, i'd like to trade some of that IRAM for DRAM as we are heap-intensive but do not care about execution speed as much (cached flash execution is fine).
having a way to remap memory regions would be super useful for us.
even now, if you can point me at registers to do that i could get going.

rojer9 wrote: does it mean that there is 48K before that that can be used?

I am not entirely sure. Could be that the 48K is used by the ROM.

for our app, i'd like to trade some of that IRAM for DRAM as we are heap-intensive but do not care about execution speed as much (cached flash execution is fine).

There's no actual way to remapping this... you could possibly use this by just pointing a pointer to the end of the code in IRAM and using it as a big buffer that way, but using it as heap is pretty much not possible for now, sorry. I'll see if I can change this, but because we'll have to overhaul it slightly after the ESP32 release, I'm not sure if it's worth the bother.

Sprite_tm wrote: I am not entirely sure. Could be that the 48K is used by the ROM.

ok, i actually miscalculated and it's 32K. but still, it is a big chunk of heap unaccounted for, would be nice to have it back or at least know that it's intentional. can you clarify it?

you could possibly use this by just pointing a pointer to the end of the code in IRAM and using it as a big buffer that way, but using it as heap is pretty much not possible for now, sorry. I'll see if I can change this, but because we'll have to overhaul it slightly after the ESP32 release, I'm not sure if it's worth the bother.

the difficulty with IRAM/IROM, at least on the 8266, is that access must be 32-bit aligned. either app needs to be super-careful, or something like this needs to be done, which slows things down. being able to dynamically reconfigure memory segments would be a big plus, because not all apps are alike. in particular IRAM/ICACHE vs DRAM tradeoff would be different for different apps. we will definitely be looking at using that IRAM as heap one way or another.

also, can you clarify these entries from the spec please:

ICACHE - 0x40080000 - 3.5M
DCACHE - 0x3FE00000 - 512k

ICACHE - my understanding is that it's the memory-mapped region backed by SPI flash, accessed through a smaller RAM window. how big is the actual RAM window size? can't really be 3.5M, with 416K total SRAM on board.
DCACHE - this is interesting. where is that mapped to? is it SPI flash as well? what is the difference between ICACHE and DCACHE - access alignment requirements? write access?