先談?wù)勅肿兞康奶攸c(diǎn)

全局變量（Global Variables）：在計(jì)算機(jī)編程語言中，所謂全局變量是指具有全局作用域的變量，這意味著它在整個(gè)程序中是可見的，因此是可訪問的。所謂可訪問，是指全局可讀、全局可寫。在編譯語言中，全局變量通常是靜態(tài)變量，其范圍(生命周期)是程序的整個(gè)運(yùn)行時(shí)。當(dāng)然解釋性語言除外，解釋性語言包括命令行解釋器（比如python, Java script,shell等）中，全局變量通常在聲明時(shí)由解釋器動(dòng)態(tài)分配，這是由于解釋性語言是讀取>解釋>執(zhí)行模式，不像編譯性語言，運(yùn)行前可預(yù)知變量屬性，解釋性語言讀取解釋前無從獲取變量屬性。

在C/C++編程語言中，全局變量的這種全局可見性特點(diǎn)，濫用全局變量會(huì)讓代碼表現(xiàn)當(dāng)相當(dāng)邪惡！如果使用全局變量，就意味著下面這些場(chǎng)景的存在：

• 實(shí)際代碼可能有很多地方在讀、在寫全局變量
• 全局變量在多線程或多任務(wù)間共享
• 全局變量在常規(guī)代碼和中斷服務(wù)程序間共享

為啥說全局變量很邪惡？

單片機(jī)裸機(jī)編程

或許你會(huì)說，我就這樣用？咋了？軟件也跑的很好?。縼砜纯催@個(gè)場(chǎng)景：

一個(gè)超字寬的變量（比如16位單片機(jī)，字寬即為16位），正被一個(gè)常規(guī)代碼在寫變量數(shù)據(jù)域時(shí)且還沒寫完，啪嘰，來了個(gè)中斷！中斷一來，CPU趕緊把手里的活兒停下來，奔過去處理中斷了，不巧在中斷函數(shù)里，該變量因業(yè)務(wù)需求有需要寫這個(gè)變量有經(jīng)驗(yàn)的不這么寫，僅為了方便說明：

舉個(gè)栗子,還是以之前文章的傳感器為例，實(shí)際應(yīng)用中傳感器可能是下面這樣的數(shù)據(jù)結(jié)構(gòu)來描述：

#ifndef?_SENSOR_H_
#define?_SENSOR_H_
typedef?struct?_t_sensor{
???/*?測(cè)量值與測(cè)量范圍及單位有關(guān)?*/
???float?value;
???
???/*?測(cè)量范圍，根據(jù)采樣值映射??*/
???float?upper_range;
???float?lower_range;
???/*?溫度單位?*/
???unsiged char unit;
}T_SENSOR;
/*假定是一個(gè)溫度測(cè)量產(chǎn)品*/
extern?T_SENSOR?temperature;

#endif?_SENSOR_H_

假定這個(gè)傳感器數(shù)據(jù)結(jié)構(gòu)有這樣一些被訪問的可能：

1. 上位機(jī)會(huì)改寫測(cè)量數(shù)據(jù)的范圍及單位，串口通信中斷服務(wù)程序直接寫這個(gè)全局變量中的上下限數(shù)據(jù)域
2. LCD操作界面可改寫溫度上下限范圍。
3. 測(cè)量更新模塊根據(jù)當(dāng)前范圍及單位配置，將傳感器采集到的數(shù)據(jù)映射為測(cè)量值。

這些需求用例，用圖描述一下：

比如用戶操作HMI界面正改寫溫度范圍，而此時(shí)遠(yuǎn)程上位機(jī)也正改寫溫度范圍，按上面這個(gè)做法，可能出現(xiàn)哪些邪惡的后果呢?

1. 通過LCD界面寫入上限為300.5（假定原下限為0），此時(shí)遠(yuǎn)程串口報(bào)文收到，程序直接在中斷服務(wù)程序?qū)⒎秶薷臑椋?100，200.5），此時(shí)中斷返回，用戶可能接著修改下限為-200，則最終設(shè)備內(nèi)的溫度范圍可能既不是（-100，200.5）也不是（-200，300.5），而可能是（-200，200.5）。這是一個(gè)易理解的數(shù)據(jù)混亂的場(chǎng)景。
2. 現(xiàn)實(shí)中如果使用的單片機(jī)是8位/16位單片機(jī)，一條指令無法完成操作一個(gè)32位立即數(shù)，有可能才完成一個(gè)浮點(diǎn)數(shù)中某幾個(gè)字節(jié)，此時(shí)就被中斷打斷寫入200，然后中斷返回后繼續(xù)寫入剩下字節(jié)，數(shù)據(jù)可能會(huì)變得非常詭異！利用http://www.speedfly.cn/tools/hexconvert/ 在線工具轉(zhuǎn)換浮點(diǎn)數(shù)到16進(jìn)制：

0x43964000?/*?浮點(diǎn)數(shù)300.5的16進(jìn)制*/
0x43488000?/*?浮點(diǎn)數(shù)200.5的16進(jìn)制*/

假定中斷進(jìn)入時(shí)，HMI界面程序?qū)懭肓?x4396前兩個(gè)字節(jié)，中斷返回時(shí)，上限改寫為200.5(0x43488000),此時(shí)繼續(xù)執(zhí)行后面兩個(gè)字節(jié)寫入，則上限變成為(0x43484000),來看看這個(gè)數(shù)是多大？變成了200.25，這是不是很邪惡？

或許有的朋友會(huì)說，可以在LCD寫范圍時(shí)關(guān)中斷嘛。誠然，可以這么做：

void?hmi_operate()
{
????/*關(guān)中斷*/
????_disable_interrupt();
????/*改寫溫度范圍*/
????....
????/*開中斷*/
????_enable_interrupt();
}

但是如果這個(gè)全局變量有很多地方在改寫，為了數(shù)據(jù)安全，勢(shì)必就到處開/關(guān)中斷，這樣做的壞處：

• 經(jīng)常開關(guān)中斷，勢(shì)必影響中斷響應(yīng)，會(huì)有概率丟失異步中斷處理(比如串口按字節(jié)接收中斷，可能就會(huì)漏收字節(jié))，程序不健壯，工作不穩(wěn)定。
• 到處訪問改寫，不易調(diào)試，群魔亂舞，代碼也不易維護(hù)。想加點(diǎn)東西，改點(diǎn)東西可能隨處都是坑，一不小心就掉坑里去了！
• 初學(xué)者甚至不會(huì)用struct將相關(guān)的數(shù)據(jù)包在一起，其結(jié)果是代碼里到處都是基本類型的全局變量。一些簡單的業(yè)務(wù)邏輯實(shí)現(xiàn)變成一個(gè)復(fù)雜的代碼，數(shù)據(jù)信息流向一團(tuán)亂麻。

裸機(jī)程序策略

對(duì)于上面這樣一個(gè)應(yīng)用場(chǎng)景，怎么解決這種混亂的現(xiàn)象呢。這里分享一下我的思路，這里將主要的串口以及測(cè)量模塊的設(shè)計(jì)思路用UML圖描述一下大體思路：

如此一來，外部就看不到全局變量了，只需要調(diào)用對(duì)應(yīng)的set/get方法即可實(shí)現(xiàn)讀寫訪問，由于是裸機(jī)前后臺(tái)程序，數(shù)據(jù)流向就變的非常清晰了。main函數(shù)的主循環(huán)大致就可能是這樣：

void?main(void)
{
???/*模塊初始化*/
???init_uart();
???init_temperature();
???....
???
???while(1)
???{
???????interprete_uart();
???????/*可能是周期性調(diào)用*/
???????if(timer_100ms)
???????{
??????????timer_100ms?=?0;
??????????update_temperature();
???????}????????
?????????
???????....
???}???
}

那么uart協(xié)議解析要怎么做呢？

void?interprete_uart(void)
{
????if(rx_msg.flag)
????{
????????rx_msg.flag?=?false;
????????/*報(bào)文完整性檢查*/
????????...
????????????
????????/*設(shè)置溫度配置*/
????????set_upper_range(xxx);
????????set_lower_range(xxx);
????????set_unit(xxx);
????}
????
????if(tx_msg.flag)
????{
????????tx_msg.flag?=?false;
????????start_send();
????}
}

static?start_send(T_UART_MSG?*pMsg)
{
????/*負(fù)責(zé)底層操作，啟動(dòng)中斷傳輸*/
}

/*提供應(yīng)答數(shù)據(jù)接口*/
void?reply_temperature_setting(T_SENSOR?sensor)
{
????/*解析傳入?yún)?shù)并封裝應(yīng)答報(bào)文*/
}

如此一來，數(shù)據(jù)流向?qū)⒆兊煤芮逦诮邮盏綌?shù)據(jù)更新范圍配置時(shí)，也無需開關(guān)中斷了，從應(yīng)用角度幾乎見不到全局變量。當(dāng)然這樣做的代價(jià)就是會(huì)增加一些棧開銷。但是這種代價(jià)還是值得的。

對(duì)于測(cè)量模塊的set函數(shù)思路稍做說明：

int?set_upper_range(float?range)
{
????T_SENSOR?temp?=?temperature;
????temp.upper_range?=?range;
????/*實(shí)現(xiàn)范圍合理性檢查*/
????if(check_range(temp))
????{
????????/*兩個(gè)結(jié)構(gòu)體變量可以直接賦值*/
????????temperature?=?temp;
????????return?0;
????}
????else
????{
???????return?-1;
????}
}

int?set_unit(E_UNIT?unit)
{
????if(unit>E_UNIT_F)
????????return?-1;
????adjust_range(&temperature,unit);
????temperature.unit?=?unit;????
}

上述代碼旨在分享個(gè)人的一些思路，其中或有不夠嚴(yán)謹(jǐn)?shù)牡胤?，但通過這樣的設(shè)計(jì)思路，應(yīng)能大幅度遠(yuǎn)離滿天飛的全局變量。

多任務(wù)/多線程環(huán)境

上面描述其實(shí)本質(zhì)上描述了裸機(jī)程序里，普通模式運(yùn)行程序與中斷服務(wù)程序?qū)τ谂R界資源的競(jìng)爭(zhēng)。事實(shí)上現(xiàn)在不管是單片機(jī)，還是處理器，大多都是基于一個(gè)操作系統(tǒng)進(jìn)行應(yīng)用開發(fā)。甚至還可能是多核芯片，這里就存在并發(fā)競(jìng)爭(zhēng)訪問資源的問題。

臨界資源：各任務(wù)/線程采取互斥的方式，實(shí)現(xiàn)共享的資源稱作臨界資源。屬于臨界資源的硬件串口打印、顯示等,軟件有消息緩沖隊(duì)列、變量、數(shù)組、緩沖區(qū)等。多任務(wù)/線程間應(yīng)采取互斥方式，從而實(shí)現(xiàn)對(duì)這種資源的共享。

多任務(wù)/多線程情況下在寫模塊時(shí)，只需要封裝進(jìn)保護(hù)機(jī)制即可。常見的保護(hù)機(jī)制有關(guān)中斷、信號(hào)量、互斥鎖等。在Linux內(nèi)核中為應(yīng)對(duì)多核并發(fā)訪問還有自旋鎖機(jī)制。由于篇幅所限，本文就不做展開了，先挖個(gè)坑，以后有機(jī)會(huì)再分享吧。

總結(jié)一下

在前文介紹static文章的基礎(chǔ)上，相對(duì)更深入的介紹了為何需要隱藏屬性以及開放接口的做法。以及如何遠(yuǎn)離邪惡的全局變量漫天飛舞的不良設(shè)計(jì)風(fēng)格。

猜你喜歡

干貨 | 嵌入式必備技能之Git的使用

CPU中的程序是怎么運(yùn)行起來的

嵌入式系統(tǒng)軟件架構(gòu)設(shè)計(jì)

Linux下應(yīng)用開發(fā)基礎(chǔ)

【Linux筆記】Pinctrl子系統(tǒng)與GPIO子系統(tǒng)