Shulou(Shulou.com)06/01 Report--

Most people do not understand the knowledge points of this article "how to manage the memory of the FreeRTOS real-time operating system", so the editor summarizes the following, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to manage the memory of the FreeRTOS real-time operating system" article.

FreeRTOS provides several memory heap management solutions, ranging from complex to simple. The simplest management strategy can also meet the requirements of many applications, such as applications with high security requirements, which do not allow dynamic memory allocation at all.

FreeRTOS also allows you to implement memory heap management yourself, and even allows you to use two memory heap management solutions at the same time. The simultaneous implementation of the two memory stacks allows task stacks and other RTOS objects to be placed in a fast internal RAM, and application data to a low-speed external RAM.

The RTOS kernel assigns RAM to tasks, queues, mutexes, software timers, semaphores, or event groups whenever they are created. The malloc () and free () functions in the standard library can sometimes be used to accomplish this task, but:

They are not always available in embedded systems

They will take up more valuable code space.

They don't have thread protection.

They are not deterministic (the execution time of each call may be different)

Therefore, it is often necessary to provide an alternative memory allocation scheme.

Embedded / real-time systems have different RAM and time requirements, so an RAM memory allocation algorithm may only belong to a subset of an application.

To avoid this problem, FreeRTOS retains the memory allocation API function at the migration layer. The migration layer is outside the RTOS core code source file (not part of the core source code), which allows different applications to provide their own application implementation. When the RTOS kernel needs RAM, the pvPortMallo () function is called instead of the malloc () function. When RAM is about to be released, the vPortFree () function is called instead of the free () function.

Five simple memory allocation implementations are available in the FreeRTOS download package, which will be described later in this article. Users can choose one of them appropriately, or they can design their own memory allocation strategy.

The memory allocation schemes provided by FreeRTOS are located in different source files (heap_1.c, heap_2.c, heap_3.c, heap_4.c, heap_5.c), which are located in the download package\ FreeRTOS\ Source\ portable\ MemMang folder. Other implementation methods can be added as needed. If you want to use the memory heap allocation scheme provided by FreeRTOS, the selected source file must be correctly included in the project file.

1.heap_1.c

This is the simplest of all implementations. Once memory is allocated, it does not even allow the allocated memory to be freed. Even so, heap_1.c is suitable for most embedded applications. This is because most deep embedded (deeplyembedded) applications simply create all tasks, queues, semaphores, etc., at system startup, and use them until the end of the program, never need to be deleted.

When you need to allocate RAM, this memory allocation scheme simply subdivides a large array into a subset. The capacity size of the large array is set by the configTOTAL_HEAP_SIZE macro in the FreeRTOSConfig.h file.

The API function xPortGetFreeHeapSize () returns the total amount of unallocated stack space, which allows configTOTAL_HEAP_SIZE to be reasonably set.

Function introduction:

For applications that never delete tasks, queues, semaphores, mutexes, etc. (in fact, most applications that use FreeRTOS meet this condition)

The execution time is determined and does not produce memory fragmentation

The implementation and allocation process is very simple, and the required memory is allocated from a static array, meaning that this memory allocation is usually only applicable to applications that do not make dynamic memory allocation.

2.heap_2.c

Unlike scenario 1, this scheme uses a best matching algorithm that allows previously allocated blocks of memory to be released. It does not combine adjacent free blocks into a larger block (in other words, this results in memory fragmentation).

The valid stack space size is defined by the configTOTAL_HEAP_SIZE macro located in the FreeRTOSConfig.h file.

The API function xPortGetFreeHeapSize () returns the size of the remaining unallocated stack space (which can be used to optimize the value of the configTOTAL_HEAP_SIZE macro), but does not provide fragmentation details of unallocated memory.

Function introduction:

Can be used to repeatedly allocate and delete tasks, queues, semaphores, mutexes, and so on, with the same stack space, regardless of memory fragmentation.

Applications that cannot be used to allocate and free random byte stack space

If an application dynamically creates and deletes tasks, and the stack space allocated to the task is always the same, then heap_2.c is available in most cases. However, if the stacks allocated to the task are not always equal, the available memory freed may be fragmented, forming many small blocks of memory. In the end, memory allocation fails because there is not enough contiguous stack space. In this case, heap_4.c is a good choice.

If an application dynamically creates and deletes queues, and in each case the queue storage area (the queue storage area refers to the number of queue items multiplied by each queue length) is the same, then heap_2.c can be used in most cases. However, if the queue store is not always equal in each case, the available memory freed may be fragmented, forming many small blocks of memory. In the end, memory allocation fails because there is not enough contiguous stack space. In this case, heap_4.c is a good choice.

The application calls the pvPortMalloc () and vPortFree () functions directly, not just indirectly through FreeRTOS API.

If queues, tasks, semaphores, mutexes, and so on in your application are in an unpredictable order, it may cause memory fragmentation problems, although this is a small probability event, but it must be kept in mind.

It is not deterministic, but it is much more efficient than the malloc function in the standard library.

Heap_2.c is suitable for most small real-time systems (smallreal time) that need to create tasks dynamically.

3.heap_3.c

Heap_3.c simply wraps the malloc () and free () functions in the standard library, and the wrapped malloc () and free () functions have thread protection.

Function introduction:

The linker is required to set up a stack, and the compiler library provides malloc () and free () functions.

Lack of certainty

May significantly increase the code size of the RTOS kernel

Note: with heap_ 3, the configTOTAL_HEAP_SIZE macro definition in the FreeRTOSConfig.h file has no effect.

4.heap_4.c

This scheme uses a best matching algorithm, but not like scenario 2. It merges adjacent free memory blocks into a larger block (including a merge algorithm).

The valid stack space size is defined by the configTOTAL_HEAP_SIZE located in the FreeRTOSConfig.h file.

The API function xPortGetFreeHeapSize () returns the size of the remaining unallocated stack space (which can be used to optimize the value of the configTOTAL_HEAP_SIZE macro), but does not provide fragmentation details of unallocated memory.

Function introduction:

Applications that can be used to re-assign, delete tasks, queues, semaphores, mutexes, and so on.

Situations that can be used to allocate and free random bytes of memory do not produce severe fragmentation as heap_2.c does.

It is not deterministic, but it is much more efficient than the malloc function in the standard library.

Heap_4.c is also particularly suitable for porting layer code, where you can directly use the pvPortMalloc () and vPortFree () functions to allocate and free memory.

5.heap_5.c (added to V8.1.0)

This scheme also implements the merge algorithm in heap_4.c and allows the stack to span multiple discontiguous memory areas.

Heap_5 initializes by calling the vPortDefineHeapRegions () function, which does not allow memory allocation and freeing until the function is finished. Creating RTOS objects (tasks, queues, semaphores, and so on) implicitly calls pvPortMalloc (), so it is important to note that the vPortDefineHeapRegions () function is executed before using heap_5 to create any objects.

The vPortDefineHeapRegions () function only takes a single argument. This parameter is an array of HeapRegion_t struct types. HeapRegion_t is defined in portable.h, as follows:

Typedef struct HeapRegion {/ * memory block start address for memory heap * / uint8_t * pucStartAddress; / * memory block size * / size_t xSizeInBytes;} HeapRegion_t

The array must end with a NULL pointer and a 0-byte element, and the starting address must be arranged from smallest to largest. The following code snippet provides an example. The MSVCWin32 simulator demo routine uses heap_5, so it can be used as a reference routine.

/ * allocate two memory blocks to the memory heap in memory. The first memory block 0x10000 bytes, starting address is 0x80000000, the second memory block 0xa0000 bytes, starting address is 0x90000000. The starting address of the memory block with the starting address 0x80000000 is lower, so it is placed at the first position of the array. * / const HeapRegion_t xHeapRegions [] = {{(uint8_t *) 0x80000000UL, 0x10000}, {(uint8_t *) 0x90000000UL, 0xa0000}, {NULL, 0} / * the end of the array. * /}; / * pass the array parameters to the function vPortDefineHeapRegions (). * / vPortDefineHeapRegions (xHeapRegions); the above article is about "how to manage the memory of FreeRTOS real-time operating system". I believe you all have some understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about it, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.