嵌入式应用程序中的内存管理资源

Ela*_*ich 7 c embedded malloc memory-management do178-b

我应该如何管理关键任务嵌入式应用程序中的内存?

我发现了谷歌的一些文章,但无法确定一个非常有用的实用指南.

DO-178b者禁用动态内存分配,但你将如何管理内存呢?提前预先分配所有内容并发送指向需要分配的每个函数的指针?在堆栈上分配它?使用全局静态分配器(但它与动态分配非常相似)?

例如,答案可以是常规答案,对资源的引用或对良好的开源嵌入式系统的引用.

澄清:这里的问题不在于内存管理是否适用于嵌入式系统.但是什么是嵌入式系统的优秀设计,以最大限度地提高可靠性.

我不明白为什么静态预分配缓冲池,并动态地获取和删除它,与动态分配内存不同.

neu*_*uro 5

我曾在 DO-178B 环境(飞机系统)中工作。据我了解,不允许动态分配的主要原因主要是认证。认证是通过测试(单一、覆盖、集成……)完成的。通过这些测试,您必须证明程序的行为是 100% 可预测的,几乎可以达到进程的内存占用量从一次执行到下一次执行都是相同的程度。由于动态分配是在堆上完成的(并且可能会失败),因此您无法轻易证明这一点(我想如果您掌握从硬件到编写的任何代码段的所有工具,这应该是可能的,但是......)。静态分配不会有这个问题。这也是当时在这样的环境中不使用 C++ 的原因。(大约15年前,可能已经改变了......)

实际上,您必须编写大量结构池和分配函数来保证您具有确定性。你可以想象很多解决方案。关键是您必须(通过大量测试)证明高水平的确定性行为。证明您手工开发的确定性工作比证明 linux + gcc 在分配内存方面具有确定性更容易。

只是我的2分钱。这是很久以前的事了,事情可能已经发生了变化,但对于像 DO-178B 这样的认证,关键是要证明您的应用程序在任何情况下都可以在任何时候正常工作。


Art*_*ski 4

作为一个处理过嵌入式系统的人,尽管到目前为止还没有那么严格(不过我已经阅读了 DO-178B):

  • 如果你看一下 u-boot 引导加载程序,就会发现很多工作都是通过全局放置的结构完成的。根据您的具体应用程序,您也许能够摆脱全局结构和堆栈。当然,其中存在重入和相关问题,这些问题并不真正适用于引导加载程序,但可能适合您。
  • 预分配,预分配,预分配。如果您可以在设计时绑定数组/列表结构/等的大小,请将其声明为全局(或静态全局 - 看 Ma,封装)。
  • 堆栈非常有用,在需要的地方使用它——但是要小心,因为很容易不断地分配它,直到没有剩余的堆栈空间为止。我曾经发现自己调试的一些代码会分配 1k 缓冲区用于多个函数中的字符串管理...有时,缓冲区的使用会占用另一个程序的堆栈空间,因为默认堆栈大小为 4k。
  • 缓冲池的情况可能完全取决于它的实现方式。如果您知道需要传递编译时已知大小的固定大小缓冲区,则处理缓冲池可能比完整的动态分配器更容易证明正确性。您只需要验证缓冲区不会丢失,并验证您的处理不会失败。这里似乎有一些很好的提示:http://www.cotsjournalonline.com/articles/view/101217

但实际上,我认为您可以在加入http://www.do178site.com/中找到答案