CodeWarrior for MCUのトピックRe: long bit field problem

long bit field problem

BasePointer — Thu, 29 Oct 2020 08:46:37 GMT

Hi,

I'm using CW 5.1 with MC9S08LC60.

Code:

typedef struct { unsigned char R0:1; unsigned char R1:1; unsigned char R2:1; unsigned char R3:1; unsigned char R4:1; unsigned char R5:1; unsigned char R6:1; unsigned char R7:1; unsigned char R8:1; unsigned char R9:1; unsigned char R10:1; unsigned char R11:1; unsigned char R12:1; unsigned char R13:1; unsigned char R14:1; unsigned char R15:1;  unsigned char R16:1; unsigned char R17:1; unsigned char R18:1; unsigned char R19:1; unsigned char R20:1; unsigned char R21:1; unsigned char R22:1; unsigned char R23:1; unsigned char R24:1; unsigned char R25:1; unsigned char R26:1; unsigned char R27:1;  unsigned char R28:1; unsigned char R29:1; unsigned char R30:1; unsigned char R31:1;} TMaskBits;typedef union { unsigned long Val; TMaskBits Bit;} TMASK;

I'm declaring a variable:

Code:

TMASK tmp;tmp.Val = 531968; // 0b10000001111000000000

If I test tmp.Bit.R12, I see it is not 1.

If I test tmp.Bit.R19, I see it is not 0.
But all they should be.

What do you thing about the problem here? Is this a bug?

Here is the result:

Code:

R0 -> 0R1 -> 0R2 -> 0R3 -> 0R4 -> 0R5 -> 0R6 -> 0R7 -> 0R8 -> 0R9 -> 0R10-> 0R11-> 1R12-> 0R13-> 0R14-> 0R15-> 0R16-> 0R17-> 1R18-> 1R19-> 1R20-> 1R21-> 0R22-> 0R23-> 0R24-> 0R25-> 0R26-> 0R27-> 0R28-> 0R29-> 0R30-> 0R31-> 0

Re: long bit field problem

Lundin — Tue, 20 Feb 2007 15:50:19 GMT

You can't use the type long for bitfields.

Problems with and suggestions about bitfields can be found here:

http://forums.freescale.com/freescale/board/message?board.id=CWCOMM&message.id=3751

Message Edited by Lundin on 2007-02-2008:52 AM
Alban fixed link.

Message Edited by Alban on 2007-02-20 08:39 AM

Re: long bit field problem

BasePointer — Thu, 29 Oct 2020 08:46:39 GMT

Hi Lundin,

This is a endianism problem. I changed the byte order of bitfield. And I saw it worked like I expected.

Code:

typedef struct { unsigned char R24:1; unsigned char R25:1; unsigned char R26:1; unsigned char R27:1;  unsigned char R28:1; unsigned char R29:1; unsigned char R30:1; unsigned char R31:1;

 unsigned char R16:1; unsigned char R17:1; unsigned char R18:1; unsigned char R19:1; unsigned char R20:1; unsigned char R21:1; unsigned char R22:1; unsigned char R23:1;

 unsigned char R8:1; unsigned char R9:1; unsigned char R10:1; unsigned char R11:1; unsigned char R12:1; unsigned char R13:1; unsigned char R14:1; unsigned char R15:1;

 unsigned char R0:1; unsigned char R1:1; unsigned char R2:1; unsigned char R3:1; unsigned char R4:1; unsigned char R5:1; unsigned char R6:1; unsigned char R7:1;} TMaskBits;

Re: long bit field problem

Lundin — Tue, 20 Feb 2007 18:34:22 GMT

Yes, as mentioned in my post, the endianess of bitfields is not specified in the standard, nor is the result you get from using long. That code will not be portable.