It could definitely be an issue. Application could utilize memory pools to get around memory fragmentation. If the application requires to allocate and release memory often with different sizes, perhaps pre-allocation of such memory would help. Please take a look at the ThreadX memory block pools and memory byte pools as well.
Thanks for the info, do you by any chance know if calling calloc_named in WICED is using ThreadX block or byte allocation? I'm trying to find where WICED is handling the ThreadX memory allocation but i couldn't find it. Thanks
PS. From mallinfo() i can see it shows in block but i'd like to check the details and finetune to what's best for my application for system wide memory allocation using standard calloc.
For any application, user may create a memory pool with a name attached to it either byte or block. If requested pool could not be created return status would indicate the error code. Using the named memory pool new memory could be allocated or released. ThreadX gives that flexibility to the user.
Hope it helps.
The problem is WICED SDK doesn't seems to allow you to play around with ThreadX memory allocation directly. As far as i can see we only have control over memory is with malloc, calloc, and other C standard memory usage.
ThreadX and NetX do not use malloc internally and so any heap fragmentation would be be an application problem. If your application mallocs and frees memory regularly but in a systematic fashion you should not have an issue with fragmentation.
WICED generally follows that rule with a few exceptions:
1) Scan results
2) TLS packet processing
3) TLS certificate processing
4) WPS workspace
WICED does not provide an interface to the ThreadX memory management functions however your application is free to include the ThreadX header and use those functions directly.