I have long wondered why - in contrast to other MCUs architectures - there is so much discussion and speculation about free memory management on ESP32. This seems to be not only a compiler problem, as discussed here, but above all a general memory management problem and the understanding of the internal structure and its limits. Not only after compilation the memory usage is relevant, also during runtime the memory limits must be dynamically recognizable. I realize that this thread is not the best place for my question, but there is a strong inner relationship to the discussion in this thread, since there is obviously no really reliable information. There is too much speculation.
My question seems old but still unanswered: What exactly is the difference when calculating the heap with esp_get_free_heap_size() or with esp_get_minimum_free_heap_size()? I don't think the heap return value with esp_get_free_heap_size() is realistic enough, but when the value is used to allocate memory, there are crashes that indicate that apparently more than the largest possible allocable memory is mentioned. So why esp_get_free_heap_size()?
Any idea what the memory secrets are?
Understanding free heap memory
Re: Compiler does not report space taken by big char arrays??
Please see esp_get_free_heap_size and esp_get_minimum_free_heap_size. Former returns current free heap size, which is the sum of sizes of every free block in heap. The latter returns the minimum free heap size that was ever seen during program execution.
Because blocks are not contiguous, the maximum size you will be able to allocate from the heap will always be smaller than the value returned by esp_get_free_heap_size. To get the size of the largest available block of heap memory, you can call heap_caps_get_largest_free_block.
Because blocks are not contiguous, the maximum size you will be able to allocate from the heap will always be smaller than the value returned by esp_get_free_heap_size. To get the size of the largest available block of heap memory, you can call heap_caps_get_largest_free_block.
Re: Compiler does not report space taken by big char arrays??
Hi artkeller,
In addition to Ivan's answer, you may find this summary of heap information functions useful:
https://docs.espressif.com/projects/esp ... nformation
And there's an explanation of "heap capabilities" here: https://docs.espressif.com/projects/esp ... alloc.html
I deleted the duplicate copy of this question in another thread. Please don't post duplicates.
In addition to Ivan's answer, you may find this summary of heap information functions useful:
https://docs.espressif.com/projects/esp ... nformation
And there's an explanation of "heap capabilities" here: https://docs.espressif.com/projects/esp ... alloc.html
I deleted the duplicate copy of this question in another thread. Please don't post duplicates.
-
- Posts: 15
- Joined: Mon Sep 10, 2018 8:58 am
Re: Compiler does not report space taken by big char arrays??
I have the same problem with large arrays and heap limitations.
heap_caps_get_largest_free_block(8) returns 113K bytes and ESP.getFreeHeap() returns 285K bytes.
heap_caps_get_largest_free_block(8) returns 113K bytes and ESP.getFreeHeap() returns 285K bytes.
If the largest contiguous heap block is 113KB does this mean making 2 arrays of 60KB with malloc is possible? I tried splitting a 115200 byte array into 2 half size arrays in my program but I get the same exception as having 1 large array .ESP_igrr wrote: Because blocks are not contiguous, the maximum size you will be able to allocate from the heap will always be smaller than the value returned by esp_get_free_heap_size. To get the size of the largest available block of heap memory, you can call heap_caps_get_largest_free_block.
Re: Compiler does not report space taken by big char arrays??
I've split these posts into a new thread because they're not really related to the original posts (which were about static memory usage).
The simpler way to do this is to just call malloc(60*1024) twice and then check if either pointer is NULL. If either pointer is NULL, allocation failed as there wasn't a large enough free block.
Maybe. There isn't enough information to know this for certain. If the largest contiguous free heap block is 113KB then you can definitely allocate one 60KB block, but this single block is not large enough for two 60KB to fit in it (60+60=120, 120>113). The second 60KB may have to fit in the second largest free block, and you don't know how big the second largest free block is. So you'd need to check the largest contiguous heap block a second time (after the first allocation) to make sure you have enough room.petersanch wrote: If the largest contiguous heap block is 113KB does this mean making 2 arrays of 60KB with malloc is possible? I tried splitting a 115200 byte array into 2 half size arrays in my program but I get the same exception as having 1 large array .
The simpler way to do this is to just call malloc(60*1024) twice and then check if either pointer is NULL. If either pointer is NULL, allocation failed as there wasn't a large enough free block.
Who is online
Users browsing this forum: Google [Bot] and 122 guests