And, if it wasn't clear from Rubens text :-), this is
much faster since there will not be any multiplications
or shifts at all. Just simple assignments:

rgb.col.red =3D red;
rgb.col.green =3D green;
rgb.col.blue =3D blue;

B.t.w, I'd define a dummy byte also, just so it is
clear at what end the "zero byte" is...

Hasn't some C compilers also 24 bit integers?

Jan-Erik.

Ruben J=F6nsson wrote 2014-08-17 10:38:
> Have you considered using a union for that:
>
> union {
>    uint32_t rgb_32;
>    struct {
>      uint8_t red:8;
>      uint8_t green:8;
>      unit8_t blue:8;
>    }col;
> }rgb;
>
> This way you can access the 32 bit value with rgb.rgb_32 and, for
> example red with rgb.col.red for both reading and writing.
>
> You can still use the shift/multiply methods with rgb.rgb_32 (but you
> need to know how the bitfields are ordered by the compiler).
>
> The union means that the variables within it shares the same memory
> (rgb_32 and col in this case).
>
> /Ruben
>
>> Hi all,
>>
>> Plugging away at my LED project. I'm currently trying to combine 3
>> separate 8 bit values into one 24 bit value (stored in a 32 bit
>> variable), and I've come across some weirdness.
>>
>> As part of my function, I've broken things down farther than I usually
>> would to help isolate the problem. I now have this code:
>>
>>      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.
>>
>> Changing the red multiplier to 0x10000 (just as a test) works.
>> Changing it to 0x1 works as well. But...0x100 doesn't.
>>
>> I know I'm probably missing something simple here, but I can't seem to
>> figure it out.
>>
>> Help!
>>
>> Josh
>> --
>> A common mistake that people make when trying to design something
>> completely foolproof is to underestimate the ingenuity of complete
>> fools.
>>          -Douglas Adams
>> --
>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2014.0.4745 / Virus Database: 4007/8050 - Release Date: 08/17/1=
4
>>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> Ruben J=F6nsson
> AB Liros Electronic
> Box 9124, 200 39 Malm=F6, Sweden
> TEL INT +46 40142078
> FAX INT +46 40947388
> ruben@pp.sbbs.se
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>
--=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
.