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,

[Tesla DeLorean]

Exactly, you typically have to make it Endian and Compiler specific, and cover your bases, because it is not defined explicitly by K&R in the language definitions, and it tends to follow the most architecturally appropriate path (of least resistance).

So the standard shift, bit insertion / extraction instructions are usable directly in the code generation stage.

Nor do you know what the rules are on other platforms the code may be migrated to later, developers tend to flag this type of dependency / pitfall in the code / definitions.

[NSemrHomeInit]

I took a look to st drivers in the GitHub repository and I could not understand why there are using context structure? is they using any OS and they have to save the PC and the register variable or just naming this way? That you in advance,

Here is the struct definition, I am little bit curios about this its okay if you don't any answer.

typedef struct
{
	/** Component mandatory fields **/
	stmdev_write_ptr write_reg;
	stmdev_read_ptr read_reg;
	/** Component optional fields **/
	stmdev_mdelay_ptr mdelay;
	/** Customizable optional pointer **/
	void *handle;
} stmdev_ctx_t;

[Tesla DeLorean]

Not sure, object, handle, context, instance seem appropriate naming for things passed as a pointer

Pavel /Jan just highlight that you need to be cautious about how things are passed if you use external libraries, or different compilers, with different options/packing expectations.

Bit fields being a specifically problematic area, and also byte packing. Historically structures in files and RAM may expect the smallest size, whereas in an MCU that's not byte orientated (ie post 8-bit MCU) there are speed or architectural expectations about size and alignment. The 80x86 MCU's tending to be very flexible/tolerant, via RISC much less so, and in the ARM family the CM0 much less forgiving than CM3/CM4/CM7

[NSemrHomeInit · Accepted solution]

this project could be run on many boards and in the context we send the handler and the read and write functions to write and read to the specific bus depending on the board chosen.