Implement an allocator for PSRAM

[JacksonUtsch]

Motivations

• Would you like to implement this feature? y

Solution

Add type to alloc.rs that implements either nightly's or allocator_api2's Allocator

Alternatives

Only use SPIRAM as part of global heap and get corruption errors when utilizing esp-idf or avoid using SPIRAM.

Additional context

Here is my current implementation that seems to not be exactly right.

#[derive(Debug, Clone, Default)]
pub struct SpiAlloc;

unsafe impl allocator_api2::alloc::Allocator for SpiAlloc {
    fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, allocator_api2::alloc::AllocError> {
        unsafe {
            let align = layout.pad_to_align().align();
            let mut size = layout.size();
            if size == 0 {
                size = 1; // avoids returning null
            }
            let raw = heap_caps_aligned_alloc(align, size, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
            if raw.is_null() {
                return Err(allocator_api2::alloc::AllocError);
            }

            let real_size = heap_caps_get_allocated_size(raw);

            let pointer = ptr::slice_from_raw_parts_mut(raw as *mut u8, real_size);
            let non_null = NonNull::new_unchecked(pointer);
            return Ok(non_null);
        }
    }

    unsafe fn deallocate(&self, ptr: NonNull<u8>, _layout: Layout) {
        heap_caps_free(ptr.as_ptr() as *mut _);
    }
}

[ivmarkov]

Even if we do this, we still have to place big bold letters "Do not place atomics in memory allocated in PSRAM".
But the reality is, most users won't even realize if they are doing this, as this is super-hard to track, especially if you expose to them a generic allocator API like the one you suggest.

I think a better approach might to just let users enable PSRAM allocations via malloc, but then detect this enablement when compiling esp-idf-sys and generate a compile-time error if the user is not compiling against THE special JSON esp-idf esp32 or esp32s3 target that would prevent corruption errors in that case.

EDIT: In fact, we can also have your solution in addition to the one I just described, but then your solution should also fail at compile-time if compiled against a non-JSON target.

[ivmarkov]

See #406