stm32网联丢包跟内存分配有关吗

Posted 2023-05-15

有关。在函数中使用malloc，如果是大的内存分配，
而且malloc与free的次数也不是特别频繁，使用malloc与free是比较合适的，

但是如果内存分配比较小，而且次数特别频繁，那么使用malloc与free就有些不太合适了。
因为过多的malloc与free容易造成内存碎片，致使可使用的堆内存变小。

尤其是在对单片机等没有MMU的芯片编程时，慎用malloc与free。
如果需要对内存的频繁操作，可以自己实现一个内存管理。

使用动态内存分配，应分不同的应用场合。
对于在操作系统上运行的程序，实际的物理内存分配与释放使用操作系统来实现的，即使程序调用了 malloc和free物理内存并不会马上变化。物理内存的变化，直到系统的内存管理操作时才发生。
对于裸机跑在MCU上的程序，分配与释放内存都会造成实际物理内存的变化。因为此时物理内存的分配是由自己实现的，而内存管理我们自己并没有去做。这样，盲目的使用malloc与free恰恰并不好，反而会造成内存的不恰当使用。甚至于内存溢出。
所以，动态内存的使用前提是有一套好的内存管理方法，这样动态内存的使用才会合理使用内存。如果没有合适的内存管理代码，还是用静态内存好一些。 参考技术A 没有，
该系统丢包跟内存分配无关。主要与网络配置有关。当然，如果不清楚的话，可以查看一下网络信息。

STM32 Cortex M0 上的 ThreadX 内存分配

【中文标题】STM32 Cortex M0 上的 ThreadX 内存分配

【英文标题】：ThreadX Memory Allocation on STM32 Cortex M0

【发布时间】：2021-10-08 03:30:16

【问题描述】：

我正在尝试在 STM32L0 Cortex M0+ 控制器上测试 ThreadX 的示例/演示代码。特别是在 GitHub 上找到的 sample_thread.c 代码。我使用了皮质 M0 端口的示例代码并编译了代码。在这一点上，一切都很好，或者我认为，端口看起来已经正确映射到我的控制器；即内存起始地址和RAM是正确的。

我遇到的问题是，在为线程分配空间时，我在某些动态内存分配函数中遇到了硬故障。我发现硬故障是在函数 _tx_byte_pool_search() 中触发的，它发生在检查块指针时，在一个实例中：

*next_block_link_ptr =  *this_block_link_ptr;

执行此行时，其中一个块指针以内存区域外的无效地址结束，通常为 0xAAAAAAAA。我试图了解 ThreadX 究竟是如何构建这些内存块的，但我不应该这样做。此功能应该按预期工作，但事实并非如此。所以我在想我做错了什么，但是已经没有想法可以检查了。如果有更多经验的人可以提供一些有用的方向或想法。

我在 _tx_initialize_low_level.S 中设置了启动代码，以提供 first_unused_memory 的地址，用于 tx_application_define()。我认为这个地址基本上是内存分配工作所需要的。也许我错过了什么。

感谢大家的帮助。

【参考方案1】：

您描述的问题暗示了内存分配给程序不同部分的不匹配。正如您所做的那样，我首先要检查的两点是链接描述文件，以及分配的 RAM 末端的位置是否已正确定义。问题也可能出在其他地方，但这些可能是原因。

首先确保链接器文件与您的系统匹配。请查阅处理器参考手册和数据表。您没有提到您使用的是哪个工具链，链接器命令文件（或链接器脚本文件）格式会因工具链而异。

其次，已用内存的结束位置和空闲内存的开始位置应该与您的系统相匹配。您可以查看通常存储在映射文件中的链接器输出，以了解应用程序正在使用多少内存。确保这是传递给 tx_application_define 的内容。

处理第二点的更好方法是根本不使用此参数，而是为每个元素（线程控制块、其他控制块、线程堆栈等）静态分配内存（作为全局变量）。基本示例使用这种复杂的内存分配方式有两个原因：足够灵活，无需修改即可在许多不同的架构中运行，以及在少量代码中显示尽可能多的 API；作为演示很有趣，但不是使用系统的首选方式。