GTL.messages and (dynamic) memory allocation

Would love to hear how others implemented this in embedded systems with limited memory and/or where malloc/free was considered bad practice.

谨致问候，
arjan.

@谢谢你的回复，我最后使用了动态内存分配，原因很明显。不过，尝试静态内存分配是有意义的。

@summer20100514感谢您的回复。请注意，我提到的32kB的RAM是针对整个系统的，而不仅仅是与BLE相关的部分。所以5kB仍然是相当大的一块；-）。

也许你能帮我解决一个新问题；SDK中的所有数据结构是否在正确的边界上显式对齐？或者假设数据结构将打包在DA14580和主机代码中（以便使用SDK）？我注意到sizeof经常用于确定不同消息参数的大小，我只是想知道是否考虑了潜在的隐式填充。

谢谢，
arjan.

@ Summer20100514也许我应该澄清我的问题。

让我们拍摄struct proxr_enable_req：


// sdk\ble_stack\profiles\prox\proxr\proxr_task.h

/// Parameters of the @ref PROXR_ENABLE_REQ message
结构程序启用请求
{
/// Connection Handle
uint16_t conhdl;
/// 安全级别
uint8_t sec_lvl;

///已保存LLS警报级别以在ATT DB中设置
uint8_t lls_alert_lvl;
///TX功率电平
INT8_T TXP_LVL;
};

When creating a PROXR_ENABLE_REQ GTL packet, sizeof(struct proxr_enable_req) is used to determine the parameter length. In this case the compiled value of the struct, and thus the value for the packet parameter length, is 6; An additional byte of padding is added just after member txp_lvl. In other words; The last member is padded with the number of bytes required so that the total size of the structure is a multiple of the largest alignment of any structure member.

当将传入字节数组强制转换为消息的相应参数struct type时，我们需要确保发送方和接收方都考虑或不考虑这种隐式填充。在proxr\u enable\u req的情况下，取消对单个成员的引用不会有真正的问题，因为填充仅添加在最后一个成员之后。但是，如果您以下面的示例为例，单个成员可能不是您期望的位置（取决于发送方和接收方是否对打包结构采用不同的规则）。

Here is a structure with members of various types, totaling 8 bytes before compilation:


struct MixedData
{
字符数据1；
短数据2;
int data3;
char Data4;
};

After compilation the data structure will be supplemented with padding bytes to ensure a proper alignment for each of its members:


struct mixeddata / *编译32位x86机器* /
{
字符数据1；/* 1 byte */
char Padding1[1]; /* 1 byte for the following 'short' to be aligned on a 2 byte boundary
assuming that the address where structure begins is an even number */
短数据2;/ * 2字节* /
int数据3；/*4字节-最大结构成员*/
字符数据4；/*1字节*/
char Padding2 [3];/ * 3字节to make total size of the structure 12 bytes */
};

https://en.wikipedia.org/wiki/Data_structure_alignment

Long story short, I'm curious to learn from Dialog itself which design choice was made with the DA SDK. Are packet parameters sent with or without pad bytes in between fields?

由于我尚未遇到任何明确地指定数据的文档，因为在结构成员之间包含数据结构以及数据结构是否存在，我的猜测是直到现在，SDK仅用于/打算（32位）平台，带有少量内存架构的没有结构（例如，我在SDK代码中找到了任何__Attribute __（packed））。

只要两个系统都使用sizeof（struct）来设置GTL包参数长度，并将传入和传出参数字节数组强制转换为这些结构类型，一切都会正常工作（因为两个平台都期望相同的结构成员填充/成员对齐）。

即使是艰难的，我相信这是如何使用SDK到目前为止的情况下，我真的很感谢对话框本身就此事作出回应。

- 是否假设结构未打包（编译器添加的隐式填充）是正确的？
- There is no explicit padding added to make sure that members align properly and struct sizes are a multiple of the size of its largest member? (i.e. this is left to the compiler)

请注意，我完全同意这种方法（使用我们当前的主机平台），因为我们的主机也使用32位ARM Cortex-M0+处理器。DA14580和主机处理器都配置了小端字节顺序。换句话说，sizeof（）将在两个平台上返回相同的结果，并且结构成员在两个平台上的对齐方式将完全相同（编译器添加了相同的隐式填充）。

I have worked quite a lot with these type of byte-oriented, packed based protocols in cross-platform solutions (with different memory architectures). Perhaps a good future addition for the SDK could be to add an extra level of abstraction, by specifying that no pad bytes exist in between fields and using a write/read module for writing/reading multi-byte data types in an endianness independent manner. This way you remove the platform-dependent aspect of it all.

I'm a big fan of the SDK (especially 5.0.3, love it!), I just like to get things cleared up as much as possible :-).

期待您的回应对话。
谨致问候，
arjan.

嗨，MT\u dialog，

Thanks for the confirmation. This topic may now be closed.

谨致问候，
arjan.