GTL消息和（动态）内存分配

很乐意听到别人在嵌入式系统中如何在具有有限的嵌入式系统中实现这一点和/或Malloc /免费被认为是不良的做法。

Kind regards,
Arjan

@MT_dialog thank you for your response, I ended up using dynamic memory allocation for obvious reasons. However it was meaningful experimenting with static memory allocation.

@summer20100514 thank you for your response. Note that the 32kB of RAM I mentioned is for the entire system, not just the BLE related portion of it. So 5kB would still be a rather big chunk ;-).

Perhaps you can help me out with a new question; Are all data structures in the SDK explicitly aligned on the right boundaries? Or is it assumed that data structures will be packed in both DA14580 as well as host code (in order to use the SDK)? I notice sizeof is used quite often to determine the size of the different message parameters, I was just wondering whether or not potential implicit padding was taken into account.

Thanks,
Arjan

@ summer20100514也许我should clarify my question.

Let's take struct proxr_enable_req for example:


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

/// @ref proxr_enable_req消息的参数
struct proxr_enable_req
{
///连接句柄
uint16_t conhdl;
/// Security level
uint8_t sec_l​​vl;

/// Saved LLS alert level to set in ATT DB
uint8_t lls_alert_lvl;
/// TX Power level
int8_t txp_lvl;
};

在创建Proxr_Enable_Req GTL数据包时，SizeOf（struct proxr_enable_req）用于确定参数长度。在这种情况下，结构的编译值，因此是分组参数长度的值为6;在成员TXP_LVL之后，添加了另外的填充字节。换句话说;最后一个成员用所需的字节数填充，使得结构的总大小是任何结构成员的最大对准的倍数。

When casting the incoming byte array to the message's corresponding parameters struct type we need to be sure that this implicit padding is, or is not taken into account by both sender and receiver. In case of proxr_enable_req we wouldn't have a real issue dereferencing the individual members, as padding is merely added after the last member. However if you take the example below, individual members might not be where you'd expect them to be (depending on whether or not sender and receiver assume different rules regarding packing structures).

以下是具有各种类型的成员的结构，在编译之前总计8个字节：


结构混合数据
{
char data1;
short Data2;
int Data3;
char data4;
};

编译后，数据结构将补充填充字节，以确保每个成员的适当对齐：


结构混合数据/* After compilation in 32-bit x86 machine */
{
char data1;/ * 1字节* /
char padding1 [1];/ * 1字节用于以下“短”以在2字节边界上对齐
假设结构开始的地址是偶数* /
short Data2; /* 2 bytes */
int Data3; /* 4 bytes - largest structure member */
char data4;/ * 1字节* /
char padding2 [3];/ * 3个字节，使结构的总大小为12字节* /
};

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

长话短说，我很想从对话本身学习哪些设计选择是用达SDK制作的。是否在字段之间发送或没有填充字节的数据包参数？

因为我还没有来across any document that explicitly specifies the data endianness and whether or not data structures are packed or that pad bytes exist in between struct members, my guess is that up until now the SDK has only been used in / intended for (32 bit) platforms with a little endian memory architecture without structs being packed (for example I did find any __attribute__(packed) in the SDK code).

As long as both systems use sizeof(struct ) for setting the GTL packet parameter length and cast the incoming and outgoing parameter byte array to these struct types, everything will work just fine (as both platforms expect the same struct member padding / member alignment).

Even tough I believe this is the case with how the SDK has been used so far, I would really appreciate a response from Dialog itself regarding this matter.

- Is it correct to assume that structs are not packed (implicit padding added by the compiler)?
- 没有添加显式填充，以确保成员正确对齐，结构大小是其最大成员大小的倍数？（即，这是留给编译器）

Please note that I am absolutely fine with this approach (with our current host platform), as our host uses the 32-bit ARM Cortex-M0+ processor as well. Both DA14580 and host processor are configured with little-endian byte order. In other words, sizeof() will return the same result on both platforms and struct members will be aligned exactly the same on both platforms (with the same implicit padding added by the compiler).

我在跨平台解决方案中使用了这些类型的面向字节的面向的基于包装的协议（具有不同的内存架构）。也许对于SDK的未来未来添加可以是添加额外的抽象级别，通过指定字段之间存在没有填充字节，并使用写/读取模块以以endianness独立方式写入/读取多字节数据类型。这样你就可以删除它的平台依赖性方面。

我是SDK的忠实粉丝（特别是5.0.3，爱它！），我只是喜欢尽可能地清理的东西:-)。

Looking forward to your response Dialog.
Kind regards,
Arjan

Hi MT_dialog,

谢谢你的确认。现在可以关闭此主题。

Kind regards,
Arjan