為什么MISRA要求你不要使用位域-本文告訴你真相

本文轉(zhuǎn)自公眾號(hào)，歡迎關(guān)注

為什么MISRA要求你不要使用位域-本文告訴你真相 (qq.com)

一．前言

做過(guò)嵌入式開(kāi)發(fā)的一般會(huì)看到一條編程規(guī)范:”不要使用位域”，一般都是知其然不其所以然，了解的多一點(diǎn)的可能知道位域是實(shí)現(xiàn)相關(guān)不具備可移植性，那么繼續(xù)追問(wèn)哪些行為是實(shí)現(xiàn)相關(guān)哪些行為導(dǎo)致移植性問(wèn)題? 或者還有人知道，存儲(chǔ)布局，對(duì)齊等行為是實(shí)現(xiàn)相關(guān)會(huì)導(dǎo)致不可移植性。如果再追問(wèn)位域產(chǎn)生的匯編代碼是什么樣的，怎么進(jìn)行讀-修改-寫(xiě)操作的？知道這些內(nèi)容的就更加少之又少了。 讀寫(xiě)肯定不能讀指定位數(shù)，只能字節(jié)，或者16位，32位這種，那么編譯器到底讀寫(xiě)用什么寬度? 這時(shí)基本大部分人都不知道了。

知其然知其所以然，尤其是嵌入式開(kāi)發(fā)和硬件結(jié)合比較緊密，所以一定要了解細(xì)節(jié)，我們這一篇從一個(gè)問(wèn)題引出然后去分析查找原因，只有遇到問(wèn)題然后去分析解決它才會(huì)有更深刻的映像。

二．問(wèn)題分析過(guò)程

問(wèn)題是驅(qū)動(dòng)程序中一個(gè)寄存器的某個(gè)位域修改，導(dǎo)致其他位域的值被修改了。

關(guān)鍵代碼如下，

1.typedefunionnfc_ena_union{

2. uint32_tw;

3. struct{

4. /*spienable,oncethespitransiscompleted,thisbitwillbeclearedbyHWautomaticlly*/

5. uint32_tnfc_ena:1; //[0]

6. uint32_treserved_0:3; //[1,3]

7. /*swrequesttousedp*/

8. uint32_tnfc_dp_req:1; //[4]

9. uint32_treserved_1:3; //[5,7]

10. /*duetodelayinreceivingdata,nfcdelayonebeattorx*/

11. uint32_tnfc_rx_delay_en:1; //[8]

12. uint32_treserved_2:7; //[9,15]

13. /*spitransdatalength,unitisbyte,oncethespitransiscompleted,thisbitwillbeclearedbyHWautomaticlly*/

14. uint32_tnfc_data_len:16; //[16,31]

15.}_b;

16.}nfc_ena_u;

1./**

2.*fnintnfc_set_datalen(uint8_tid,uint16_tlen)

3.*param[in]idportid

4.*param[in]lendatalen

5.*retval0ok

6.*retval<0?param?err

7.*

8.*/

9.NFC_INLINEintnfc_set_datalen(uint8_tid,uint16_tlen)

10.{

11. if(id>=HW_NFC_PORT_MAX)

12.{

13. return-1;

14.}

15.nfc_base[id]->nfc_ena._b.nfc_data_len=len;

16. return0;

17.}

執(zhí)行之前該寄存器值為0x00020100

nfc_base[id]->nfc_ena._b.nfc_data_len= len

匯編代碼被優(yōu)化為了寫(xiě)高16位

執(zhí)行完后寄存器低16位變?yōu)榱?

這是因?yàn)榧拇嫫饔布现恢С?2位的寫(xiě)操作，所以寫(xiě)高16位導(dǎo)致低16位清零了，這是硬件決定的。

二．驗(yàn)證

一般想到的就是優(yōu)化相關(guān)，加volatile等，我們分別驗(yàn)證下。

3.1不使能編譯器優(yōu)化

編譯器優(yōu)化選項(xiàng)改為”-O0”

代碼不變

依然會(huì)按照16位訪問(wèn)，導(dǎo)致低16位被清掉。

所以可以看到這個(gè)和編譯器行為有關(guān)，編譯器顯然不是根據(jù)優(yōu)化等級(jí)決定位域的操作寬度，這里而是根據(jù)位域的寬度剛好是16位對(duì)齊，所以優(yōu)化為了16位操作指令。

3.2使用volatile避免編譯器優(yōu)化

#ifndef__IOM

#define__IOM volatile

#endif

所有uint32_t替換為_(kāi)_IOM uint32_t

還是一樣的

顯然匯編代碼的訪問(wèn)寬度也不受volatile影響。

3.3為什么指定了uint32_t和volatile還會(huì)優(yōu)化。

問(wèn)題來(lái)了為什么告訴了編譯器是uint32_t和volatile，為什么其還要一意孤行，要優(yōu)化為16位訪問(wèn)指令呢，答案就是因?yàn)槭菢?biāo)準(zhǔn)沒(méi)有規(guī)定，這是編譯器實(shí)現(xiàn)行為決定的，所以編譯器設(shè)計(jì)者決定的(當(dāng)然也會(huì)有一些現(xiàn)實(shí)考慮的)，可能不同編譯器行為不同，這里以GCC為例。

GCC編譯器文檔中可以找到答案

GCC的文檔可以看到如下內(nèi)容，也給出了最好是不使用位域的原因

另外也介紹了位域哪些行為也是編譯器實(shí)現(xiàn)相關(guān)的，所以嵌入式可移植性考慮不要使用位域

那么有沒(méi)有辦法指定編譯按照一定大小訪問(wèn)呢，GCC有編譯選項(xiàng)可以控制見(jiàn)下一節(jié)。

3.4使用編譯器選項(xiàng)-fstrict-volatile-bitfields

可以看到改為了sw指令，按照32位進(jìn)行了操作

四.一些廠家做法

如下可見(jiàn)

4.1CMSIS

core_cmxx.h中定義

CMSIS中進(jìn)行了定義,寄存器個(gè)別使用位域

1./*IOdefinitions(accessrestrictionstoperipheralregisters)*/
2./**
3.defgroupCMSIS_glob_defsCMSISGlobalDefines
4.
5.IOTypeQualifiersareused
6.litospecifytheaccesstoperipheralvariables.
7.liforautomaticgenerationofperipheralregisterdebuginformation.
8.*/
9.#ifdef__cplusplus
10.#define__Ivolatile/*!

1./**
2.*@briefUniversalSerialBusFullSpeedDevice
3.*/
4.
5.typedefstruct
6.{
7.__IOuint16_tEP0R;/*!

1.#ifndef__IM/*!