Memory functions implementation and wrapping

[sergiotomasello]

• switched from heap_3.c to heap_4.c (FreeRTOS 10.2.0).
• implemented realloc and calloc in heap_4.c.
• renamed heap_4.c to heap_4bis.c.
• wrapped system memory functions to FreeRTOS memory functions via linker options.

[sergiotomasello]

Hi @BriscoeTech are there any chances that PR will be merged and released a new version? Thank's for your job Regards

[BriscoeTech]

Hello sergiotomasello,

Thanks for the additions! I have been wanting something like this for awhile now, and think it will solve some issues people are having in the issue tracker. I am hoping to sit down and play with it later this week.

I do have a question for you, what will happen if someone downloads the library without turning on the linker option? Will it essentially be the same as the original heap_4 and only manage the rtos objects? Just want to make sure that code would still compile and run without the linker setting being changed.

Talk to you soon!

[sergiotomasello]

Thanks for your quick reply @BriscoeTech,

I do have a question for you, what will happen if someone downloads the library without turning on the linker option? Will it essentially be the same as the original heap_4 and only manage the rtos objects? Just want to make sure that code would still compile and run without the linker setting being changed.

if you don't make changes in the linker options, it should works as before. @godario can confirm and give you a better explanation.

[godario]

Hi BriscoeTech, without turning on the linker option simply the functions of the malloc family continue to be the default gcc compiler functions; in this way the only advantage would be to have a thread-safe implementation of realloc and calloc. From our tests we have seen that, once the freertos scheduler was launched, the default malloc and realloc functions always fail (returning always NULL), and therefore all the functions that use it (eg String object from Wstring.h). Clearly, turning on the linker option, all the libraries and functions that use the malloc family functions work again. Regards

[BriscoeTech]

hello @sergiotomasello and @godario ,

I seem to have run into some unexpected issues using the linker command. After merging the code, I tried modifying my sparkfun samd platform.txt like referenced in the readme, but it does not seem to have worked. Everything compiles and im able to program the board, but the micro controller seems to have locked up and the serial port never enumerates in order to run the Basic_RTOS_Example2.

Attached is the modified platform.txt file, does anything seem obviously wrong? platform.txt

I reverted the merge back to the way things were, and committed the basic Heap_4 to the repo until we figure out what is going on :-)

[godario]

Hi @BriscoeTech , Your platform.txt file seems to be correct. Honestly, I hadn't noticed this problem, so I tried the Basic_RTOS_Example2 sketch and actually the same thing happens to me too. What I understood is that the SerialUSB class does not seem to work until the scheduler is launched, in particular, if you call <<while (! SerialUSB);>> before launching the scheduler, execution stay stucked on this while. Moreover, even omitting this control, no SerialUSB.print() used before the scheduler launch has effect (although the execution proceeds anyway). The SerialUSB class returns to work normally if used after the launch of the scheduler. Despite this strange behavior, it seems that the wrapped malloc works even before the scheduler is launched. I suspect that the cause of the problem is related to interrupts; unfortunately at the moment I have no certainty, but I'm investigating and I'll let you know as soon as possible.