棧增長和大端/小端問題是和CPU相關(guān)的兩個問題.

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

函數(shù)的局部變量,都是存放在"棧"里面,棧的英文是:STACK.STACK的大小,我們可以在stm32的啟動文件里面設(shè)置,以戰(zhàn)艦stm32開發(fā)板為例,在startup_stm32f10x_hd.s里面,開頭就有:

Stack_Size EQU 0x00000800

表示棧大小是0X800,也就是2048字節(jié).這樣,CPU處理任務(wù)的時候,函數(shù)局部變量做多可占用的大小就是:2048字節(jié),注意:是所有在處理的函數(shù),包括函數(shù)嵌套,遞歸,等等,都是從這個"棧"里面,來分配的.
所以,如果一個函數(shù)的局部變量過多,比如在函數(shù)里面定義一個u8 buf[512],這一下就占了1/4的棧大小了,再在其他函數(shù)里面來搞兩下,程序崩潰是很容易的事情,這時候,一般你會進入到hardfault....
這是初學(xué)者非常容易犯的一個錯誤.切記不要在函數(shù)里面放N多局部變量,尤其有大數(shù)組的時候!

對于棧區(qū),一般棧頂,也就是MSP,在程序剛運行的時候,指向程序所占用內(nèi)存的最高地址.比如附件里面的這個程序序,內(nèi)存占用如下圖:

圖中,我們可以看到,程序總共占用內(nèi)存:20+2348字節(jié)=2368=0X940
那么程序剛開始運行的時候:MSP=0X2000 0000+0X940=0X2000 0940.
事實上,也是如此,如圖:

圖中,MSP就是:0X2000 0940.
程序運行后,MSP就是從這個地址開始,往下給函數(shù)的局部變量分配地址.

再說說棧的增長方向,我們可以用如下代碼測試:

//保存棧增長方向
//0,向下增長;1,向上增長.
static u8 stack_dir;

//查找棧增長方向,結(jié)果保存在stack_dir里面.
void find_stack_direction(void)
{
static u8 *addr=NULL;//用于存放第一個dummy的地址。
u8 dummy; //用于獲取棧地址
if(addr==NULL) //第一次進入
{
addr=&dummy; //保存dummy的地址
find_stack_direction (); //遞歸
}else //第二次進入
{
if(&dummy>addr)stack_dir=1; //第二次dummy的地址大于第一次dummy,那么說明棧增長方向是向上的.
else stack_dir=0; //第二次dummy的地址小于第一次dummy,那么說明棧增長方向是向下的.
}
}

這個代碼不是我寫的,網(wǎng)上抄來的,思路很巧妙,利用遞歸,判斷兩次分配給dummy的地址,來比較棧是向下生長,還是向上生長.
如果你在STM32測試這個函數(shù),你會發(fā)現(xiàn),STM32的棧,是向下生長的.事實上,一般CPU的棧增長方向,都是向下的.

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

全局變量,靜態(tài)變量,以及內(nèi)存管理所用的內(nèi)存,都是屬于"堆"區(qū),英文名:"HEAP"
與棧區(qū)不同,堆區(qū),則從內(nèi)存區(qū)域的起始地址,開始分配給各個全局變量和靜態(tài)變量.
堆的生長方向,都是向上的.在程序里面,所有的內(nèi)存分為:堆+棧. 只是他們各自的起始地址和增長方向不同,他們沒有一個固定的界限,所以一旦堆棧沖突,系統(tǒng)就到了崩潰的時候了.
同樣,我們用附件里面的例程測試:

stack_dir的地址是0X20000004,也就是STM32的內(nèi)存起始端的地址.
這里本來應(yīng)該是從0X2000 0000開始分配的,但是,我仿真發(fā)現(xiàn)0X2000 0000總是存放:0X2000 0398,這個值,貌似是MSP,但是又不變化,還請高手幫忙解釋下.
其他的,全局變量,則依次遞增,地址肯定大于0X20000004,比如cpu_endian的地址就是0X20000005.
這就是STM32內(nèi)部堆的分配規(guī)則.

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

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

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

//獲取CPU大小端模式,結(jié)果保存在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內(nèi)存的問題.
還是以附件工程為例,在前面第一個圖,程序總共占用內(nèi)存:20+2348字節(jié),這么多內(nèi)存,到底是怎么得來的呢?
我們可以雙擊Project側(cè)邊欄的:Targt1,會彈出test.map,在這個里面,我們就可以清楚的知道這些內(nèi)存到底是怎么來的了.在這個test.map最后,Image 部分有:
==============================================================================

Image component sizes

Code (inc. data) RO Data RW Data ZI Data Debug Object Name

172 10 0 4 0 995 delay.o//delay.c里面,fac_us和fac_ms,共占用4字節(jié)
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字節(jié).
384 24 0 8 200 3050 usart.o//usart.c定義了一個串口接收數(shù)組buffer,占用200字節(jié).

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

----------------------------------------------------------------------

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字節(jié)
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