You have a problem.
A bit-field may have type int , unsigned int , or signed int .
So unsigned int is not permitted.
An implementation may allocate any addressable storage unit large enough to hold a bit-field.
So you have no control over the number of bytes allocated.
The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined.
So if you were to try to just let it allocate (probably) 4 bytes intending to ignore the extra, then you cannot be sure whether the bits are allocated at the beginning or end of the space.
A work around for these problems requires multiple strategies:
- Define a union of unsigned short [2] and struct with bitfields, not of volatile unsigned short and something that is 16+ bits.
- Define all of the bitfields as unsigned int
- During regular execution, copy your vuint16_t into one of the unsigned short entries and access through the bitfields
- You might need to define a struct with the bitfields in exactly the other order as well
- At initialization time, test to find out how the bitfields get laid out. Take a test variable and zero the two unsigned short, and then write a 1 to EROE. Now test which of the two shorts is non-zero in order to find out which of two shorts to copy into in step 3. Now test whether the short is 0x0800 (EROE is 5th most significant bit) or is 0x0010 (EROE is 5th least significant bit) in order to determine which of the two bitfield orders you need to use.
