Dear support,

Currently I am implementing the GTL interface (over UART) in a custom embedded project. My first goal is to get the prox_reporter_ext project working in combination with our external processor (DA1458x_SDK\5.0.2.1\projects\target_apps\ble_examples folder). I have used the host_proxr_sdk project as a reference (DA1458x_SDK\5.0.2.1\projects\host_apps\windows\proximity\reporter\ folder).

The challenge I'm facing is with memory allocation. Up until now we have avoided using malloc/free in our embedded code, simply to prevent introducing disastrous side effects such as memory leaks (also it might introduce new challenges in combination with our RTOS). In ble_msg of the aforementioned project I see that malloc and free are used via for example BleMsgAlloc and BleFreeMsg, the same goes for SendToMain in uart.c. Furthermore the receive buffer in UARTProc (uart.c) is 1000 bytes in size, with MAX_PACKET_LENGTH being 350 bytes (uart.h). Another 500 bytes are allocated in UARTSend (uart.c).

From what I understand from going through the sources and reading through UM-B-017 GTL interface in Integrated Process Application.pdf and UM-B-010_DA14580_581_583 Proximity application_v1.3.pdf, the GTL interface cannot be classified as a stop-and-wait protocol. In other words, multiple event packets / messages can be sent by the DA14580 to the external processor at any given moment. On the other hand the external processor can send a command packet / message whenever required by the application.

I fully understand the reason for using dynamic memory allocation, it makes sense with a variable number of packets and a variable PAR_LEN field value. However I would like to know if static memory allocation is a viable option (and achievable looking at memory requirements). In this case I would like to know what the max value for PAR_LEN is (the maximum number of bytes of Parameters that a message can contain) and how many packets / messages could potentially be sent by the DA14580. If feasible, I could create a circular buffer of X number of packets, each with MAX_PAR_LEN bytes of Parameters (we have 32kB of RAM available in total, so for example 3 packets of each 350 bytes with a separate read buffer of 350 bytes and a write buffer of 350 bytes (for asynchronous reading/writing) is not very realistic).

I would love to hear your thoughts on this. If at all possible, I would rather not use malloc / free.

Kind regards,
Arjan

Edit 02-11-2015
I have added information regarding endianness and data structure padding below, perhaps other forum users might find this useful as well.