Heap Memory and large Array allocation

Kernel
1

Hi guys,

I’m sure that is not a valid concern, but I prefer to have an answer by those who have more experience than me.

I’m using FreeRTOS 9.0 and heap_4.c for heap memory management.

In order to simplify my question, let us imagine that we use a 8-bit processor (so, a word is a byte)

Now, I need to create a task after creating and deleting another tasks (so, my heap memory can be a little bit fragmented):

ReturnState = xTaskCreate( MyTask,
( char * ) “MyTask”,
4 * configMINIMAL_STACK_SIZE,
( void * ) NULL,
1,
NULL);

Of course, the configTOTAL_HEAP_SIZE is large enough for another task.

MyTask code is the following:

void MyTask( void *pvParameters )
{
 uint8_t MyArray[3*configMINIMAL_STACK_SIZE];

 memset((void *)&MyArray[0],0xA5,sizeof(MyArray));

 printf("The last number of my array is: %d",MyArray[3*configMINIMAL_STACK_SIZE-1]);

 for(;;;) __asm('NOP');
}

In MyTask I’ve created an array with size larger than configMINIMAL_STACK_SIZE. If heap memory is fragmented, FreeRTOS ensure me that the MyArray is allocated to a single memory block ?

Thanks for your reply.

Sincerely,

FlavioB

2

FreeRTOS is not responsible the binary layout of MyArray it‘s just the C/C++ standard.
The same would apply to allocating MyArray from heap provided the heap implementation is standard compliant.
In your case yes, MyArray is contiguous, which can be verified with
sizeof(MyArray) == sizeof(MyArray[0]) * 3*configMINIMAL_STACK_SIZE
because there is no alignment constraint with uint8_t elements.

BTW I’m pretty sure that your code will fail with stack overflow because of using pretty stack hungry printf.

3

The FreeRTOS memory allocation routines can only return the requested memory as a contiguous block, or they will fail and return NULL. If the heap gets too fragmented you get allocation failures, not some strange way to return a disjointed block of memory.

4

Dear Richard and Hartmut.

Thanks for your reply, you have confirmed to me the behavior that I expected.

Sincerely,

FlavioB