MC9S08DV16 bit field warnings

[ngsoftuser]

Hi all,

In our project we have two MC9 devices connected to each other using UART.

One is slave and one is Master.

Our master device is a MC9s08DZ60 while the slave was chnaged to MC9S08DV16.

Each project (MCU) has its own project. Both projects share same file.

In this file I defined structure with bit field.

The problem is that the MC9S08DV16 compiler prints warning regarding these bit fields:

"warning:C1106 Non-standard bitfield type".

Can I still use bit fields for this MCU or not? are there any side effects using bit fields in this MCU?

Thanks.

[Lundin]

The problem likely is that the standard register maps in Codewarrior are using bit field types of uint8_t which is implementation-defined and non-portable.

If you are writing portable code, bit fields cannot be used, they are non-portable, useless, superfluous crap. This is true for any C language compiler. The following is not specified by the standard:

- whether bit field int is treated as signed or unsigned int
- the bit order (lsb is where?)
- whether the bit field can reach past the memory alignment of the CPU or not
- the alignment of non-bit field members of the struct
- the memory alignment of bit fields (to the left or to the right?)
- the endianess of bit fields larger than one byte
- whether plain int values assigned to them are interpreted as signed or unsigned
- how bit fields are promoted implicitly by the integer promotions
- whether signed bit fields are one’s compliment or two’s compliment
- padding bytes
- padding bits
- values of padding bits.
- and so on.

Feel free to send a service request to Freescale and ask them why they can't deliver C standard compliant, MISRA-compliant, portable headers for the register maps.

[ngsoftuser]

Hi Daniel, thank you for your reply.

I am getting warnings for the following strcuture:

byte is defined as followed:

unsigned char byte;

struct _LEDS

{

    byte Emergency:2;

    byte CallCenter:2;

    byte User1:2;

    byte User2:2;

    byte Mute:2;

    byte VolumePlus:2;

    byte VolumeMinus:2;

    byte Answer:2;

    byte Hangup:2;

    byte Red:2;

    byte Green:2;
}LEDS, *PLEDS;

It's not that i am doing something wrond here. Am I?

[bigmac]

Hello Eran,

Had you used the following code, I think that the warning message would not have been generated, even without the presence of the #pragma.

#ifndef word

typedef unsigned int word;

#endif

struct _LEDS {

   word Emergency  :2;

   word CallCenter :2;

   word User1      :2;

   word User2      :2;

   word Mute       :2;

   word VolumePlus :2;

   word VolumeMinus:2;

   word Answer     :2;

   word Hangup     :2;

   word Red        :2;

   word Green      :2;
} LEDS, *PLEDS;

Each structure will be packed into two 16-bit words.

The use of non-standard, byte type bit fields within the device header file, is to provide a "match" to the hardware register structure for the device.

Regards,

Mac

[ngsoftuser]

Hi bigmac,

So i understand that byte is a non-standard use gfor bit field while Word is.

Using byte or Word ends up with same struct size of 3 bytes.

[bigmac]

Hello Eran,

Using "word" within the structure definition will result in a structure size of 32 bits, or 4 bytes, with 10 bits unused.  The structure size will always be a multiple of 16 bits.

Since each bit field is 2 bits long, there should be little advantage in using 8-bit byte multiples.

However, had your structure actually consisted of single bit flags only, and provided you place the structure in zero page RAM, the use the non-standard byte definition can be justified because it should result in considerably simpler (and faster) code, making use of the bit manipulation instructions BSET, BCLR, etc.

Regards,

Mac

[kef]

Mac,

no, using "word" or int in bitfield doesn't make struct size multiple of 16bits. It depends on compiler and target specifics only. This is why no one should use bitfields to form some datagram to be sent to PC or other MCUs. Compiler for 2nd end of wire most certainly will swap bit fields order or add padding bytes and won't make code talking the way you expect.

CW 6.3 for MCUs for both byte=char and byte=word generates the same code and reserves 3 bytes for LEDS struct. Unless you change some settings.

[kef · Accepted solution]

You get this warning because you should use int type for bitfields, not char or anything else.

I think that in one of your projects your struct is defined after inclusion of derivative.h or MC9Sxxx.h, while in another project you declare the same struct above the similar includes. If you look into these file you should find this line

#pragma MESSAGE DISABLE C1106 /* WARNING C1106: Non-standard bitfield type */

[ngsoftuser]

Thank you. I saw that the project which doesn't show this warning uses the pragma but the other one doesn't.

Thanks again.