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.

Thanks,
Arjan

@summer20100514 perhaps I should clarify my question.

Let's take struct proxr_enable_req for example:


// 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;
/// Security level
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;
short Data2;
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 /* After compilation in 32-bit x86 machine */
{
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 */
short Data2; /* 2 bytes */
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?

Since I did not yet come 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)?
- 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