I am wondering why is necessary to align PortMalloc blocks?  My MCU is Cortex M3 / STM with 128K RAM. I have large number of small objects and lose 10-15K only for the alignments. Is there any problem if I modify heap_4.c to align at byte boundary? Probably the memory access may be slower but this is less important than memory size. I read that it is not recommended to modify portBYTE_ALIGNMENT macro because it is used for stack alignment.

I read that it is not recommended to modify portBYTE_ALIGNMENT macro because it is used for stack alignment.

Then you have answered your own question :o) You must be allocating a *lot* of blocks to loose 10-15K in alignment padding as the current FreeRTOS release will loose a maximum of 8 bytes per allocation.  The next FreeRTOS release does improve the amount of loss so blocks that are 8 byte aligned already don’t loose any, meaning the maximum loss per allocation is 7. Regards.

I am parsing XML file. All dynamic data is about 47K (about 1500-2000 small objects). I tested with portBYTE_ALIGNMENT = 2 and the free memory difference at the end was about 7K – the percentage (7 of 47) is not small. Maybe it is a good idea to have heap_5.c for “economical” pvPortMalloc. Also I think it is necessary to implement PortRealloc.

Hi, I’m also interested in this topic. Just curious, Is there any specific reason to align the memory for M3 in 8 bytes (is it to resolve some issues)? I realize that the older FreeRTOS sets this value at 4 bytes.

Heap_4.c has been updated in FreeRTOS V7.5.0.

Hi, I’m also interested in this topic. Just curious, Is there any specific reason to align the memory for M3 in 8 bytes (is it to resolve some issues)? I realize that the older FreeRTOS sets this value at 4 bytes.

The ARM ABI is to have 8 byte alignment.  You probably won’t notice any difference unless you start calling library functions that assume 8 byte alignment.  The one that shows this up normally is calling printf() with a %f to format a double precision floating point value. Regards.