Reducing internal memory on PSRAM variants
Posted: Mon Jan 13, 2020 12:26 pm
What can I do on a complex project to get it to use as much PSRAM rather than internal as possible? I'd like to get the behavior described for CONFIG_SPIUSE wherein malloc() starts handing it out, but I'm using the Arduino SDK.
I've got a demanding project where WiFi won't connect because I only have about 170K of RAM left by the time loop() starts (using Ardunino, or when you create your tasks in IDF).
I've got a PSRAM version of the chip where I can move allocated buffers, but what about the rest of the 8 or so libraries that I'm linking in, like WiFi() itself for example. They could be doing their 32-bit allocs out of PSRAM as well, could they not? This would free up more internal RAM.
Basically, I have DMA stuff that must remain low but I have buffers that can go anywhere 32-bit. Plus I have all the builtin library code, so I'm trying to figure out what my best strategy is for maximizing low memory.
Part of me wonders if I "#define" malloc() and new() early enough but that feels like a bad hack, so thought I'd better look for advice before I do anything silly!
I've got a demanding project where WiFi won't connect because I only have about 170K of RAM left by the time loop() starts (using Ardunino, or when you create your tasks in IDF).
I've got a PSRAM version of the chip where I can move allocated buffers, but what about the rest of the 8 or so libraries that I'm linking in, like WiFi() itself for example. They could be doing their 32-bit allocs out of PSRAM as well, could they not? This would free up more internal RAM.
Basically, I have DMA stuff that must remain low but I have buffers that can go anywhere 32-bit. Plus I have all the builtin library code, so I'm trying to figure out what my best strategy is for maximizing low memory.
Part of me wonders if I "#define" malloc() and new() early enough but that feels like a bad hack, so thought I'd better look for advice before I do anything silly!