1246_FreeRTOS的存储管理方案

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.

从描述看，FreeRTOS也可以不使用heap。关于这部分应该仔细研究下，按照之前我看过实践过的部分内容以及信息，我觉得FreeRTOS给我的一个很大的困惑点在于heap占用了太多的RAM。看起来，这方面还是有改进空间的。

OS中的很多对象，例如task、队列等都需要用到RAM，可以直接从heap分配也可以由应用软件开发人员分配。关于后面的说法，之前我似乎就看到过，但是一直没有弄清楚应该如何来实现。

如果创建的RTOS的对象是动态的，那么就会用到malloc和free这样的功能。但是，相应的功能在嵌入式系统中并不是很方便也不是很搞笑。FreeRTOS针对这部分内容进行了重新设计，并且把这部分功能放到了可移植层中。相应的接口名称也有了新的变化。

FreeRTOS提供了多种heap的功能实现方案，并且允许用户自己来设计自己的heap实现方案。甚至允许使用混合的方案，提供了很高的灵活度。

这是对FreeRTOS打包提供的几种heap方案的简单介绍。

1. heap_1，简单，不支持free。

2. heap_2，功能全，但是不支持内存碎片的处理。

3. heap_3，标准的malloc和free的封装，增强了线程安全。

4. heap_4，可以进行内存碎片的处理，也支持绝对地址功能。

5. heap_5，功能跟heap_4差不多，但是支持使用不连续的存储。

heap_1以及heap_2都是历史的包袱了，原本heap_1可以支持部分没有动态RTOS对象的应用，但是随着FreeRTOS支持了静态的分配机制之后这个也应该丢弃了。

从某种角度讲，感觉heap_1这种机制其实是很安全的。但是，这种heap管理机制之下，队列等功能都是不支持的。

这是heap_4的老版本，基本上支持了FreeRTOS的全部功能运行。但是，不支持内存碎片的整理算是很大的一个痛点。

这个基本是标准的malloc和free的改进版本，这样，使用的其实就是系统的heap。而这部分的heap的分配在嵌入式的开发中其实是由链接器来分配的。如果使用这种模式，FreeRTOS配置中heap大小的配置参数就无效了。这个模式可能会让FreeRTOS的内核代码大小显著增大。至于为什么会有这样的存在，我觉得从软件移植以及兼容性的角度考虑应该算是一个很重要的理由。

heap_4继承了heap_2的功能，并且解决了heap_2不支持内存碎片处理的痛点。相比标准的malloc以及free来说，更加高效。从上面的介绍内容看，应该有一部分专用的数据结构，这可能会导致一些已经存在的代码的重用得进行二次修改。

我觉得heap_5应该算是heap_4的改进版，增加了离散内存的支持，可以试用不连续的内存区。但是，在使用heap_5的时候，动态的存储管理可能会多几个接口调用。如果采用的存储本身是连续的，或许没有不使用heap_4的理由。我看过的很多demo其实硬件的设计本身就是简单的，不存在这样的不连续的存储区。或许，正是因为这个原因，我看到的很多Demo工程其实都是使用了heap_4的存储管理模式。