C++ STM32H7 + TouchGFX + ThreadX + ESP32 MQTT - heap allocation

[PAdam.11]

Hi, I'm working under not very restricted medical device with WiFi logging. This is quite a big project, requires processing of many string data so I want some easier tools. I know that in general it is not good to use heap on embedded, but H7 seems to have so much resources.

One part is communication with ESP32 - it has UART interface with custom JSON string protocol based on cJSON library. This library parses cstring to heap allocated structure, and in the same function free it. I added custom smart pointer wrapper to make it safer in deallocating.

To further secure messaging I use custom option wrapper (like optional in >= C++20) - agan move semantics.

Mostly I use std::strings to construct messages provided to ESP32, pass it between functions hoping that move semantics works.

I know what is heap segmentation.

And my questions:

1. is move semantics with rule of zero works when compiling with -std=gnu++14?
2. relatively short strings are processed on stack, is it true in embedded?
3. can I use heap allocation for processing temporary strings without worry about segmentation?
4. how can I check/profile dynamic memory in STM32CubeIDE to see if segmentation happens? Seems memory map shows only static memory.
5.  

Thank you for help 😀

[Piranha]

You probably mean fragmentation. When one allocates arbitrary sized blocks, nothing can save from fragmentation. On Cortex-A and desktop class PCs the virtual memory saves from the fragmentation of physical memory, but still it cannot solve the problem of a fragmentation of the virtual address space for a particular process. The only thing, which can solve the problem for specific cases, is using of a memory pools of equal-sized blocks.

[PAdam.11]

Hi, thank you for answer. I was searching for some information about memory pools, it seems it is not very popular topic. Do you have any resources how to use ThreadX's byte pools in dynamic allocation?

[Piranha]

https://learn.microsoft.com/en-us/training/modules/threadx-memory-management/3-memory-management

Still byte pools have a fragmentation risk.

[MHank.1]

Memory management can be a real problem, as others have stated fragmentation eats up memory quick when you have various size allocation blocks.

Another way around this problem is using the size of the biggest block you need and use that as an allocation page. If the sizes are pretty close in size you will be OK if not you will waste a lot of memory.

[Piranha]

And that brings us to the fixed-size block pools, which are also described in the link I gave.