I am having a hard time understanding how the “ieee802154_set_frame_hdr” function, found in this link, sets the Frame Control Field (FCF) for 802.15.4 frame header.
Following the IEEE 802.15.4 FCF format, frame version should be at the 12-13th bit of the 2-byte FCF, while in the function code, the frame version was set at the 11th bit. Does it uses different FCF format or am I missing something?
I think you must have made a mistake in your calculations. buf contains bits 8-15 of the fcf, bits 12-13 are the version bits. 12 - 8 = 4, 1 << 4 = 0x10, so the frame version is set to version 1, all other bits are zero at the beginning of that function.
Thank you, Joakim, but I don’t think it is correct.
Starting from 0, bit No. 3 of the IEEE802154_FCF_VERS_V1 (Hex 0x10 or binary: 0001 0000) have the value 1, thus 0 to 3 represent 8 to 11 on buf. therefor, the bit No. 3, in 0x10, is set on bit No. 11 of the FCF.
Not sure if the below illustration will be on a layout.
0000 0000 0000 0000 <-- FCF
I think you are confusing byte ordering with bit ordering, the IEEE
802.15.4 frame format uses little-endian _byte_ ordering, so the least
significant byte comes first. But inside each byte, the least
significant bit has number 0, the most significant bit has number 7.
Therefore, a byte where only bit number 4 is set (written 1 << 4 in
C), is equal to 0x10.
Thank you, Anton. Please bear with me if I misunderstood any programming fundamentals,
I agree that the 4th bit of buf is set to 1, but according to FCF format the 13th and 14th bits, of buf[0-1], must be set for frame version, or if you start counting the FCF bits from 0 to 15, bit 12 and bit 13 are the frame version bits.
buf = IEEE802154_FCF_VERS_V1 means the 12th bit is set to 1, or the 11th bit if we start counting FCF bits from 0 to 15.
Besides, when I did print buf I get decimal 16, while I should get decimal 8 for the frame version to be set.