heap: Refactor heap regions/capabilities out of FreeRTOS

Remove tagged heap API, rename caps_xxx to heap_caps_xxx

Also includes additional heap_caps_xxx inspection functions.
This commit is contained in:
Angus Gratton
2017-05-03 18:03:28 +10:00
committed by Angus Gratton
parent 5ee49fd311
commit 71c70cb15c
37 changed files with 1166 additions and 995 deletions

View File

@@ -9,19 +9,15 @@ possible to connect external SPI flash to the ESP32; it's memory can be integrat
the flash cache.
In order to make use of all this memory, esp-idf has a capabilities-based memory allocator. Basically, if you want to have
memory with certain properties (for example, DMA-capable, accessible by a certain PID, or capable of executing code), you
memory with certain properties (for example, DMA-capable, or capable of executing code), you
can create an OR-mask of the required capabilities and pass that to pvPortMallocCaps. For instance, the normal malloc
code internally allocates memory with ```pvPortMallocCaps(size, MALLOC_CAP_8BIT)``` in order to get data memory that is
code internally allocates memory with ```heap_caps_malloc(size, MALLOC_CAP_8BIT)``` in order to get data memory that is
byte-addressable.
Because malloc uses this allocation system as well, memory allocated using pvPortMallocCaps can be freed by calling
Because malloc uses this allocation system as well, memory allocated using ```heap_caps_malloc()``` can be freed by calling
the standard ```free()``` function.
Internally, this allocator is split in two pieces. The allocator in the FreeRTOS directory can allocate memory from
tagged regions: a tag is an integer value and every region of free memory has one of these tags. The esp32-specific
code initializes these regions with specific tags, and contains the logic to select applicable tags from the
capabilities given by the user. While shown in the public API, tags are used in the communication between the two parts
and should not be used directly.
The "soc" component contains a list of memory regions for the chip, along with the type of each memory (aka its tag) and the associated capabilities for that memory type. On startup, a separate heap is initialised for each contiguous memory region. The capabilities-based allocator chooses the best heap for each allocation, based on the requested capabilities.
Special Uses
------------
@@ -39,4 +35,3 @@ API Reference - Heap Regions
----------------------------
.. include:: /_build/inc/heap_regions.inc