http://www.freertos.org/a00111.html

The RTOS kernel allocates RAM each time a task, queue, mutex, software timer or semaphore is created.

The standard C library malloc() and free() functions can sometimes be used for this purpose, but ...

  1. they are not always available on embedded systems,
  2. they take up valuable code space,
  3. they are not thread safe, and
  4. they are not deterministic (the amount of time taken to execute the function will differ from call to call)

... so more often than not an alternative memory allocation implementation is required.

One embedded / real time system can have very different RAM and timing requirements to another -

so a single RAM allocation algorithm will only ever be appropriate for a subset of applications.

To get around this problem, FreeRTOS keeps the memory allocation API in its portable layer.

The portable layer is outside of the source files that implement the core RTOS functionality,
allowing an application specific implementation appropriate for the real time system being developed to be provided.

When the RTOS kernel requires RAM, instead of calling malloc(), it instead calls pvPortMalloc().
When RAM is being freed, instead of calling free(), the RTOS kernel calls vPortFree().

Memory allocation implementations included in the RTOS source code download

The FreeRTOS download includes four sample memory allocation implementations, each of which are described in the following subsections.

The subsections also include information on when each of the provided implementations might be the most appropriate to select.

Each provided implementation is contained in a separate source file (heap_1.c, heap_2.c, heap_3.c and heap_4.c respectively)
which are located in the Source/Portable/MemMang directory of the main RTOS source code download.
Other implementations can be added as needed. Exactly one of these source files should be included in a project at a time.

heap_1.c - Heap secton name is .bss, kind is zero(Zero-initialized),  type is data(Read/write)

This is the simplest implementation of all. It does not permit memory to be freed once it has been allocated.
Despite this, heap_1.cvice versa appropriate for a large number of embedded applications.

This is because the majority of deeply embedded applications create all the tasks, queues, semaphores, etc.
required when the system boots, and then use all of these objects for the lifetime of program
(until the application is switched off again, or is rebooted). Nothing ever gets deleted.

The implementation simply subdivides a single array into smaller blocks as RAM is requested.
The total size of the array (the total size of the heap) is set by configTOTAL_HEAP_SIZE - which is defined in FreeRTOSConfig.h.

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated, allowing the configTOTAL_HEAP_SIZE setting to be optimised.

The heap_1 implementation:

  • Can be used if your application never deletes a task, queue, semaphore, mutex, etc. (which actually covers the majority of applications in which FreeRTOS gets used).
  • Is always deterministic (always takes the same amount of time to execute).
#define MPU_WRAPPERS_INCLUDED_FROM_API_FILE

#include "FreeRTOS.h"
#include "task.h" #undef MPU_WRAPPERS_INCLUDED_FROM_API_FILE /* A few bytes might be lost to byte aligning the heap start address. */
#define configADJUSTED_HEAP_SIZE ( configTOTAL_HEAP_SIZE - portBYTE_ALIGNMENT ) /* Allocate the memory for the heap. */
static unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];
static size_t xNextFreeByte = ( size_t ) ; /*-----------------------------------------------------------*/ void *pvPortMalloc( size_t xWantedSize )
{
}
/*-----------------------------------------------------------*/ void vPortFree( void *pv )
{
/* Memory cannot be freed using this scheme. See heap_2.c, heap_3.c and heap_4.c for alternative implementations,
and the memory management pages ofhttp://www.FreeRTOS.org for more information. */
    ( void ) pv;

    /* Force an assert as it is invalid to call this function. */
configASSERT( pv == NULL );
}
/*-----------------------------------------------------------*/ void vPortInitialiseBlocks( void )
{
/* Only required when static memory is not cleared. */
xNextFreeByte = ( size_t ) ;
}
/*-----------------------------------------------------------*/ size_t xPortGetFreeHeapSize( void )
{
return ( configADJUSTED_HEAP_SIZE - xNextFreeByte );
}

heap_2.c - Heap secton name is .bss, kind is zero(Zero-initialized),  type is data(Read/write)

This scheme uses a best fit algorithm and, unlike scheme 1, allows previously allocated blocks to be freed.
It does not however combine adjacent free blocks into a single large block (it does not include a coalescence algorithm -
see heap_4.c for an implementation that does coalescence free blocks).

The total amount of available heap space is set by configTOTAL_HEAP_SIZE - which is defined in FreeRTOSConfig.h.

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated
(allowing the configTOTAL_HEAP_SIZE setting to be optimised), but does not provided information on
how the unallocated memory is fragmented into smaller blocks.

This implementation:

  • Can be used even when the application repeatedly deletes tasks, queues, semaphores, mutexes, etc., with the caveat below regarding memory fragmentation.
  • Should not be used if the memory being allocated and freed is of a random size.
    For example:Could possible result in memory fragmentation problems if your application queues, tasks, semaphores, mutexes, etc.
    in an unpredictable order. This would be unlikely for nearly all applications but should be kept in mind.
    • If an application dynamically creates and deletes tasks, and the size of the stack allocated to the tasks being created is always the same,
      then heap2.c can be used in most cases.
      However, if the size of the stack allocated to the tasks being created was not always the same,
      then the available free memory might become fragmented into many small blocks,
      eventually resulting in allocation failures. heap_4.c would be a better choise in this case.
    • If an application dynamically creates and deletes queues, and the queue storage area is the same in each case
      (the queue storage area is the queue item size multiplied by the length of the queue),
      then heap_2.c can be used in most cases.
      However, if the queue storage area were not the same in each case,
      then the available free memory might become fragmented into many small blocks,
      eventually resulting in allocation failures. heap_4.c would be a better choise in this case.
    • The application called pvPortMalloc() and vPortFree() directly, rather than just indirectly through other FreeRTOS API functions.
  • Is not deterministic - but is much more efficient that most standard C library malloc implementations.

heap_2.c is suitable for most small real time systems that have to dynamically create tasks.

#define MPU_WRAPPERS_INCLUDED_FROM_API_FILE

#include "FreeRTOS.h"
#include "task.h" #undef MPU_WRAPPERS_INCLUDED_FROM_API_FILE /* A few bytes might be lost to byte aligning the heap start address. */
#define configADJUSTED_HEAP_SIZE ( configTOTAL_HEAP_SIZE - portBYTE_ALIGNMENT ) /*
* Initialises the heap structures before their first use.
*/
static void prvHeapInit( void ); /* Allocate the memory for the heap. */
static unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];

heap_3.c - Heap secton name is HEAP, kind is uninit : __Heap_Handler  = DLMalloc

This implements a simple wrapper for the standard C library malloc() and free() functions that will, in most cases,
be supplied with your chosen compiler. The wrapper simply makes the malloc() and free() functions thread safe.

This implementation:

  • Requires the linker to setup a heap, and the compiler library to provide malloc() and free() implementations.
  • Is not deterministic.
  • Will probably considerably increase the RTOS kernel code size.

Note that the configTOTAL_HEAP_SIZE setting in FreeRTOSConfig.h has no effect when heap_3 is used.

dlmalloc.c : malloc(), free()

Heap Size in *.icf  : define symbol __ICFEDIT_size_heap__   = 0x2000;

/*
* Implementation of pvPortMalloc() and vPortFree() that relies on the
* compilers own malloc() and free() implementations.
*
* This file can only be used if the linker is configured to to generate
* a heap memory area.
*
* See heap_1.c, heap_2.c and heap_4.c for alternative implementations, and the
* memory management pages of http://www.FreeRTOS.org for more information.
*/ #include <stdlib.h> /* Defining MPU_WRAPPERS_INCLUDED_FROM_API_FILE prevents task.h from redefining
all the API functions to use the MPU wrappers. That should only be done when
task.h is included from an application file. */
#define MPU_WRAPPERS_INCLUDED_FROM_API_FILE #include "FreeRTOS.h"
#include "task.h" #undef MPU_WRAPPERS_INCLUDED_FROM_API_FILE /*-----------------------------------------------------------*/ void *pvPortMalloc( size_t xWantedSize )
{
void *pvReturn; vTaskSuspendAll();
{
pvReturn = malloc( xWantedSize );
traceMALLOC( pvReturn, xWantedSize );
}
xTaskResumeAll(); #if( configUSE_MALLOC_FAILED_HOOK == 1 )
{
if( pvReturn == NULL )
{
extern void vApplicationMallocFailedHook( void );
vApplicationMallocFailedHook();
}
}
#endif return pvReturn;
}
/*-----------------------------------------------------------*/ void vPortFree( void *pv )
{
if( pv )
{
vTaskSuspendAll();
{
free( pv );
traceFREE( pv, );
}
xTaskResumeAll();
}
}

heap_4.c - Heap secton name is .bss, kind is zero(Zero-initialized),  type is data(Read/write)

This scheme uses a first fit algorithm and, unlike scheme 2, does combine adjacent free memory blocks into a single large block
(it does include a coalescence algorithm).

The total amount of available heap space is set by configTOTAL_HEAP_SIZE - which is defined in FreeRTOSConfig.h.

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated
(allowing the configTOTAL_HEAP_SIZE setting to be optimised), but does not provided information on how the unallocated memory is fragmented into smaller blocks.

This implementation:

  • Can be used even when the application repeatedly deletes tasks, queues, semaphores, mutexes, etc..
  • Is much less likely than the heap_2 implementation to result in a heap space that is badly fragmented into multiple small blocks
    - even when the memory being allocated and freed is of random size.
  • Is not deterministic - but is much more efficient that most standard C library malloc implementations.

heap_4.c is particularly useful for applications that want to use the portable layer memory allocation schemes directly in the application code
(rather than just indirectly by calling API functions that themselves call pvPortMalloc() and vPortFree()).

/*
* A sample implementation of pvPortMalloc() and vPortFree() that combines
* (coalescences) adjacent memory blocks as they are freed, and in so doing
* limits memory fragmentation.
*
* See heap_1.c, heap_2.c and heap_3.c for alternative implementations, and the
* memory management pages of http://www.FreeRTOS.org for more information.
*/
#include <stdlib.h> /* Defining MPU_WRAPPERS_INCLUDED_FROM_API_FILE prevents task.h from redefining
all the API functions to use the MPU wrappers. That should only be done when
task.h is included from an application file. */
#define MPU_WRAPPERS_INCLUDED_FROM_API_FILE #include "FreeRTOS.h"
#include "task.h" #undef MPU_WRAPPERS_INCLUDED_FROM_API_FILE /* Block sizes must not get too small. */
#define heapMINIMUM_BLOCK_SIZE ( ( size_t ) ( heapSTRUCT_SIZE * 2 ) ) /* Assumes 8bit bytes! */
#define heapBITS_PER_BYTE ( ( size_t ) 8 ) /* A few bytes might be lost to byte aligning the heap start address. */
#define heapADJUSTED_HEAP_SIZE ( configTOTAL_HEAP_SIZE - portBYTE_ALIGNMENT )

/* Allocate the memory for the heap. */
static unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];

FreeRTOS Memory Management ( IAR )的更多相关文章

  1. Memory Management in Open Cascade

    Open Cascade中的内存管理 Memory Management in Open Cascade eryar@163.com 一.C++中的内存管理 Memory Management in ...

  2. Java (JVM) Memory Model – Memory Management in Java

    原文地址:http://www.journaldev.com/2856/java-jvm-memory-model-memory-management-in-java Understanding JV ...

  3. Objective-C Memory Management

    Objective-C Memory Management Using Reference Counting 每一个从NSObject派生的对象都继承了对应的内存管理的行为.这些类的内部存在一个称为r ...

  4. Operating System Memory Management、Page Fault Exception、Cache Replacement Strategy Learning、LRU Algorithm

    目录 . 引言 . 页表 . 结构化内存管理 . 物理内存的管理 . SLAB分配器 . 处理器高速缓存和TLB控制 . 内存管理的概念 . 内存覆盖与内存交换 . 内存连续分配管理方式 . 内存非连 ...

  5. Android内存管理(2)HUNTING YOUR LEAKS: MEMORY MANAGEMENT IN ANDROID PART 2

    from: http://www.raizlabs.com/dev/2014/04/hunting-your-leaks-memory-management-in-android-part-2-of- ...

  6. Android内存管理(1)WRANGLING DALVIK: MEMORY MANAGEMENT IN ANDROID PART 1

    from : http://www.raizlabs.com/dev/2014/03/wrangling-dalvik-memory-management-in-android-part-1-of-2 ...

  7. Understanding Memory Management(2)

    Understanding Memory Management Memory management is the process of allocating new objects and remov ...

  8. Java Memory Management(1)

    Java Memory Management, with its built-in garbage collection, is one of the language’s finest achiev ...

  9. ural1037 Memory Management

    Memory Management Time limit: 2.0 secondMemory limit: 64 MB Background Don't you know that at school ...

随机推荐

  1. 登陆记录utmp wtmp

    /var/log/wtmp文件的作用     /var/log/wtmp也是一个二进制文件,记录每个用户的登录次数和持续时间等信息.   查看方法:   可以用last命令输出当中内容: debian ...

  2. chkconfig命令主要用来更新(启动或停止)和查询系统服务的运行级信息

    chkconfig命令主要用来更新(启动或停止)和查询系统服务的运行级信息.谨记chkconfig不是立即自动禁止或激活一个服务,它只是简单的改变了符号连接. 使用语法:chkconfig [--ad ...

  3. Otto:EventBus

    Otto:EventBus 2014年6月20日 星期五 15:14 参考: http://www.mythroad.net/?p=4151 Otto 是Android系统的一个Event Bus模式 ...

  4. Percona XtraDB Cluster(PXC)-高可用架构设计说明

    Mycat+PXC高可用集群 一.架构图 架构说明: 1.mysql 集群高可用部分: l 针对业务场景选用Percona XtraDB Cluter(PXC)复制集群.两个片集群 PXC-dataN ...

  5. POJ 1386 Play on Words(单词建图+欧拉通(回)路路判断)

    题目链接:http://poj.org/problem?id=1386 题目大意:给你若干个字符串,一个单词的尾部和一个单词的头部相同那么这两个单词就可以相连,判断给出的n个单词是否能够一个接着一个全 ...

  6. spring源码解析--事务篇(前篇)

    对于每一个JAVA程序员,spring应该是再熟悉不过的框架了,它的功能有多强大我就不多说了,既然他有这么强大的功能,是如何实现的呢?这个就需要从他的原理去了解,而最直接了解原理的方式莫过于源码.当然 ...

  7. JavaWeb知识回顾-servlet简介。

    现在公司主要用jsp+servlet这种原生的开发方式,用的是uap的开发平台,所以趁着这个时候把有关javaweb的知识回顾一下. 首先是从servlet开始. 一.什么是Servlet?(是一些理 ...

  8. 洛谷P1720 月落乌啼算钱 题解

    题目传送门 初看题目,好难.再看一次,探索规律,发现这就是有名的斐波那契数列. F[i]=f[i-1]+f[i-2] SO 代码很简单,貌似要开long long,又貌似不用开. #include&l ...

  9. 几个python one-liner

    生成斐波那契数列的前10个数,从1开始.若生成前n个,改为range(n-2).代码很简单: List = reduce(lambda x, y: x + [x[-1] + x[-2]], range ...

  10. CentOS下Redis安装与配置

    本文详细介绍redis单机单实例安装与配置,服务及开机自启动.如有不对的地方,欢迎大家拍砖o(∩_∩)o (以下配置基于CentOS release 6.5 Final, redis版本3.0.2 [ ...