I was going through heap_2.c in the MemMang folder in FreeRTOS V7.4.2 source to understand it. I have compared heap_2.c with the latest vesrion too, this file remains more of less the same, so I did not move over to the newest version of FreeRTOS to get a newer version of heap_2.c. After going through the code, I have a few doubts.
Why is configTOTAL_HEAP_SIZE defined with a** size_t** type e.g. “#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 19 * 1024 ) )” and size_t is used in a few other places as well in heap_2.c? What is the benefit of it ?
Why does size of** xBlockLink**, blocks and** xWantedSize** need to be aligned or adjusted to the nearest word (4 bytes in case of Cortex M4), is it because some controllers are not capable of unaligned access ?
To save stack depth prvInsertBlockIntoFreeList macro is defined in heap_2.c, whereas** prvHeapInit** is an independent function in the same file even though prvHeapInit is a static function as well. What are the considerations for using macros or functions here?
In recent versios of FreeRTOS, heap_4.c is normally used in favour of heap_2.c.
size_t is used for its portability - FreeRTOS runs on 8-bit up to 64-bit hardware.
Alignment is a requirement of many processors, especially the alignment of the stack. Each port has the required alignment defined - breaching the alignment can result in mis-calculations, or complete crashes.
prvHeapInit is only called once, whereas prvInsertBlockIntoFreeList is called on each allocation, hence the latter is written as a macro to make it faster and use less stack. More important on small processors than large processors.
Thank you very much. I am planning to make a Youtube video on memory allocation for deeply embedded systems. I want to explain it using the heap_x.c files from FreeRTOS. I will maintain the copyrights as is. I will be using the evaluation version of the IAR compiler for this.
Please let me know if there is anything specific that I need to abide by if I use your code for the training.