三、STM32堆棧區

預備知識：

一個由C/C++編譯的程序占用的內存分為以下幾個部分：

l? 棧區（stack）：編譯器自動分配釋放，存放函數的參數值，局部變量的值等。操作方式類似于數據結構中的棧。

l? 堆區（heap）：一般由程序員分配釋放， 若程序員不釋放，程序結束時可能由OS回收。注意它與數據結構中的堆是兩回事，分配方式倒是類似于鏈表。

l? 全局區（靜態區）（static）：全局變量和靜態變量的存儲是放在一塊的，初始化的全局變量和靜態變量在一塊區域，未初始化的全局變量和未初始化的靜態變量在相鄰的另 一塊區域。程序結束后由系統釋放。

l? 文字常量區 —常量字符串就是放在這里的。 程序結束后由系統釋放

l? 程序代碼區—存放函數體的二進制代碼

編譯后，各個區存儲內容舉例說明如下：

//main.cpp

int a = 0; 全局初始化區

char *p1; 全局未初始化區

main()

{

int b; 棧

char s[] = “abc”;棧

char *p2; 棧

char *p3 = “123456”;123456\0在常量區，p3在棧上

static int c =0； 全局（靜態）初始化區

p1 = (char *)malloc(10);

p2 = (char *)malloc(20);

分配得來得10和20字節的區域就在堆區。

strcpy(p1, "123456"); 123456\0放在常量區，編譯器可能會將它與p3所指向的"123456"

優化成一個地方。

}

STM32的分區

STM32的分區從0x2000 0000（0x2000 0000是SRAM的起始地址，由此可知，堆棧等都是在RAM中的）開始。靜態區，堆，棧。所有的全局變量，包括靜態變量之類的，全部存儲在靜態存儲區。?緊跟靜態存儲區之后的，是堆區（如沒用到malloc，則沒有該區），之后是棧區，棧在程序中存儲局部變量。

?

先看啟動文件startup_stm32f10x_md.s的定義：

;Amount of memory (in bytes) allocated for Stack?
; Tailor this value to your application needs?
; <h> Stack Configuration?
; <o> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8>?
; </h>

Stack_SizeEQU 0x00000400

AREASTACK, NOINIT, READWRITE, ALIGN=3?
Stack_Mem SPACE Stack_Size?
__initial_sp

; <h> Heap Configuration?
; <o> Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>?
; </h>

Heap_SizeEQU 0x00000200

AREAHEAP, NOINIT, READWRITE, ALIGN=3?
__heap_base?
Heap_Mem SPACE Heap_Size?
__heap_limit

這里定義了堆棧各自大小，堆：512bytes 棧1k；

所以棧區大小有限制，我們在局部變量中不要定義大數組否則容易溢出。

再看下code ro rw zi

l? Code指存儲到flash【Rom】中的程序代碼。

l? ZI英語是zero initial，就是程序中用到的變量并且被系統初始化為0的變量的字節數，keil編譯器默認是把你沒有初始化的變量都賦值一個0，這些變量在程序運行時是保存在RAM中的。

l? RW是可讀可寫變量，就是初始化時候就已經賦值了的，RW + ZI就是你的程序總共使用的RAM字節數。

l? RO是程序中的指令和常量，這些值是被保存到Rom中的。

l? Total ROM Size (Code +RO Data + RW Data)這樣所寫的程序占用的ROM的字節總數，也就是說程序所下載到ROM flash 中的大小。為什么Rom中還要存RW，因為掉電后RAM中所有數據都丟失了，每次上電RAM中的數據是被重新賦值的，每次這些固定的值就是存儲在Rom中的，為什么不包含ZI段呢，是因為ZI數據都是0，沒必要包含，只要程序運行之前將ZI數據所在的區域一律清零即可。包含進去反而浪費存儲空間。?

?????????實際上，ROM中的指令至少應該有這樣的功能：?
? ? ? ? ?1. 將RW從ROM中搬到RAM中，因為RW是變量，變量不能存在ROM中。?
? ? ? ? ?2. 將ZI所在的RAM區域全部清零，因為ZI區域并不在Image中，所以需要程序根據編譯器給出的ZI地址及大小來將相應得RAM區域清零。ZI中也是變量，同理：變量不能存在ROM中。?

?

1,首先來看:棧(STACK)的問題.

函數的局部變量，都是存放在“棧”里面，棧的英文是：STACK。STACK的大小，我們可以在stm32的啟動文件里面設置，在startup_stm32f10x_hd.s里面，開頭就有：

Stack_Size?????EQU???? 0x00000800

表示棧大小是0X800，也就是2048字節，這樣，CPU處理任務的時候，函數局部變量過多可占用的大小就是：2048字節。注意：是所有在處理的函數，包括函數嵌套，遞歸，等等，都是從這個“棧”里面，來分配的。

所以，如果一個函數的局部變量過多，比如在函數里面定義一個u8 buf[512]，這一下就占了1/4的棧大小了，再在其他函數里面來搞兩下，程序崩潰是很容易的事情，這時候,一般你會進入到hardfault....
這是初學者非常容易犯的一個錯誤.切記不要在函數里面放N多局部變量,尤其有大數組的時候!

對于棧區，一般棧頂，也就是MSP，在程序剛運行的時候，指向程序所占用內存的最高地址。比如附件里面的這個程序序，內存占用如下圖：

圖中，我們可以看到,程序總共占用內存：20+2348字節=2368=0X940
那么程序剛開始運行的時候：MSP=0X20000000+0X940=0X2000 0940.
事實上，也是如此，如圖：

圖中，MSP就是：0X2000 0940，程序運行后，MSP就是從這個地址開始，往下給函數的局部變量分配地址。再說說棧的增長方向，我們可以用如下代碼測試：

//保存棧增長方向

//0，向下增長；1，向上增長

static u8 stack_dir;

//查找棧增長方向，結果保存在stack_dir里面

void find_stack_direction(void)

{
??? static u8 *addr=NULL;?? //用于存放第一個dummy的地址。
??? u8dummy;????????????????? //用于獲取棧地址?
??? if(addr==NULL)? ?????? //第一次進入
???{??????????????????????????
??????? addr=&dummy;?????? //保存dummy的地址
??????? find_stack_direction ();?//遞歸?
??? }

else???????????????//第二次進入?
? {??
???????if(&dummy>addr)stack_dir=1; //第二次dummy的地址大于第一次dummy,那么說明棧增長方向是向上的.?
??????? elsestack_dir=0;?????????? //第二次dummy的地址小于第一次dummy,那么說明棧增長方向是向下的.??
?}
}?

這個代碼不是我寫的，網上抄來的，思路很巧妙，利用遞歸，判斷兩次分配給dummy的地址，來比較棧是向下生長，還是向上生長。如果你在STM32測試這個函數，你會發現， STM32的棧，是向下生長的。事實上，一般CPU的棧增長方向，都是向下的。

2,再來說說,堆(HEAP)的問題.

全局變量，靜態變量，以及內存管理所用的內存，都是屬于“堆"區”，英文名：“HEAP”，與棧區不同，堆區，則從內存區域的起始地址開始分配給各個全局變量和靜態變量。

堆的生長方向，都是向上的。在程序里面，所有的內存分為：堆+棧，只是他們各自的起始地址和增長方向不同，他們沒有一個固定的界限，所以一旦堆棧沖突，系統就到了崩潰的時候了。同樣，我們用附件里面的例程測試：

stack_dir的地址是0X2000 0004，也就是STM32的內存起始端的地址。

這里本來應該是從0X2000 0000開始分配的，但是，我仿真發現0X2000 0000總是存放：0X2000 0398，這個值，貌似是MSP，但是又不變化，還請高手幫忙解釋下。其他的，全局變量，則依次遞增，地址肯定大于0X20000004，比如cpu_endian的地址就是0X20000005。這就是STM32內部堆的分配規則.

3,再說說,大小端的問題.
大端模式：低位字節存在高地址上，高位字節存在低地址上?
小端模式：高位字節存在高地址上，低位字節存在低地址上

STM32屬于小端模式,簡單的說,比如u32temp=0X12345678;
假設temp地址在0X2000 0010.
那么在內存里面,存放就變成了:
地址?????????????|???????????HEX?????????|
0X2000 0010??|??78?? 56?? 43?12? |

CPU到底是大端還是小端,可以通過如下代碼測試:
//CPU大小端
//0,小端模式;1,大端模式.
static u8 cpu_endian;

//獲取CPU大小端模式,結果保存在cpu_endian里面
void find_cpu_endian(void)
{?
?int x=1;
?if(*(char*)&x==1)cpu_endian=0;?//小端模式?
?else cpu_endian=1;????//大端模式??
}
以上測試,在STM32上,你會得到cpu_endian=0,也就是小端模式.


3,最后說說,STM32內存的問題.
??? 還是以附件工程為例，在前面第一個圖，程序總共占用內存:20+2348字節,這么多內存,到底是怎么得來的呢?

我們可以雙擊Project側邊欄的:Targt1,會彈出test.map,在這個里面,我們就可以清楚的知道這些內存到底是怎么來的了.在這個test.map最后,Image 部分有:
==============================================================================

Image component sizes

?Code (inc. data)?? ROData??? RW Data??? ZIData????? Debug?? Object Name

??????172????????10????????? ???0????????? ????4????????????0???????995?? delay.o//delay.c里面,fac_us和fac_ms,共占用4字節
??????112????????12?????????0?????????0?????????0??????? ??427?? led.o
????????72?????????26???????304?????????0??????2048??????? 828??startup_stm32f10x_hd.o? //啟動文件,里面定義了Stack_Size為0X800,所以這里是2048.
??????712????????52?????????0?????????0?????????0?????? 2715?? sys.o
???????348???????154?????????0?????????6?????????0???? 208720?? test.o//test.c里面,stack_dir和cpu_endian?以及*addr??,占用6字節.
???????384????????24?????????0?????????8??????? 200??????3050?? usart.o//usart.c定義了一個串口接收數組buffer,占用200字節.

???----------------------------------------------------------------------
??????1800???????278???????336????????20?????? 2248????216735?? Object Totals //總共2248+20字節
????????0?????????0???????? 32?????????0?????????0????????? 0?? (incl.Generated)
????????0?????????0?????????0?????????2????????? 0?????????0?? (incl. Padding)//2字節用于對其

???----------------------------------------------------------------------

????? Code (inc. data)?? RO Data???RW Data??? ZI Data?????Debug?? Library Member Name

????????8?????????0?????????0?????????0?????????0???????? 68?? __main.o
??????104?????????0?????????0?????????0?????????0???????? 84?? __printf.o
???????52?????????8?????????0????????? 0?????????0????????? 0??__scatter.o
???????26?????????0?????????0?????????0?????????0????????? 0??__scatter_copy.o
???????28?????????0?????????0?????????0?????????0????????? 0??__scatter_zi.o
???????48?????????6?????????0?????????0?????????0???????? 96??_printf_char_common.o
???????36?????????4?????????0?????????0?????????0???????? 80??_printf_char_file.o
???????92?????????4????????40?????????0?????????0???????? 88??_printf_hex_int.o
??????184?????????0?????????0????????? 0?????????0???????? 88??_printf_intcommon.o
????????0?????????0?????????0?????????0?????????0????????? 0??_printf_percent.o
????????4?????????0?????????0?????????0?????????0????????? 0??_printf_percent_end.o
????????6?????????0?????????0?????????0?????????0????????? 0??_printf_x.o
???????12?????????0?????????0?????????0?????????0???????? 72?? exit.o
????????8?????????0?????????0?????????0?????????0???????? 68?? ferror.o
????????6?????????0?????????0?????????0?????????0??????? 152?? heapauxi.o
????????2?????????0?????????0?????????0?????????0????????? 0?? libinit.o
????????2?????????0?????????0?????????0?????????0????????? 0??libinit2.o
????????2????????? 0?????????0?????????0?????????0????????? 0??libshutdown.o
????????2?????????0?????????0?????????0?????????0????????? 0??libshutdown2.o
?????????8?????????4?????????0?????????0????????96???????? 68??libspace.o????????? //庫文件(printf使用),占用了96字節
???????24?????????4?????????0?????????0?????????0???????? 84??noretval__2printf.o
????????0?????????0?????????0?????????0?????????0????????? 0?? rtentry.o
???????12?????????0?????????0?????????0?????????0????????? 0??rtentry2.o
???????? 6?????????0?????????0?????????0?????????0????????? 0??rtentry4.o
????????2?????????0?????????0?????????0?????????0????????? 0?? rtexit.o
???????10?????????0?????????0?????????0?????????0????????? 0?? rtexit2.o
???????74?????????0????????? 0?????????0?????????0???????? 80??sys_stackheap_outer.o
????????2?????????0?????????0?????????0?????????0???????? 68?? use_no_semi.o
????????2?????????0?????????0?????????0?????????0???????? 68??use_no_semi_2.o
??????450?????????8????????? 0?????????0?????????0??????? 236?? faddsub_clz.o
??????388????????76?????????0?????????0?????????0???????? 96?? fdiv.o
???????62?????????4?????????0?????????0?????????0???????? 84?? ffixu.o
???????38?????????0?????????0?????????0????????? 0????????68?? fflt_clz.o
??????258?????????4?????????0?????????0?????????0???????? 84?? fmul.o
??????140?????????4?????????0?????????0?????????0???????? 84?? fnaninf.o
???????10?????????0?????????0?????????0?????????0???????? 68?? fretinf.o
????????0?????????0?????????0?????????0?????????0????????? 0?? usenofp.o

???----------------------------------------------------------------------
?????2118???????126????????42?????????0??????? 100??????1884?? Library Totals? //調用的庫用了100字節.
???????10?????????0?????????2?????????0?????????4????????? 0?? (incl.Padding)?? //用于對其多占用了4個字節

???----------------------------------------------------------------------

????? Code (inc. data)?? ROData??? RW Data??? ZIData????? Debug?? Library Name

??????762????????30????????40?????????0???????? 96??????1164?? c_w.l
?????1346????????96?????????0?????????0????????? 0???????720?? fz_ws.l

???----------------------------------------------------------------------
?????2118???????126???????? 42?????????0???????100?????? 1884?? Library Totals

???----------------------------------------------------------------------

==============================================================================

????? Code (inc.data)?? RO Data??? RW Data??? ZIData????? Debug??

?????3918???????404???????378????????20?????? 2348???? 217111??Grand Totals
?????3918???????404???????378????????20?????? 2348???? 217111??ELF Image Totals
?????3918???????404???????378????????20????????? 0?????????0?? ROM Totals

==============================================================================

??? Total RO? Size (Code + ROData)????????????????4296 (?? 4.20kB)
????Total RW? Size (RW Data + ZIData)?????????????2368 (?? 2.31kB)?? //總共占用:2248+20+100=2368.
??? Total ROM Size (Code + RO Data + RWData)?????? 4316 (?? 4.21kB)

==============================================================================

通過這個文件,我們就可以分析整個內存,是怎么被占用的,具體到每個文件,占用多少.一目了然了.

總結

以上是生活随笔為你收集整理的STM32堆栈区的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。