對 51 單片機(jī)內(nèi)存的認(rèn)識，很多人有誤解，最常見的是以下兩種：

① 超過變量128后必須使用compact模式編譯

實(shí)際的情況是只要內(nèi)存占用量不超過 256.0 就可以用 small 模式編譯

② 128以上的某些地址為特殊寄存器使用，不能給程序用

與 PC 機(jī)不同，51 單片機(jī)不使用線性編址，特殊寄存器與 RAM 使用重復(fù)的重復(fù)的地址。但訪問時(shí)采用不同的指令，所以并不會占用 RAM 空間。

由于內(nèi)存比較小，一般要進(jìn)行內(nèi)存優(yōu)化，盡量提高內(nèi)存的使用效率。

以 Keil C 編譯器為例，small 模式下未指存儲類型的變量默認(rèn)為data型，即直接尋址，只能訪問低 128 個(gè)字節(jié)，但這 128 個(gè)字節(jié)也不是全為我們的程序所用，寄存器 R0-R7必須映射到低RAM，要占去 8 個(gè)字節(jié)，如果使用寄存組切換，占用的更多。

所以可以使用 data 區(qū)最大為 120 字節(jié)，超出 120 個(gè)字節(jié)則必須用 idata 顯式的指定為間接尋址，另外堆棧至少要占用一個(gè)字節(jié)，所以極限情況下可以定義的變量可占 247 個(gè)字節(jié)。當(dāng)然，實(shí)際應(yīng)用中堆棧為一個(gè)字節(jié)肯定是不夠用的，但如果嵌套調(diào)用層數(shù)不深，有十幾個(gè)字節(jié)也夠有了。

為了驗(yàn)上面的觀點(diǎn)，寫了個(gè)例子

#define LEN 120

data UCHAR tt1[LEN];

idata UCHAR tt2[127];

void main()

{

UCHAR i,j;

for(i = 0; i < LEN; ++i )

{

j = i;

tt1[j] = 0x55;

}

}

可以計(jì)算 R0-7(8) + tt1(120) + tt2(127) + SP(1) 總共 256 個(gè)字節(jié)

keil 編譯的結(jié)果如下：

Program Size: data=256.0 xdata=0 code=30

creating hex file from "./Debug/Test"...

"./Debug/Test" - 0 Error(s), 0 Warning(s).

(測試環(huán)境為 XP + Keil C 7.5)

這段代碼已經(jīng)達(dá)到了內(nèi)存分配的極限，再定義任何全局變量或?qū)?shù)組加大，編譯都會報(bào)錯(cuò) 107

這里要引出一個(gè)問題：為什么變量 i、j 不計(jì)算在內(nèi)?

這是因?yàn)?i、j 是局部變量，編譯器會試著將其優(yōu)化到寄存器 Rx 或棧。問題也就在這了，如果局部變量過多或定義了局部數(shù)組，編譯器無法將其優(yōu)化，就必須使用 RAM 空間，雖然全局變量的分配經(jīng)過精心計(jì)算沒有超出使用范圍，仍會產(chǎn)生內(nèi)存溢出的錯(cuò)誤!

而編譯器是否能成功的優(yōu)化變量是根據(jù)代碼來的

上面的代碼中，循環(huán)是臃腫的，變量 j 完全不必要，那么將代碼改成

UCHAR i;

UCHAR j;

for(i = 0; i < LEN; ++i )

{

tt1[i] = 0x55;

}

再編譯看看，出錯(cuò)了吧!

因?yàn)榫幾g器不知道該如何使用 j，所以沒能優(yōu)化，j 須占 RAM 空間，RAM 就溢出了。

(智能一點(diǎn)的編譯器會自動將這個(gè)無用的變量去掉，但這個(gè)不在討論之列了)

另外，對 idata 的定義的變量最好放在 data 變量之后

對于這一種定義

uchar c1;

idata uchar c2;

uchar c3;

變量 c2 肯定會以間接尋址，但它有可能落在 data 區(qū)域，就浪費(fèi)了一個(gè)可直接尋址的空間

變量優(yōu)化一般要注意幾點(diǎn):

①讓盡可能多的變量使用直接尋址，提高速度

假如有兩個(gè)單字節(jié)的變量，一個(gè)長119的字符型數(shù)組

因?yàn)榭傞L超過 120 字節(jié)，不可能都定義在 data 區(qū)

按這條原則，定義的方式如下:

data UCHAR tab[119];

data UCAHR c1;

idata UCHaR c2;

但也不是絕的，如果 c1, c2 需要以極高的頻率訪問，而 tab 訪問不那么頻繁

則應(yīng)該讓訪問量大的變量使用直接尋址：

data UCAHR c1;

data UCHaR c2;

idata UCHAR tab[119];

這個(gè)是要根據(jù)具體項(xiàng)目需求來確定的

②提高內(nèi)存的重復(fù)利用率

就是盡可能的利用局部變量，局部變量還有個(gè)好處是訪問速度比較快

由前面的例子可以看出，局部變量 i, j 是沒有單獨(dú)占用內(nèi)存的

子程序中使用內(nèi)存數(shù)目不大的變量盡量定義為局部變量

③對于指針數(shù)組的定義，盡可能指明存儲類型

盡量使用無符號類型變量

一般指針需要一個(gè)字節(jié)額外的字節(jié)指明存儲類型

8051 系列本身不支持符號數(shù)，需要外加庫來處理符號數(shù)，一是大大降低程序運(yùn)行效率，二是需要額外的內(nèi)存

④避免出現(xiàn)內(nèi)存空洞

可以通過查看編譯器輸出符號表文件(.M51)查看

對前面的代碼，M51文件中關(guān)于內(nèi)存一節(jié)如下：

* * * * * * * D A T A M E M O R Y * * * * * * *

REG 0000H 0008H ABSOLUTE "REG BANK 0"

DATA 0008H 0078H UNIT ?DT?TEST

IDATA 0080H 007FH UNIT ?ID?TEST

IDATA 00FFH 0001H UNIT ?STACK

第一行顯示寄存器組0從地址0000H開始，占用0008H個(gè)字節(jié)

第二行顯示DATA區(qū)變量從0008H開始，占用0078H個(gè)字節(jié)

第三行顯示IDATA區(qū)變量從0080H開始，占用007F個(gè)字節(jié)

第四行顯示堆棧從00FFH開始，占0001H個(gè)字節(jié)

由于前面代碼中變量定義比較簡單，且連續(xù)用完了所有空間，所以這里顯示比較簡單

變量定義較多時(shí)，這里會有很多行

如果全局變量與局部變量分配不合理，就有可能出現(xiàn)類似下面的行

0010H 0012H *** GAP ***

該行表示從0010H開始連續(xù)0012H個(gè)字節(jié)未充分利用或根本未用到

出現(xiàn)這種情況最常見的原因是局變量太多、多個(gè)子程序中的局部變量數(shù)目差異太大、使用了寄存器切換但未充分利用。

擴(kuò)展閱讀：EEPROM的幾種保護(hù)方法