Understanding Byte-Order (Little-Endian) in arduino serial communication

[Zero2]

Hi!

I am trying to set up a serial communication between my arduino nano and matlab/simulink.

Problem is, in simulink i have to specify the used byte order. I know arduino (Atmel avrs) use litle endian, however, if i print a binary number to the serial port:

Code: [Select]

      Serial.println(105,BIN);     
the arduino serial monitor shows me

Code: [Select]

1101001
1101001
1101001
1101001


Ok, as far as i understand the leading "0" (which would carry the no-existent '128' value) has been left out by the serial monitor:
MSB ->  [0*128] +1*64 +1*32+ 0*16 + 1*8 +0*4 +0*2 +1*1   <-LSB

However, in this order, the MostSignificantBit comes first. Would that not be "Big-Endian" instead of "Little-Endian"? I am confused...

Best regards,
Zero2

[billroy]

Looking at the transmitted byte after it has been properly reassembled won't tell you what order the bits arrived in, right?

Here is how I understand it: endianness refers to the ordering of the bytes within the larger word.  The order of _serial_ transmission of the bits within a byte is, by convention, least significant bit (LSB) first:

Most serial communications designs send the data bits within each byte LSB (Least significant bit) first. This standard is also referred to as "little endian."
from: http://en.wikipedia.org/wiki/Serial_port

-br

[PaulS]

Little endian vs. big endian means something when you are sending larger-than-byte sized values as binary to the serial port. The print() and println() methods are NOT how you send binary data to the serial port.

So, you've learned nothing from your test.

[Zero2]

Ah, now i get it! I confused two things:
-order of bits within the byte and
-order of bytes within a larger number

Thanks!

[nickgammon]

Here is how I understand it: endianness refers to the ordering of the bytes within the larger word.  The order of _serial_ transmission of the bits within a byte is, by convention, least significant bit (LSB) first:

That's correct for async serial (bits within a byte). The reason is that in the early days you used to not necessarily send all 8 bits, so you would start with the least significant (which you always wanted to send) and send the rest, up to the most significant. So for example if you were sending 7 bits the final one (the most significant) would be omitted (presumably because it was zero).

Other serial techniques (eg. SPI) often send the most significant bit first. With the SPI hardware that can be configured, so the datasheets usually say which order a device expects the bits. And in the case of multiple bytes it will also specify the order of the bytes (which will not necessarily be the same order as the bits within a byte).