The 0x prefix is a clue to the compiler that the numbers/characters that follow are a number in base 16, not base 10. Internally, the value is stored in a variable in binary.
So I can convert the INT to a HEX already, but that just gives me the last part of what I need, without the 0x ... so how do I do this properly?
Where is this int coming from? Are you parsing a string? Converting an int to hex really does not make much sense, unless you are talking about converting an int to a printable format using hex notation.
The numbers are all handled as binary inside the uC, showing them in DEC format (base 10, such as 255) or HEX (0xFF) is just a nicety for us humans.
I think if you try a test with shifts and compound ORs you will get the correct results back.
Where does " 'color' gets pushed out " go to? Serial monitor?
PaulS:
Where is this int coming from? Are you parsing a string? Converting an int to hex really does not make much sense, unless you are talking about converting an int to a printable format using hex notation.
That int is coming from an HSL2RGB routine that spits out integers between 0 and 255 for each color. So I'll get something like:
r = 35
g = 123
b = 0
for example.
I need to take those and convert them to hex and then feed them to the code that's posted on Sparkfun's website.
It's that code that wants something between 0x00 and 0xFF to feed into the 'color' value.
That's fine though, I don't need to print anything to the Serial monitor. I will try what CrossRoads suggested when I get home later this evening. Thanks guys.