It is not a size problem: uint32_t is always 32 bits. Converting the
numbers to hex gives:
- Raspberry to Raspberry: 0x00000000, 0x00000016, 0x0000002c
- Arduino to Raspberry: 0x14000000, 0x2d000000, 0x00000000
There seems to be an offset between the two. You may just have lost one
byte when the Arduino is the sender. There may be also a byte order
issue, but your test is not sufficient to say. You can, e.g., send a
series of 0x12345678 to know for sure.
You need to devise a way of synchronizing the communication, i.e. to identify, in the byte stream, which is the first byte of the packet.
Edit: Let me illustrate how this can happen both with and without
and endianness issue. I'll assume you are transmitting
{status: 0, temperature: 20, humidity: 45} and the first byte(s) of
the first packet are lost. On the receiving side, you combine the
remaining bytes of the first packet with the first byte(s) of the second
packet, and interpret the whole as a single packet. You get:
{status: 335544320, temperature: 754974720, humidity: 0}.
In a little endian to little endian scenario, you only need to loose one byte:
original data: 0x00000000, 0x00000014, 0x0000002d
transmitted bytes: 00 00 00 00 14 00 00 00 2d 00 00 00
received bytes: 00 00 00 14 00 00 00 2d 00 00 00 00
received data: 0x14000000, 0x2d000000, 0x00000000
In a big endian to little endian scenario, you get the exact same result if you loose 4 bytes:
original data: 0x00000000, 0x00000014, 0x0000002d
transmitted bytes: 00 00 00 00 00 00 00 14 00 00 00 2d
received bytes: 00 00 00 14 00 00 00 2d 00 00 00 00
interpreted data: 0x14000000, 0x2d000000, 0x00000000