UART流打包；流还是向量？答案

【问题标题】：UART stream packetisation; stream or vector?UART流打包；流还是向量？
【发布时间】：2019-08-12 17:23:23
【问题描述】：

我正在编写一些代码以通过 UART 将 STM32H7 与 BM64 蓝牙模块 连接起来。

BM64 需要以字节为单位的二进制数据；一般来说：

1. Start word (0xAA)    
2-3. Payload length    
4. Message ID    
5-n. Payload    
n+1. Checksum

我的问题是关于消息队列的最佳实践，即：自定义iostream，接口类内的消息向量还是其他？

目前的理解，如有错误请指正，如有遗漏请补充：

自定义iostream 具有与cout 等一致的简洁用法的巨大优势。非常有用和干净，并且很可能至少在原则上可移植到此项目中在其他UART 端口上运行的其他设备。缺点是创建自定义streambuf 的工作量相对较大，并且不确定“endl”使用什么（不能使用 null 或 '\n'，因为它们可能存在于消息中，与它一起是二进制的。）
向量对我来说似乎有点脏，尤其是对于嵌入式的东西，动态分配可能会窃取大量内存，除非我无情地将周期花在 resize() 和 reserve() 上。但是，消息向量（定义为 class 或 struct）将非常快速且容易完成。
还有其他解决方案吗？请注意，我不想使用数组，即传递缓冲区指针和缓冲区长度。

你会在这个应用程序中提出什么建议？

【问题讨论】：

标签： c++ c++11 iostream streambuf

【解决方案1】：

在裸机系统上，我更喜欢具有最大可能有效负载大小的固定大小的缓冲区。其中两个，固定分配，一个填充，一个并行发送，完成后切换。所有类型的动态内存分配都以内存碎片告终，尤其是在此类缓冲区大小抖动的情况下。

即使你的系统有一个 MMU，最好不要做太多的动态堆分配。我经常使用自己编写的块池内存管理来摆脱长时间的碎片和延迟分配失败。

如果您害怕使用超过当前需要的 ram，请再想一想：如果您的 ram 太少以至于您不能花费超过当前所需的内存，那么如果您确实需要最大缓冲区大小，您的系统有时可能会失败。这根本不是嵌入式的选择。最后一个是一个很好的论点，只要在实际运行时条件下，这可能可能发生在“未来的某个时间点”，所有分配的内存或多或少都是固定的:-)

【讨论】：