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.

@mt_dialog感谢您的回复，我最终使用动态内存分配以获得明显的原因。然而，它具有静态内存分配的有意义的实验。

@ Summer20100514谢谢您的回复。请注意，我提到的32KB的RAM是整个系统，而不仅仅是它的BLE相关部分。所以5KB仍然是一个相当大的块;-)。

也许你可以帮助我解决一个新问题;SDK中的所有数据结构都在正确的边界上明确对齐吗？或者它假设数据结构将包装在DA14580中以及主机代码（为了使用SDK）？我注意到尺寸频繁地用于确定不同消息参数的大小，我只是想知道是否考虑了潜在的隐式填充。

谢谢，
arjan.

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

让我们拍摄struct proxr_enable_req：


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

/// Parameters of the @ref PROXR_ENABLE_REQ message
struct proxr_enable_req.
{
/// 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.

当将传入的字节数组施放到消息的相应参数的相应参数时，我们需要确保发件人和接收器不考虑这种隐式填充。在Proxr_Enable_Req的情况下，我们不会有一个真正的问题解除了个别成员，因为填充仅在最后一个成员之后添加。但是，如果您采取以下示例，则各个成员可能不是您希望它们的位置（取决于发送方和接收方是否假设有关包装结构的不同规则）。

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


struct MixedData
{
char data1;
短数据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机器* /
{
char data1;/ * 1字节* /
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 data3;/ * 4字节 - 最大的结构成员* /
char Data4;/ * 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_dialog，

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

亲切的问候，
arjan.