Josh Koffman wrote:
>     greentemp =3D green * 0x10000;
>     redtemp =3D red * 0x100;
>     bluetemp =3D blue;
>
> The temp variables are all uint32_t, and the input values are all
> uint8_t. The goal is to shift the values over so I can then add them
> together.
>
> When I execute this code with all of the input values as 0xFF, things
> are weird. Green (*0x10000) and Blue (*1) work fine, I end up with
> 0xFF0000 and 0xFF, respectively. However, redtemp ends up with
> 0xFFFFFF00, which I can't explain.
>  =20
The int size in the microchip compilers is 16 bit iirc.

In c types smaller than int are supposed to be (though iirc at least C18=20
had an option to not do this) are automatically promoted to int and your
constant is probablly also being treated as an int.

So  red * 0x100 is treated as (int)red * (int)0x100 which gives an int=20
with value 0xFF00. I'm not sure if C defines what should happen when a=20
smaller signed type is assigned to a larger unsigned type but it seems=20
C18 is sign extending it.

0x10000 works because it's too big to fit in an int. So it gets treated=20
as a long. That forces the multiplication to be treated as a=20
multiplication of a pair of longs producing a long result.

You need to add an explicit cast to force things to be done with the=20
type you want. e.g.

redtemp =3D red * (uint32_t)0x100;


--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.