This is an excellent thread. A couple of points. Given:

union {
  uint32_t rgb_32;
  struct {
    uint8_t red:8;
    uint8_t green:8;
    uint8_t blue:8;
    uint8_t dummy:8;
  }col;
}rgb;

You are declaring a variable 'rbg' to be of the union type. You are not
declaring a new type. However just adding one word gives you what you want:

typedef union {
  uint32_t rgb_32;
  struct {
    uint8_t red:8;
    uint8_t green:8;
    uint8_t blue:8;
    uint8_t dummy:8;
  }col;
}rgb;

Now 'rgb' is a type which you can use to declare variables or array, as the
argument or return value of function, etc.

You are declaring a variable 'rbg' to be of the union type. You are not
declaring a new type. However just adding one word gives you what you want:

Another thing. I probably would not use bit fields because, according to th=
e
standard you cannot take their address with the & operator. Since your
fields are all full bytes I'd probably end up with:

typedef union {
  uint32_t rgb_32;
  struct {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
    uint8_t dummy;
  }col;
}rgb;

Unfortunately all this leaves you with a bit of ambiguity if portability is
important. You really don't know the byte order of rgb_32. Is 'red' the
least significant or most significant byte of rgb_32? The byte orders are
typically either 1234 or 4321, but I have dealt with at least one
architecture where they are 3412!

~ Bob Ammerman
RAm Systems

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
Josh Koffman
Sent: Sunday, August 17, 2014 2:22 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] XC8 Math weirdness?

On Sun, Aug 17, 2014 at 4:57 AM, Jan-Erik Soderholm
<jan-erik.soderholm@telia.com> wrote:
> And, if it wasn't clear from Rubens text :-), this is much faster=20
> since there will not be any multiplications or shifts at all. Just=20
> simple assignments:
>
> rgb.col.red =3D red;
> rgb.col.green =3D green;
> rgb.col.blue =3D blue;

Yep, I dig it! I will probably leave the actual assignments to a function
that I've written, that way it can be swapped out in the future. Plus
changing the color of an LED is a single line in my main code.

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

Would that change the definition to:


?

> Hasn't some C compilers also 24 bit integers?

I can't remember where, but I thought I read something about 24 bit ints no=
t
being a standard, so they weren't recommended for portability. I haven't
looked into XC16 or XC32 to see if they support it though.

Josh
--
A common mistake that people make when trying to design something completel=
y
foolproof is to underestimate the ingenuity of complete fools.
        -Douglas Adams
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/chang=
e
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

--=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
.