Replace arduino memory functions by esp-idf memory functions

[ewowi]

Preparing for P4 support

(doesn't break non P4 devices)

As discussed here: https://discord.com/channels/1420051709656305724/1420054764846190705/1425481731850502184

[ewowi]

@troyhacks, please review

[troyhacks]

Reviewed, looks good to me.

The step further that can be done is replace key calls with variables or #define options - and then you can select if maybe you want something internal first, PSRAM fallback. Or you can ask for specific memory blocks as there's a wildly huge memory map on the ESP32 family and some have exotic uses - like alignment, DMA capable memory for real-time stuff, or SIMD aligned memory in some cases.

This was intended as a general overhaul of the malloc and calloc stuff to use PSRAM when available. It works. With small RAM, often the crashes we see is lack of heap - and this can help.

[ewowi]

Yeah, agreed.
In further thought I think we should first make P4 support work in MoonLight to avoid a number of pull requests on SvelteKit, possible destabilizing things.

I see this memory handling change as a possible desirable but not 100% required change.

So for now I propose to let @theelims make a decision independent from P4 support whether this is a good addition to SvelteKit. If not at the moment, close this PR and maybe reopen later when P4 is ready in MoonLight and we PR it into the SvelteKit repo.

And later can be very soon 😉, let's see how things go

[theelims]

It seems most changes concern the PsychicHttp lib. While I welcome changes to accommodate the P4, I am not sure if sticking with PsychicHttp is the best way forward. Especially since ESPAsyncWebserver is under active development again. The maintainer expressed his interest to get this working within ESP32-Sveltekit. Back porting the code to ESPAsyncWebserver might be a good case moving forward.

[troyhacks]

I don't think anything in there is a bad idea.

It's touching some of the HTTPd stuff but mostly it was just modern ESP32 programming patterns for memory.

The stuff I do tends to need ... gobs of memory. So PSRAM is in everything I do now.

[theelims]

My favorite module (S3-Mini-1) does not come with PSRAM. Does this work flawless with boards without PSRAM?

[troyhacks]

@theelims yes, it does.

That's the main nice feature of this new "prefer" syntax - you can have a number of preferences (more than the 2 I used in most places here) and it'll try them left to right until something sticks.

You can "or" types of malloc capabilities together to get fancy - but you'll tend to have very specific reasons for that.

Also if you want a certain thing to be in internal RAM for speed reasons (more applicable to boards other than the P4) you can say "I want internal first, fall back to PSRAM" and if there's no PSRAM, it just fails like malloc() would.

You can also store those allocation types as variables so they can be changed on the fly in a running system if you really wanted to. I think you can even realloc() with the prefer syntax to move things around - but don't quote me on that. 😁