implement allocator-api via allocator-api2 crate

[liebman]

Motivations

Now that we have an allocator that supports multiple heaps we need to be able to choose where something is allocated.

Solution

We should consider using this crate to provides the api in a stable environment. I'll admit I've not looked deeply into this, but for some things being able to specify to allocate from psram (or NOT from psram) would be helpful.

Thoughts?

[MabezDev]

Do you have an idea of how it might work?

Currently, we only have one allocator, so being able to specify the allocator on collections like Vec isn't that helpful. We also have the complication that we may or may not have a psram allocator, and we won't know until runtime. Maybe a psram allocator that has so psram attached is fine, it will just fail to allocate I anything I guess?

[bugadani]

Currently, we only have one allocator

Wellactually :) If we implement the api for PSRAM, we can specify some types to be placed in PSRAM with this.

Sometimes this might come handy, not knowing until runtime may be fine in some systems.

Maybe a psram allocator that has so psram attached is fine, it will just fail to allocate I anything I guess?

Yes!

[bjoernQ]

In future we might add more ways to decide from which memory we need to allocate (not sure we need it but allowed alignment, able to execute code etc. comes to my mind)

I could think of a way to get an Allocator api implementation from esp-alloc matching a given EnumSet<MemoryCapability>

[MabezDev]

I think this might be as simple as:

pub struct PsramAllocator(&'static EspHeap);

pub static PSRAM_ALLOCATOR: PsramAllocator = PsramAllocator(&HEAP);

and then impl GlobalAlloc for PSRAM_ALLOCATOR which always uses MemoryCapability::External when allocating via the internal heap.

We'd probably want an example that show cases this with the allocator-api2 crate.