Fix #4911 : Partially rework some code to remove warnings about potential non-aligned memory accesses

[TheMalkavien]

Hi,

As discussed in the issue #4911, here is my approach to contain the memory alignment issue

There is some very easy fixes based on memcpy insted of pointer arithmetic and dereferrence. This is a quick win.

But I had to think of another way to work with the radiobuffer bytebuffer, because of how it was previously handled, the only way was using pointer arithmetic to access payload after the header.

So I just replaced the byte buffer by a struct containing header then payload :

/**
 * This structure represent the structured buffer : a PacketHeader then the payload. The whole is
 * MAX_LORA_PAYLOAD_LEN + 1 length
 * It makes the use of its data easier, and avoids manipulating pointers (and potential non aligned accesses)
 */
typedef struct {
    /** The header, as defined just before */
    PacketHeader header;

    /** The payload, of maximum length minus the header, aligned just to be sure */
    uint8_t payload[MAX_LORA_PAYLOAD_LEN + 1 - sizeof(PacketHeader)] __attribute__ ((__aligned__));

} RadioBuffer;

As you can see, this is very simple. And I replaced all the pointer code by struct accesses :

PacketHeader *h = (PacketHeader *)radiobuf;
h->from

becomes :
radioBuffer.header.from

and
radiobuf + sizeof(PacketHeader)
becomes :
radioBuffer.payload

Its more elegant too :)

The result is, less memory-aligned warnings, and a more safe code to use, and depending of your coding style, more readable I guess.
I quickly tested it on RP2040, HTv3 and HT Tracker 1.1 (to test the gps part) without seeing any issue.

This should Fix #4911 (partially at least) and gives a good start (or just ideas) to a more robust code.

Regards,

[caveman99]

LGTM. We need to make sure the packetheader stays the same size and alignment no matter what processor architecture we're running on.