English is currently available.
Computer Engineering DISCUSSION
I am sending a 32-bit value from a microcontroller to a PC program over a serial link by copying the four bytes of the variable into the transmit buffer. The value 0x12345678 arrives correctly on one PC program but a colleague's receiver on a different platform shows 0x78563412.
I know this is byte order, but I am not sure what exactly is stored where, when endianness affects my code and when it does not, and what the correct way to send multi-byte values is.
Endianness is the order in which the bytes of a multi-byte value are placed at increasing memory addresses. For 0x12345678 stored at address A, a little-endian machine puts the least significant byte first: 78 at A, 56 at A+1, 34 at A+2, 12 at A+3. A big-endian machine stores 12, 34, 56, 78. It concerns bytes only; the bits inside each byte are not reversed.
x86 and x86-64 are little-endian, and ARM microcontrollers are little-endian in practice. Most network protocols define big-endian as the order on the wire, which is why it is also called network byte order. Your code sends memory order, and a receiver assuming the other order reads 0x78563412.
Endianness only becomes visible when a value is viewed as individual bytes: writing it to a file or link, overlaying a struct on a receive buffer, casting a uint32_t* to a uint8_t*, or using a union. Arithmetic on values is unaffected. x >> 24 always yields the most significant byte and x & 0xFF always the least significant, on any machine, because shifts and masks operate on the value and not on its memory layout.
That gives the rule: code that never looks at the bytes of a value through a pointer or a copy is endian-neutral.
The portable way to send is to define the wire order in your protocol document and build the bytes with shifts, never with memcpy of the variable. For big-endian on the wire: buf[0] = v >> 24; buf[1] = v >> 16; buf[2] = v >> 8; buf[3] = v;. The receiver rebuilds it with v = ((uint32_t)buf[0] << 24) | ((uint32_t)buf[1] << 16) | ((uint32_t)buf[2] << 8) | buf[3];.
This code is correct on every processor, and it also avoids the other two problems of copying structs raw: padding between members and alignment, both of which differ between compilers.
Useful recognition patterns when debugging: a small number that arrives enormous is nearly always byte order. The value 1 sent as four bytes and read the wrong way round becomes 0x01000000, which is 16,777,216; 256 becomes 65,536. A value that looks like its hex digits reversed in pairs, as yours does, is the same thing.
Be aware of mixed orders too. Some protocols carry 16-bit words big-endian but leave the order of the two words of a 32-bit value or float to the device vendor, so you can receive 0x56781234. Floats follow the same byte order as integers on almost all platforms, so treat them as a 32-bit pattern and serialise that.
