RE: Integers in characteristics little or big endian?

Raphael — Mon, 28 Mar 2016 17:49:17 GMT

OK, It may be true that it is generally up to the higher layers, but any Bluetooth GATT service, such as the Heart Rate Service. They all use Little Endian. So Nordic's MCP really should not set integers in Big Endian order since it's largely inconsistent with GATT's standard services.

RE: Integers in characteristics little or big endian?

MartinBL — Mon, 21 Mar 2016 16:55:20 GMT

I'm not entirely sure if I got all this right, but:

The Bluetooth Core spec Vol 3: Part A, Ch. 3, "Data Packet Format" says:

All L2CAP layer packet fields shall use Little Endian byte order with the exception of the information payload field. The endian-ness of higher layer protocols encapsulated within L2CAP information payload is protocol-specific.

So the payload is received and stored in memory as big endian. If I use MCP (on my PC) and write 0x11223344 this is how it is transmitted and how it is stored in memory:

However, the nRF5 core is little endian so if I cast the four byte long data into an uint32_t I will get 0x44332211.