user-1: I was playing around with some analog grove sensors and looking at examples (https://github.com/DexterInd/GrovePi/blob/master/Software/Go/grovepi/grovepi.go - this specific example is in go and for raspberry pi, but it's the same on arduino) I realised that you need to "(int(val[1]) << 8) | int(val[2])" before getting the result.
Why is that so? Why do the second 8 bits need to be left shifted by 8 and why is there then an OR with the third group of bits?

user31105: You read bytes in the order: 

Most significant byte   (let's call this msb)
Least significant byte  (let's call this lsb)

The formula to get to real value is msb * 256 + lsb
256 because this is the value of the maximum value of one byte, + 1. which is bits (2 ^ 8 = 256).
However, a CPU is normally faster in bit operations than in arithmetic operations.  
Assume msb is 10101010
and lsb is    11001100

Now below is the table with the calculation order
sensor value             msb         lsb
00000000 00000000        10101010    11001100
00000000 10101010                                sensor value = msb
10101010 00000000                                msb << 8, or msb * 256
10101010 11001100                                (msb << 8) + lsb, or (msb * 256) + lsb

Actually I would expect a cast to an unsigned byte type (8 bits). However, if the values msb or lsb would be floating points/doubles, than the remainder will be removed, leaving an integer (whole) number.

-1: <p>I was playing around with some analog grove sensors and looking at examples (<a href="https://github.com/DexterInd/GrovePi/blob/master/Software/Go/grovepi/grovepi.go" rel="nofollow noreferrer">https://github.com/DexterInd/GrovePi/blob/master/Software/Go/grovepi/grovepi.go</a> - this specific example is in go and for raspberry pi, but it's the same on arduino) I realised that you need to "(int(val[1]) &lt;&lt; 8) | int(val[2])" before getting the result.</p>

<p>Why is that so? Why do the second 8 bits need to be left shifted by 8 and why is there then an OR with the third group of bits?</p>
 31105: <p>You read bytes in the order: </p>

<ul>
<li>Most significant byte   (let's call this msb)</li>
<li>Least significant byte  (let's call this lsb)</li>
</ul>

<p>The formula to get to real value is msb * 256 + lsb
256 because this is the value of the maximum value of one byte, + 1. which is bits (2 ^ 8 = 256).</p>

<p>However, a CPU is normally faster in bit operations than in arithmetic operations.  </p>

<pre><code>Assume msb is 10101010
and lsb is    11001100
</code></pre>

<p>Now below is the table with the calculation order</p>

<pre><code>sensor value             msb         lsb
00000000 00000000        10101010    11001100
00000000 10101010                                sensor value = msb
10101010 00000000                                msb &lt;&lt; 8, or msb * 256
10101010 11001100                                (msb &lt;&lt; 8) + lsb, or (msb * 256) + lsb
</code></pre>

<p>Actually I would expect a cast to an unsigned byte type (8 bits). However, if the values msb or lsb would be floating points/doubles, than the remainder will be removed, leaving an integer (whole) number.</p>
