Bit endianness is an issue in bitfields?

[NSemrHomeInit]

Dear ST hello,

I have a question about the bit field,

I am using the stm32F429 discovery board, and I am working on the gyroscope Mems.

if I declare a union like this:

typedef volatile union
{
	uint8_t All;
	struct
	{
		uint8_t Yen:1; /*X axis enable*/
		uint8_t Xen:1; /*Y axis enable*/
		uint8_t Zen:1; /*Z axis enable*/
		uint8_t PD:1;  /*Power-down mode enable*/
		uint8_t BW0:1;
		uint8_t BW1:1; /*Bandwidth selection*/
		uint8_t DR0:1;
		uint8_t DR1:1; /*Output data rate selection*/
	} RegBits;
 
} Tst_CTRL_REG1;

How does the compile organize the bits in memory?

Does the MSB is Yen or DR1?

Thank you in advance,

[waclawek.jan]

Yen is LSB, DR1 is MSB.

JW

[NSemrHomeInit]

Thank you for your answer,

I think these kind of information could be found in the compiler user Manuel.

do i have to look for is in stm or arm cortex m4 website?

[Tesla DeLorean]

GCC​

[waclawek.jan]

>>I think these kind of information could be found in the compiler user Manuel.

>GCC

It's more complicated than one would think.

https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html :

The order of allocation of bit-fields within a unit (C90 6.5.2.1, C99 and C11 6.7.2.1):

Determined by ABI.

Okay, so where's ABI for ARM (i.e. ARM's rules determining how to write compilers so that their objects are mutully linkable)?

https://github.com/ARM-software/abi-aa - the bitfield ordering is in "Procedure Call Standard" https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst, bitfields are namely in https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#8171bit-fields-no-larger-than-their-container

ARM Cortex-M are fixed little endian, so

For little-endian data types

K(F)

is the offset from the least significant bit of the container to the least significant bit of the bit-field.

JW

[S.Ma]

Did you browse the STMems sensor drivers on github ?

Here is an extract:

typedef struct
{
#if DRV_BYTE_ORDER == DRV_LITTLE_ENDIAN
  uint8_t bit0       : 1;
  uint8_t bit1       : 1;
  uint8_t bit2       : 1;
  uint8_t bit3       : 1;
  uint8_t bit4       : 1;
  uint8_t bit5       : 1;
  uint8_t bit6       : 1;
  uint8_t bit7       : 1;
#elif DRV_BYTE_ORDER == DRV_BIG_ENDIAN
  uint8_t bit7       : 1;
  uint8_t bit6       : 1;
  uint8_t bit5       : 1;
  uint8_t bit4       : 1;
  uint8_t bit3       : 1;
  uint8_t bit2       : 1;
  uint8_t bit1       : 1;
  uint8_t bit0       : 1;
#endif /* DRV_BYTE_ORDER */
} bitwise_t;

[NSemrHomeInit]

No, I am creating my one driver.

[NSemrHomeInit]

Realy, are we uisng Gcc in cubeIDE?

I think you want to say arm ...GCC. Here is the compiled called when I compile the project arm-none-eabi-gcc.

[Tesla DeLorean]

Well it's not using KEIL's, IAR's or ST's compilers

The ARM ABI presumably dictates the general rules of engagement

ARM Embedded Application Binary Interface (AEABI) ?

Don't most/all Little-Endian implementation count bits from the right, and encode least-significant bytes first?

The old ARM7 and ARM9 chips had big and little endian options depending on what the SoC ASIC needed.

[Pavel A.]

IIRC the gcc compiler has an option to select endianness of bit fields.

Generally bit fields in shared code (libraries) are deprecated, exactly because of portability among various compilers. Otherwise, be ready to write the bitield structs twice and use custom defines, as in the example above.

From the ABI docum cited by Jan:

"The AAPCS does not allow exported interfaces to contain packed structures or bit-fields."