我面临的挑战是内存分配。到目前为止，我们一直避免在我们的嵌入式代码中使用malloc/free，这只是为了防止引入灾难性的副作用，比如内存泄漏(它还可能与我们的RTOS结合带来新的挑战)。在上述项目的ble_msg中，我看到malloc和free是通过BleMsgAlloc和BleFreeMsg使用的，uart.c中的SendToMain也是如此。此外，UARTProc (uart.c)中的接收缓冲区大小为1000字节，MAX_PACKET_LENGTH为350字节(uart.h)。在UARTSend (uart.c)中分配另外500个字节。

从综合过程应用.pdf和UM-B-010_DA14580_581_583 Proximity application_v1.3.pdf中的源和读取UM-B-017 GTL接口的理解来看，GTL接口不能被归类为停止-等待协议。 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.