diff options
| author | mrfaptastic <12006953+mrfaptastic@users.noreply.github.com> | 2020-08-03 14:10:32 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-08-03 14:10:32 +0100 |
| commit | d1dfa833037420aad9c48732ee229554fa88f261 (patch) | |
| tree | 2d7802eebbbd31801204a8c8b7c3b628f41fa1af | |
| parent | 54d6e485b9901dc2cf159bbdd4ef9b2e8467933a (diff) | |
Update SPLIT_MEMORY_MODE.md
| -rw-r--r-- | SPLIT_MEMORY_MODE.md | 7 |
1 files changed, 6 insertions, 1 deletions
diff --git a/SPLIT_MEMORY_MODE.md b/SPLIT_MEMORY_MODE.md index 903bdf0..52a7a01 100644 --- a/SPLIT_MEMORY_MODE.md +++ b/SPLIT_MEMORY_MODE.md @@ -1,10 +1,15 @@ # SPLIT_MEMORY_MODE -Aka. the enabling of the 'feature' (enabled by default) with: + +### New Feature + +With version 1.1.0 of the library onwards, there is now a 'feature' to split the framebuffer over two memory 'blocks' (mallocs) to work around the fact that typically the ESP32 upon 'boot up' has 2 x ~100kb chunks of memory available to use (ideally we'd want one massive chunk, but for whatever reasons this isn't the case). This allows non-contiguous memory allocations to be joined-up potentially allowing for 512x64 resolution or greater (no guarantees however). This is enabled by default with: + ``` #define SPLIT_MEMORY_MODE 1 ``` ...in 'ESP32-RGB64x32MatrixPanel-I2S-DMA.h' + ## What is it trying to resolve? For whatever reason (and this may not be consistent across all ESP32 environments) when `heap_caps_print_heap_info(MALLOC_CAP_DMA)` is executed to print information about the available memory blocks that are DMA capable (which we need for a DMA-enabled pixel framebuffer), you may see something like this: |
