[参考译文] CC2642R：具有 OSAL 堆类型的 iCall_malloc()在一段时间内是否会出现堆内存碎片问题？

克莱门特，您好！

感谢您的回复。 那么，我们是否会遇到碎片问题，即使认为有可用字节，堆也不可用？

我们正在使用 rtos_heaposal.h 上的“HEAPMGR_MEMALO”来分配当前内存。 它是提供非碎片连续内存还是仅提供总分配字节？ 如果“HEAPMGR_MEMALO”不提供该信息，我们如何获得非碎片连续可用内存？

我可以获得任何文档来了解 OSAL 内存管理的工作原理？ 以下链接以外的任何文档？

software-dl.ti.com/.../memory_management.html

克莱门特，您好！

是的，在应用程序中，我们正在进行合理的内存分配。 但 BLE 堆栈也是如此。 BLE 堆栈是否使用 iCall_malloc()分配内存的任何特定方式来避免碎片化？

您好，

堆栈的开发考虑到了这些因素。 此外，我们还会进行几天的耐力测试。

此致，

克莱门特，您好！

抱歉，您能否详细阐述您的声明：“堆栈的开发考虑到了这些因素。  ”。 您的意思是>长期使用堆碎片整理？

您好，

我们的开发人员了解碎片问题，并尝试在编码中将这些问题最小化。

此致，

谢谢克莱门特。 TI 开发人员提出的任何关于应用开发商如何也能最大程度地减少碎片问题的具体清单？

克莱门特，您是否可以向我们提供有关将如何最小化堆中的碎片的参考？

您好，

与所有嵌入式系统一样，动态分配会增加碎片风险。 我建议尽可能使用静态分配。

我希望这将有所帮助，

此致，

克莱门特，您好！

在与 Mehul 直接交谈时，我们希望您尽可能提供帮助，帮助您更清楚地了解 TI 的耐久性测试。

首先，下面是 TI 和 Mehul/客户之间的最新问答：

1. TI 开发商采取了哪些措施来最大限度地减少碎片问题？ 分配恒定大小的内存是否始终能最大程度地减少碎片问题，以及 TI 开发商在 BLE 堆栈和 TI RTOS 中所做的工作？

(a)堆栈的开发考虑到了合理的内存分配。  当然，根据客户具体实施应用程序的方式，如果所说的应用程序分配了大量内存(特别是不同大小的大内存分配)，我们建议用户充分利用至少一些静态内存分配。  请记住，这不是一个全面修复，因为 BLE 堆栈的某些区域可能会继续使用动态分配。

1. 运行耐力测试意味着什么？ 应用固件的标准是什么？

(A)根据客户通过 TI-RTOS 或 OSAL 堆管理器专门实施堆的方式，两者都有一些可以提取的诊断信息级别。  这些诊断程序[如 《BLE-5堆栈用户指南》的调试内存问题[software-dl.ti.com 中所述]非常有用，在测试不同的内存分配缓冲区大小和内存测试条件时，TI 开发人员也使用这些诊断程序。  然后，这些‘耐用性’或重复性测试将用于在这些内存分配的上下文中验证 BLE 堆栈本身的整体可靠性和运行情况。

1. 即使建议应用程序开发人员不要使用堆内存来最小化堆碎片，TI RTOS 和 BLE 堆栈仍然使用堆内存，堆碎片问题也不会完全消除。 因此，无论应用程序是否使用堆，堆碎片的风险都将存在。 那么，为什么应用程序不能继续使用堆内存以及 TI 对 TI RTOS 和 BLE 堆栈遵循的相同标准？ 或者，TI 对应用开发商的建议是完全不在应用中使用堆内存？

(a)这可能更像是一个建筑问题。  如果用户知道需要大量内存分配，则可以根据需要分配内存，然后在应用程序中手动管理内存分配，或者只是静态分配。  老实说，由于 CC2642R 设备本身拥有相对较大的80KB RAM 占用空间，因此这可能不是一个整体问题。  此外，还应查看上述《BLE-5堆栈用户指南》中的“动态内存分配和堆配置”部分，以获得更多建议。  

 未决问题与以下内容相关： Mehul/客户将对应用程序中的堆内存的使用情况执行所需的分析。 [他们已经在使用“heapmgMemAlo”来跟踪堆的使用情况。]

 但请您详细说明上述耐力测试吗？ TI 运行此测试的持续时间是多少，对于频繁执行使用堆的模块，建议使用其他特定方案或建议吗？

谢谢你，
克里斯

克莱门特，您好！

我知道您之前曾分享过："耐久性测试是我们测试设备是否长期保持稳定的测试(小时或天，具体取决于用例)。 根据客户所针对的用例，客户可能会运行类似的测试，这可能是有意义的。”

我们非常感谢并欢迎根据最新线索提供的更多详细信息。

谢谢你，
克里斯