基于RTOS的應用中，每個任務都擁有自己的堆?？臻g。堆棧設置過大，會造成內存資源浪費；設置過小，可能導致運行過程中的任務棧溢出，從而導致一些奇怪的系統行為。

事實上，當應用程序行為“奇怪”時，我們首先想到的就是堆棧大小不足。

但任務所需的堆棧大小與具體應用相關，如何確定任務堆棧的大?。?/p>

通過分析任務實現，我們可以通過手動計算的方法獲取任務所需的堆棧空間：

1.所有函數嵌套調用所需的內存

對于每個層級的函數調用：

根據CPU架構，存儲一個指向函數調用返回地址的指針。一些CPU實際上將函數返回地址保存在特殊寄存器中（通常稱為鏈接寄存器LR）。但如果該函數嵌套調用其它函數，則調用者必須保存鏈接寄存器的內容，因此，計算時我們假設指針也被壓入堆棧。

函數調用時，傳遞參數所需的內存。參數通常使用寄存器傳遞，但同樣，如果一個函數調用其它函數，寄存器內容需要保存到堆棧中。因此，假設使用堆棧傳遞所有參數以確定任務堆棧的大小。

存儲函數的局部變量所需內存空間。

用于函數運行過程中內部狀態(tài)保存所需的堆?？臻g。

2.完整的CPU上下文存儲空間，上下文通常指CPU的寄存器現場，如果需要FPU功能，還需保存相應的FPU寄存器

3.中斷處理現場保存。如果沒有獨立的中斷堆棧，還需在任務堆棧中為每個可能嵌套的ISR增加存儲CPU上下文的空間，以及ISR中的局部變量所需的堆棧空間。

將所有這些信息加起來是一件繁瑣的工作，而得到的數字僅是堆棧的最低需求。計算是假定已知代碼的確切路徑，但有時并不可能。例如調用printf()函數時，很難猜測printf()需要多少堆?？臻g。為了應用安全，我們還需要在計算值的基礎上，乘以一些安全系數，如1.5到2.0。推算出任務堆棧值后，我們可以通過調試手段進一步優(yōu)化設置。

許多IDE的調試器都提供了內核感知插件，該插件允許用戶查看某些內核數據結構如任務的狀態(tài)，如圖1所示，IAR提供了FreeRTOS感知插件。通過IDE的內核感知插件，應用停止運行時，可以查看當前任務堆棧使用情況，基于插件提供的信息調整任務堆棧設置，但只能獲得某個瞬間的快照。

圖1IDE提供的內核感知功能

為了實時監(jiān)控任務堆棧使用，優(yōu)化堆棧設置，我們還可以借助RTOS的可視化分析工具，如Tracealyzer，在運行時監(jiān)控堆棧使用情況。通過堆棧使用視圖顯示隨時間的變化，每個任務使用或未使用的堆棧數量，從而調整任務堆棧設置，優(yōu)化內存使用。

圖2Tracealyzer的堆棧使用捕獲

一般來說，任務堆?？梢詮囊粋€比較大的堆棧空間開始，在運行時監(jiān)視堆?？臻g的使用情況，以查看應用程序運行一段時間后實際使用了多少堆?？臻g?；诳梢暬治?，用戶可以更清晰直觀的掌握系統中內存的使用情況，進而開發(fā)出更高質量的代碼。

審核編輯 ：李倩