Sending struct from Arduino to Raspberry Pi - wrong types I'm using Raspberry Pi and Arduinos for my home automation project where Raspberry Pi is the controler of Arduino nodes.
I use nRF24 wireless transceivers to communicate.

My problem is that when I was sending a structure like following

struct TempSensorData


{
      uint32_t result;
      uint32_t temperature;
      uint32_t humidity;
    };

From Raspberry to Raspberry everything went fine but now when I use Arduino as sender I get very strange results:

received: status: 335544320, temperature: 754974720 degrees, humidity: 0%


While on Raspberry it was

received: status: 0, temperature: 22 degrees, humidity: 44%


Can this be a problem with types? Or with different type of architecture (like different sizes on 3-2bit and 64-bit arch)?

EDIT:

Code on Raspberry:

if (radio.available())


{
        // dump the payloads until we've got everything
        Message receivedData = {0};
        radio.read(&amp;receivedData, sizeof(Message));
        TempSensorData data = receivedData.msgData.tempSensorData;
        std::cout &lt;&lt; "received: status: " &lt;&lt; data.result &lt;&lt; ", temperature: " &lt;&lt; data.temperature &lt;&lt; " degrees, humidity: " &lt;&lt; data.humidity &lt;&lt; "%" &lt;&lt; std::endl; //TODO here we have some strange numbers - check if we have proper types
    }

Before that I have:

radio.begin();
radio.setPALevel(RF24_PA_LOW);
radio.setChannel(0x4c);
radio.openReadingPipe(1, RASPI_READ_ADDR);
radio.openWritingPipe(RASPI_WRITE_ADDR);

radio.enableDynamicPayloads();
radio.setAutoAck(true);
radio.powerUp();
radio.startListening();


And on Arduino:

Header header = {thisNodeId, thisNodeType, 0, static_cast&lt;uint8_t&gt;(MsgType::TEMP_SENSOR_DATA), 12345, Status::ok};
TempSensorData dhtData;
dhtData.result = DHT.read11(DHT11_PIN);
dhtData.humidity = (int)DHT.humidity;
dhtData.temperature = (int)DHT.temperature;
Message message = {0};
message.header = header;
message.msgData.tempSensorData = (dhtData);
radio.stopListening();
radio.write(&amp;message, sizeof(message));
radio.startListening();


I also use a common header with defined structures for both Arduino and Raspberry, which contains:

#define RASPI_WRITE_ADDR 0xF0F0F0F0F0LL
#define RASPI_READ_ADDR 0xF0F0F0F0E1LL

struct TempSensorData {   
  uint32_t result;
  uint32_t temperature;
  uint32_t humidity;
};  

enum class Status : uint8_t


{
        ok,
        error,
        fail
    };

enum class MsgType : uint8_t {
    INITIALIZATION,
    RESET_REQUEST,
    ACK_NACK,
    TEMP_SENSOR_DATA,
};

struct Header {
  uint8_t nodeId;
  uint8_t nodeType;
  uint8_t location;
  uint8_t msgType;
  uint16_t checksum;
  Status status;
};

union MsgData {
  InitMsgData initMsgData;
  AckNack ackNack;
  TempSensorData tempSensorData;
};

struct Message {
    Header header;
    MsgData msgData;
};


radio is an item of RF24 class from https://github.com/TMRh20/RF24/

Unfortunately the RF24 repo is 64 commits ahead of what I use.

EDIT2:

Maybe the problem lays in that 

enum class Status {};


which I use in both files.

I must add that I use g++-4.7 when compiling on Raspberry and when compiling on Arduino I use avr-g++-4.8.2
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