c - LPC1788 微 Controller 的内存分配问题

Question

我对微 Controller 编程相当陌生；我已经使用 LPC1788 几个星期了。

我最近遇到的一个问题是我的内存耗尽的速度比我预期的要快得多。我通过测试可以 malloc 有多大的连续内存块来测试似乎有多少内存可用，结果是 972 字节。分配从地址 0x10000000 开始(该板上片上 SRAM 的起始位置应约为 64kB)。

我目前正在开发的程序旨在充当一个简单的调试器，它利用 LCD 并允许将消息打印到上面。我有一个字符串，它会不断地“添加”新消息，然后整个消息将打印在液晶显示屏上。当屏幕上消息的长度超过垂直边界时，它将删除最旧的消息(靠近顶部的消息)，直到适合为止。但是，在它拒绝分配更多内存之前，我只能添加大约 7 条附加消息。如果需要，该项目的 main.c 托管在 http://pastebin.com/bwUdpnD3

早些时候，我还开始了一个使用 threadX RTOS 创建和执行多个线程的项目。当我尝试在该程序中使用 LCD 时，我发现那里的内存也非常有限。 LCD 似乎存储从 SDRAM 基地址开始的所有像素数据，但我不确定这是否与我使用的 SRAM 相同。

我需要的是一种分配足够内存的方法，以允许多个线程运行或存储大字符串，同时能够利用 LCD。一种可能性可能是使用缓冲区或其他内存区域，但我不太确定如何做到这一点。任何帮助将不胜感激。

tl;dr:尝试在 LCD 上打印大字符串时，SRAM 上的可分配内存很快就会耗尽。

编辑 1:发现变量 currMessage 存在内存泄漏。我认为现在已经解决了:

strcpy(&trimMessage[1], &currMessage[trimIndex+1]);

// Frees up the memory allocated to currMessage from last iteration
// before assigning new memory.
free(currMessage);
currMessage = malloc((msgSize - trimIndex) * sizeof(char));
for(int i=0; i < msgSize - trimIndex; i++)
{
  currMessage[i] = trimMessage[i];
}

编辑2:实现了内存泄漏修复。程序现在运行得好多了，但我觉得很愚蠢。

Answer 1

在嵌入式环境中选择使用动态内存分配时需要小心，尤其是在内存受限的情况下。您很容易最终将内存空间碎片化，留下的最大空洞是 972 字节。

如果必须从堆中分配，请执行一次，然后卡在内存上 - 几乎就像静态缓冲区一样。如果可能，请使用静态缓冲区并避免一起分配。如果您必须进行动态分配，则将其保留为固定大小的 block 将有助于减少碎片。

不幸的是，确实需要一些工程努力来克服碎片问题。这是值得的，而且它确实使系统更加健壮。

至于SRAM 与SDRAM，它们并不相同。我不熟悉 threadX，也不熟悉他们是否有适合您的主板的主板支持包 (BSP)，但一般来说，必须设置 SDRAM。这意味着引导代码必须初始化内存 Controller 、设置时序，然后启用该空间。根据您的堆实现，您需要动态添加它，或者更可能的是，您需要使用指向它最终所在位置(在 SDRAM 空间中)的堆空间进行编译。然后，您必须确保在实际使用堆之前配置并激活内存控制。

另一件事需要注意，您实际上可能正在从 SRAM 空间运行代码，并且其中一些空间也为处理器异常表保留。整个空间可能不可用，并且可能存在于两个不同的地址(例如 0x00000000 和 0x10000000)。我知道在其他一些 ARM9 处理器中，这种情况很常见。您可以从闪存启动，该闪存最初被映射到 0x00000000 空间，然后您可以一边跳舞一边将启动程序复制到 SRAM 中，并将 SRAM 映射到该空间中。此时，您可以启动到类似 Linux 的系统，它希望能够更新位于 0 的表。

顺便说一句，您发布的代码中确实存在一些内存泄漏。也就是说，currentMessage 永远不会被释放……只是被新指针覆盖。这些 block 随后将永远丢失。