 FreeRTLS memory allocation schemes In this section I will describe more in details memory management schemes possible to be used within FreeRTLS applications within FreeRTLS configuration FreeRTLS config.h file in particular we are specifying few important parameters related to memory allocation used by FreeRTLS type of memory allocation static dynamic or mixed we will focus within this training only on dynamic memory allocation then size of RAM space dedicated to FreeRTLS it is called total heap size given in bytes and the third one is a memory management scheme where we can select among heap1, heap2, heap3, heap4 and heap5 options on next slides I will describe more in details the differences among those heap files in majority of memory management schemes FreeRTLS heap is located on FreeRAM area outside of existing stack and heap areas of the MCU the only exception is heap3 model within heap3 model we have full control on memory allocation by creating our own linker file and our own methods to allocate and to release the memory let's have a closer look on each memory management scheme prepared within FreeRTLS we will start from the simplest one, heap1 all of the functions supporting this memory management scheme allocated within heap underscore 1.c file it uses the first-fit algorithm to allocate memory it is a simplest allocation method it is deterministic but doesn't allow release of allocated memory it could be interesting when a no-memory release is necessary so in the situation when within our FreeRTLS-based application we create all of the components at the beginning of the operating system run and then we do not perform any operation and a change within its structure the second model, heap2, is an obsolete one it is kept due to compatibility reasons it implements the best-fit algorithm for memory allocation and it implements as well the release memory functions but it doesn't combine the released blocks into the bigger ones it is stored within heap underscore 2.c file the third model, heap3, starts within heap underscore 3.c file is a model which needs to be implemented fully by the user it is using the heap area which is common with the mcu heap area and user needs to prepare the linker file and its own implementation of the functions for memory allocation and memory release we will not focus on this model within this training session the last two models are the most popular ones heap4 is selected for the mcu's where we have continuous RAM area while heap5 allows us to concatenate different RAM areas available in the system let's start from heap4 heap4 is using first-fit algorithm to allocate memory it is able to combine the three memory blocks into the single block this model is used in all of the stm32cub examples it is stored within heap underscore 4.c file complete memory allocation is done automatically by prepared port functions based on our configuration in particular total heap size we don't need to modify here anything but if you would like to declare our own memory array used by heap4 we can do it for this we need to declare config application allocated heap we need to set it to 1 within 3.config.h file and then we need to specify the array its name is uc heap what we can see here and the type is unsigned int 8bit and the size of this buffer should be config total heap size it is important to understand how the memory size to be allocated is calculated each call of pvport malloc apa function from heap4 consumes 8 bytes for the structure of the heap linked list then we've got n bytes for the data to be allocated itself and we need to add some padding data to be aligned to 8 bytes so for example if we are trying to allocate 52 bytes we need in fact 52 plus 8 which is 60 bytes and then we need to align it to 8 bytes and the nearest value aligned to 8 bytes is 64 so to allocate 52 bytes we will use in fact 64 bytes of RAM memory from the heap the last memory management scheme heap5 is used in case we have mcu with some RAM areas not visible as a continuous memory space it uses the fit algorithm able to combine free memory blocks into a single block using the same algorithms like in heap4 but it is supporting different memory regions being not in a linear memory space it is the only memory allocation scheme this must be explicitly initialized before any operating system object can be created so before any first call of pvport malloc function to initialize this scheme we need to call the function vport define heap regions this function is specifying start address and size of each separate memory area we would like to dedicate for as a heap for our operating system application on the next slide I will present the example for stm32l476 device with two different RAM areas sram1 and sram2 which are not in linear space in this example we need to build our free address heap from two areas one from sram1 and the second one from sram2 to do this we need to define heap region underscore t type array where in each row we will specify start address of the area starting from lower addresses and its size in bytes then the second one to terminate the array we need to specify a region with null and zero arguments like on a below example then we need to call vport define heap regions before calling any operating system create function let's have a closer look what we will find in each heap.c file there are two most important components there the first one is a function to allocate the memory area it is always named pvport malloc and the second one is a function to release the memory area it is called pvport3 pvport malloc is implemented in most of the heap models except heap3 which needs to be implemented fully by the user it is starting from freezing of all the tasks then in case it is the first call of memory allocation it is initializing the operating system heap the next step it is checking whether the requested block size is not bigger than the available memory size and if it's inline the function is allocating the memory block with proper alignment which we discussed a bit before at the end it is unfreezing all the tasks in case of any memory allocation error there is an execution of vapp malloc failed hook which should be enabled within the configuration of freeR2S and is informing us about any anomalies related to memory allocation pvport3 is present in heap3, heap4 and heap5 as you remember heap1 doesn't allow us to release the memory this is why it is not present there it is starting from freezing of all the tasks then it is adding the memory segment of available memory so in case the memory scheme allows us to concatenate the free areas it is done in this place and then at the end it is unfreezing all the tasks thank you for watching this video