0

Code from this link: https://github.com/openwch/arduino_core_ch32/blob/main/libraries/USBPD_SINK/src/usbpd_def.h

I am looking at the previous file. I did some search and found something about unsign int literal. However, I am not sure how it would make sense in this case and hope someone can explain it to me.

typedef struct { uint32_t MaxOperatingCurrent10mAunits : 10u; uint32_t OperatingCurrentIn10mAunits : 10u; uint32_t Reserved20_21 : 2u; // 00b uint32_t EPRModeCapable : 1u; uint32_t UnchunkedExtendedMessage : 1u; uint32_t NoUSBSuspend : 1u; uint32_t USBCommunicationsCapable : 1u; uint32_t CapabilityMismatch : 1u; uint32_t GiveBackFlag : 1u; uint32_t ObjectPosition : 4u; }USBPD_SinkFixedVariableRDO_t;

Is this struct has the total size of 44 bytes assume 32bits padding? And what is the 10u, 2u at at the end of each struct member?

Improve this question
5
  • 1
    It's an explicitly unsigned integer. The value 10 has the type int, the value 10u has the type unsigned int. Commented Feb 6, 2024 at 8:43
  • 2
    As for the structure itself, it's a bitfield. uint32_t something : 10; say that the member something are using 10 bits. Commented Feb 6, 2024 at 8:44
  • 1
    Not to be condescending, but both of these should have been taught by a decent book, class or tutorial. Commented Feb 6, 2024 at 8:46
  • I wonder how you get to the size 44 bytes. There are 10 members so even in the unlikely situation where each bit field takes up a whole uint32_t 44 bytes is strange... BTW: My gues is that on most systems the size is 4 bytes. BTW: Notice how all the numbers add up to 32 (10 + 10 + 2 +...) Commented Feb 6, 2024 at 8:50
  • Perhaps read stackoverflow.com/questions/24933242/… Commented Feb 6, 2024 at 8:53

2 Answers 2

Reset to default
5

This is a non-portable type of struct known as bit-field, where some members have a size in bits as specified by the : n after each member. So MaxOperatingCurrent10mAunits is 10 bits large and so on. The bit order is not specified by the C language so it could be anything.

The general recommendation is to always avoid bit-fields and use bit masks and bit shifts with the bitwise operators instead, since they are portable and deterministic. Unlike bit-fields which are severely under-specified by the C standard.

That the bit sizes in this case is specified as unsigned integer constants ending with u/U have no significance. It is general good practice to always use unsigned ones instead of signed, but it doesn't matter in this specific case. Some coding standards like MISRA C enforce unsigned constants wherever an unsigned type is intended, so the bit sizes could be written with u just to silence a MISRA checker.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

I personally don't use bit-fields often so I'm not sure of my answer.

As far as I remember, they can be used to optimize the memory footprint of the program by using the same 32-bit integer (in this case) to store more information. So, unless there are particular compiler speed optimizations that can make it faster to access a 32-bit integer for each field instead of doing bit-mask and shift, the structure should have the size of 4 bytes because by adding all the field-sizes (those numbers after the colon) we reach 32 bits.

As said by others, it is not advisable to use them especially when it is necessary to know the position of the bit to be masked (for example the status flags in some kind of hardware emulator). I think the only pro of bit-fields are that the compiler can generate warnings if you try to assign to the field a value that is out of field range.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.