heap-management: Use C memory management APIs

[AhmedIsmail02]

Description

We shouldn't be allocating heap using C and FreeRTOS heap management APIs as we might end up with both FreeRTOS heap and C heap. This can lead to several unexpected issues.

C standard heap functions are used to unify heap allocations as we can't use FreeRTOS heap management APIs because this would require patching lots of file as part of
ml-embedded-evaluation-kit library which use C standard heap functions for heap allocations.

Heap space is increased by 0x10000 as C standard heap management APIs requires more heap space for the existing FRI applications because it is less optimised than FreeRTOS heap management APIS (heap_4).

Test Steps

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[archigup]

Couldn't this just set the FreeRTOS heap to heap 3 which wraps malloc and free?
See: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/MemMang/heap_3.c

[AhmedIsmail02]

Couldn't this just set the FreeRTOS heap to heap 3 which wraps malloc and free? See: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/MemMang/heap_3.c

@archigup Indeed, I've tried to use heap_3 sample implementation. However, it did not work in our case as we would still need the symbols for xPortGetFreeHeapSize() and xPortGetMinimumEverFreeHeapSize() functions as they are used as part of FreeRTOS plus TCP library even if heap3 implementation is used where in case of heap3 implementation, these functions are not defined. The part of the code that uses xPortGetFreeHeapSize() and xPortGetMinimumEverFreeHeapSize() is not used in our project but Arm Compiler for Embedded toolchain requires symbols to be defined even if the function containing the symbols is to removed by the linker. Please refer to this comment where i explained why we've added these dummy implementations.

[urutva]

@archigup In addition to issue explained by @AhmedIsmail02, the main driver for the decision to switch to C memory management instead of FreeRTOS memory management is that, the middleware used by the FRI like ml-embedded-evaluation-kit and tflite-micro uses C memory management APIs. In order to use heap_3, the middlewares need to an override of C memory management APIs to call pvPortMalloc and vPortFree, which in turn calls the overridden C memory management APIs. Also, having two heap implementation (C and FreeRTOS memory management) is not recommended as it can lead to unexpected issues. Therefore, we decided to only use C memory management APIs.

[hugueskamba]

@archigup @chinglee-iot @aggarg
I hope you are all well.
Are you able to merge this?