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.

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.

谢谢，
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;

/// Saved LLS alert level to set in ATT DB
uint8_t lls_alert_lvl;
/// TX Power level
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.

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).

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 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 data3;/* 4 bytes - largest structure member */
char Data4;/* 1 byte */
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））。

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.

- 是否假设结构未打包（编译器添加的隐式填充）是正确的？
- 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)

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).

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 :-).

Looking forward to your response Dialog.
Kind regards,
arjan.

Hi MT_dialog,

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

Kind regards,
arjan.