Shop OBEX P1 Docs P2 Docs Learn Events
16-bit little-endian 2's complement — Parallax Forums

16-bit little-endian 2's complement

QuadrtrFlyrQuadrtrFlyr Posts: 73
edited 2013-01-09 03:13 in Propeller 1
I have a hexadecimal (FF F3) coming in over a serial line that is a 16-bit little-endian 2's complement value and I need to convert it to a decimal..
However I was trying to understand the little endian part but am now very confused. Could anyone please lend a helping hand?

Also is there any differnce between a regular 16-bit 2's complement integer and 16-bit little-endian 2's complement value?

Thank you

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2013-01-08 17:48
    The only difference in little/big endian is that the bytes get stored in reverse order in memory.
  • QuadrtrFlyrQuadrtrFlyr Posts: 73
    edited 2013-01-08 17:50
    So what is the standard? Because another value coming in on the serial line is just a 16 bit 2's complement integer without mention of the little endian part (stated in the user manual). No mention of big or little endian. Should I treat both of these cases equally?
  • JonnyMacJonnyMac Posts: 9,108
    edited 2013-01-08 19:42
    Little-Endian (the way the Propeller stores values) means the bytes in a mult-byte value are arranged lowest to highest in RAM.

    2's compliment means the value is signed (sign is in bit15). As your're receiving two bytes, you can convert to a signed long like this.
    myval.byte[0] := device.rx
  myval.byte[1] := device.rx
  myval := ~~myval
  • QuadrtrFlyrQuadrtrFlyr Posts: 73
    edited 2013-01-08 19:45
    Very helpful! Thank you Jonny!
  • Heater.Heater. Posts: 21,230
    edited 2013-01-09 01:09
    QuadrtrFlyr,

    Hope you have your problem solved.

    Just wanted to add that there is no standard.

    With a computer big numbers can be held in memory such that the least significant bytes are at the lower addresses, littlendian, or with the most
    significant bytes at the lower addresses, bigedndian.

    Just to make life confusing Intel CPUs are little-endian, while Motorola 680x0 CPUs are big-endian.

    To make it even more confusing Intel Itanium and ARM processors can be either. I believe littleendian has become the norm for ARM now a days.

    Normally none of this matters until you dump the bytes of memory and get confused because all the numbers look backwards.
    Problems can arise when you want to pack bytes into longs or take the addresses of bytes within a word or long etc.

    Then, just to make life even more confusing we find that when communicating over serial lines and such large numbers can be sent least significant or most significant bytes first. As you have found.
  • Mark_TMark_T Posts: 1,981
    edited 2013-01-09 03:13
    Endianess is to do with addressing of individual bytes in a word and is a property of the CPU (some allow it to be
    changed such as the DEC Alpha). It only shows up if you access values inconsistently (reading a byte from
    an area of memory containing longs, for instance)

    For serial transmission this is irrelevant - you talk of byte order and bit order - ie LSB first or MSB first - this can
    be different for bits within bytes from bytes with words. Assuming you have already read in the bytes
    correctly then you need to know if the packet is using "network byte order" (most sig byte first) or the opposite.

    However many programs get the network data already put into memory by the OS - then endianness will matter
    as the OS will treat the data as a byte stream and store as bytes - you may want to see ints... This means you
    are exposed to both network byte order and the local endianess.

    2's complement or not is irrelevant here, we are not interpreting the values, merely transmitting the bits. The task
    is to reconstruct the same bit pattern in the local device as was in the sending device.
Sign In or Register to comment.