user50241: So I'm playing with a TFT screen and trying to understand the colourspace encoding.  I wrote a quick for loop to show colours from 0 to FFFF and to print the value of colour being displayed:
for (int q=0; q<0xFFFF; q+=0x80) {
  tft.fillScreen(q);
  tft.setCursor(0, 0); tft.println(q, HEX);
  delay(2);
}

I was surprised to find values greater than FFFF being displayed - which suggest that int is more than 16 bits.  It's running on a Uno.
What has happened?
(PS I now understand RGB565 encoding, so this is off-topic)

user4143: I guess you're seeing some big numbers starting with FFFF...?
What you are seeing is not big numbers - it's misrepresented numbers.
You have an int. That's not a "16-bit number", it's a 15-bit number plus a sign bit.  
When you print it the variable is promoted to a long and the sign bit is extended.
That long is then further mapped (cast) into an unsigned long to print it as hexadeximal (there is no negative in the hexadecimal representation on Arduino), and that extended sign bit is seen as a string of F.
For example, the value 0xABCD stored in an int is:
 1 010 1011 1100 1101

I broke off the first bit because that is the sign bit in a signed integer.  The actual decimal value of that is -21555.
Now when that gets cast to a long the sign extension copies the leading sign bit to all the other 16 bits to the left of it, resulting in:
1 111 1111 1111 1111 1010 1011 1100 1101

Because of the way that twos complement works, that string of bits still represents -21555 in decimal.
However, cast it to unsigned long for printing as HEX and you can see how you would end up with some big numbers.  It would give you:
FFFFABCD

So you can see that a 16 bit signed value can end up being printed as 8 hex digits, and all because of the way the print() function in the Arduino API works.
When working with unsigned values you really should be working with an unsigned variable - especially if those unsigned values (0 - 65535) fall outside the range of the signed variable type (-32768 - 32767).  Switch to using uint16_t and you will be able to both store and represent the values correctly.

You might find it useful playing around with this site to learn how different variable types represent and store the data within them as binary.

50241: <p>So I'm playing with a TFT screen and trying to understand the colourspace encoding.  I wrote a quick <code>for</code> loop to show colours from 0 to FFFF and to print the value of colour being displayed:</p>

<pre><code>for (int q=0; q&lt;0xFFFF; q+=0x80) {
  tft.fillScreen(q);
  tft.setCursor(0, 0); tft.println(q, HEX);
  delay(2);
}
</code></pre>

<p>I was surprised to find values greater than FFFF being displayed - which suggest that <code>int</code> is more than 16 bits.  It's running on a Uno.</p>

<p>What has happened?</p>

<p>(PS I now understand RGB565 encoding, so this is off-topic)</p>
 4143: <p>I guess you're seeing some big numbers starting with FFFF...?</p>

<p>What you are seeing is not big numbers - it's misrepresented numbers.</p>

<p>You have an <code>int</code>. That's not a "16-bit number", it's a 15-bit number <em>plus a sign bit</em>.  </p>

<p>When you print it the variable is <em>promoted</em> to a <code>long</code> and the sign bit is <em>extended</em>.</p>

<p>That <code>long</code> is then further mapped (cast) into an <code>unsigned long</code> to print it as hexadeximal (there is no negative in the hexadecimal representation on Arduino), and that <em>extended sign bit</em> is seen as a string of F.</p>

<p>For example, the value 0xABCD stored in an <code>int</code> is:</p>

<pre><code> 1 010 1011 1100 1101
</code></pre>

<p>I broke off the first bit because that is the <em>sign</em> bit in a <em>signed integer</em>.  The actual decimal value of that is -21555.</p>

<p>Now when that gets cast to a long the sign extension copies the leading sign bit to all the other 16 bits to the left of it, resulting in:</p>

<pre><code>1 111 1111 1111 1111 1010 1011 1100 1101
</code></pre>

<p>Because of the way that <em>twos complement</em> works, that string of bits still represents -21555 in decimal.</p>

<p>However, cast it to <code>unsigned long</code> for printing as HEX and you can see how you would end up with some big numbers.  It would give you:</p>

<pre><code>FFFFABCD
</code></pre>

<p>So you can see that a 16 bit signed value can end up being printed as 8 hex digits, and all because of the way the <code>print()</code> function in the Arduino API works.</p>

<p>When working with unsigned values you really should be working with an unsigned variable - especially if those unsigned values (0 - 65535) fall outside the range of the signed variable type (-32768 - 32767).  Switch to using <code>uint16_t</code> and you will be able to both store and represent the values correctly.</p>

<hr>

<p>You might find it useful <a href="http://www.binaryconvert.com/" rel="nofollow noreferrer">playing around with this site</a> to learn how different variable types represent and store the data within them as binary.</p>
