PSRAM support status

[loboris]

It is now almost 3 months since the the experimental feature/psram_malloc branch was released.
Can we get some information about the current status of psRAM support development, its future, will it be merged into esp-idf v3.0. ?
The psRAM functionality mostly works, but there are some problems, and the feature/psram_malloc branch is 655 commits behind the master...
As more ESP32 modules with psRAM integrated are available, I think it is important to get full, reliable support for it in the master esp-idf branch as soon as possible...

[ESP_Sprite]

The plan is to integrate it in the esp-idf-3.0 branch, and we're busy integrating it now. You should see the first additions to the master branch next week or so.

[rudi ;-)]

The plan is to integrate it in the esp-idf-3.0 branch, and we're busy integrating it now. You should see the first additions to the master branch next week or so.

a further question

we use IO16 and IO17 for pSRAM in the future/psram_malloc branche.

the D2WD and PICO use this pins for the eMbedded Flash / packaged SPI Flash.

is there in 3.0 support for both ( menuconfig ) or is converted from 3.0 on this "newer" pin assignment

i wonder cause D2WD was the state for CS and CLK for pSRAM TBD

and previous and today's hw design based on IO16, IO17.

this can remain so (over menuconfig pin assignment) or is generaly newly assigned?

txs

best wishes
rudi

[ESP_igrr]

Hi Rudi,
In 3.0, we don't have support for pSRAM + D2WD or pSRAM + PICO planned. Most likely will be done in the version after 3.0.

[rudi ;-)]

Hi Rudi,
In 3.0, we don't have support for pSRAM + D2WD or pSRAM + PICO planned. Most likely will be done in the version after 3.0.

Hi Ivan
no problem, i had a try to figured it out in "future/psram_malloc branch" for a first start with pSRAM now - looks very good
( no more guru with wrong config pins ).
cause the SPI Flash work with 3.3V, must connect 3.3V pSRAM now - hope the lines not disturb other lines in the SIP, finger crossed,
know we have "only" rev0 here as test board, so the note on bugs are valid for this too.

best wishes
rudi

[rudi ;-)]

Hi Rudi,
In 3.0, we don't have support for pSRAM + D2WD or pSRAM + PICO planned. Most likely will be done in the version after 3.0.

today done now

D2WD need 1.8V PSRAM
PICO need 3.3V PSRAM ( PICO-D4, CORE_V2, CORE_V3 Boards )

thank you

best wishes
rudi

[rudi ;-)]

It is now almost 3 months since the the experimental feature/psram_malloc branch was released.
Can we get some information about the current status of psRAM support development, its future, will it be merged into esp-idf v3.0. ?
The psRAM functionality mostly works, but there are some problems, and the feature/psram_malloc branch is 655 commits behind the master...
As more ESP32 modules with psRAM integrated are available, I think it is important to get full, reliable support for it in the master esp-idf branch as soon as possible...

look promissed :
step1
step2
step3


( txs jeroen! )

[sintech]

Yesterday I compiled hello world example using latest esp-idf to run it on ALB-WROVER module.
PSRAM was successfully initialized and tested by internal functions.
I have noticed that currently PSRAM only mapped to ESP32 memory space but not available via heap to be malloced.
Looking forward for new commits.
Please provide us with updated binary toolchain for windows/linux with support for "SPIRAM_CACHE_WORKAROUND".

[ESP_igrr]

sintech: we are working on the toolchain release. It touches a fair number of things (not only pSRAM support), so we need to have some updates prepared on the IDF side before we can switch to the new toolchain. If all goes well, we will have it released tomorrow.

[loboris]

I have an issue with psram support in esp-idf master.
I've done some simple tests and everything works fine, except for one thing:
memcmp fails when running with flash @80MHz & spiram @80MHz, other speed combinations runs without issue.
Two spiram memory regions are filled using memset function (alternating 0xA5 & 0x5A in subsequent passes), then compared using memcmp.
Comparing the memory byte by byte in loop passes.
What is also interesting is the fact that comparing the memory byte by byte is 65% faster then comparing with memcmp (in speed configurations where memcmp passes).
Tested on ESP32-WROVER.

Tested also on AnalogLamb's ALB32-WROVER, but it can only run at flash @40MHz, so I couldn't test the issue with spiram @80MHz.