STM32CubeMX FreeRTOS堆棧分配、調(diào)試技巧
免責(zé)聲明：本文素材來源網(wǎng)絡(luò)，版權(quán)歸原作者所有。如涉及作品版權(quán)問題，請與我聯(lián)系刪除。
堆?？臻g分配
這部分很重要，如果選擇的單片機RAM比較吃緊，那就要精打細算了。
這個問題牽連了不少容易混淆的概念，我在學(xué)習(xí)的時候也翻了很多帖子，按照自己的理解梳理了一下，有錯誤請評論區(qū)或私信指出。
參考博客：
https://www.cnblogs.com/CaesarTao/p/9816965.html
先是RAM，我選用的是stm32f103RBT6，有20K的RAM。
這20K被分為4大部分：
其中 “內(nèi)部用，中斷向量等” 這塊是系統(tǒng)固定的，我們不需要管。
其中的HEAP和STACK，他們跟FreeRTOS里的堆和棧沒有關(guān)系。
為了避免弄混，我們把這里的HEAP稱為系統(tǒng)堆，把這里的STACK稱為系統(tǒng)棧
在裸機編程中：
| 成分 | 描述 |
|---|---|
| 系統(tǒng)堆HEAP | 當(dāng)我們使用malloc函數(shù)申請內(nèi)存時，就是從這里申請的，它必須由程序員提前定義好大小，如果空間不足，malloc會申請失敗。目前我了解到的，它就這一個作用。 |
| 系統(tǒng)棧STACK | 用來存儲臨時變量、函數(shù)的參數(shù)等等，當(dāng)我們進行函數(shù)嵌套時，進入函數(shù)前，是要進行保存現(xiàn)場的工作的，等執(zhí)行完函數(shù)跳回到原來位置時，需要恢復(fù)現(xiàn)場，而保存現(xiàn)場所使用的內(nèi)存，就是從系統(tǒng)棧中獲取的，如果系統(tǒng)棧不足，就會出現(xiàn)常說的棧溢出，導(dǎo)致程序跑飛。與系統(tǒng)堆不同的是，系統(tǒng)?？梢圆惶崆耙?guī)定大小，不影響程序運行。 |
| 全局區(qū) | 用來存儲全局變量、靜態(tài)變量 |
在stm32工程的啟動文件中，堆系統(tǒng)堆和系統(tǒng)棧定義了大小：
Stack_Size默認為0x400 1024byte
Heap_Size默認為0x200 512byte
對于系統(tǒng)堆Heap，如果你用malloc申請了一個600byte的空間，那么會申請失?。ò吹览硎沁@樣、沒實驗過）
而對于系統(tǒng)棧Stack來說，這里限定的1024byte并不限定程序?qū)嶋H使用的大小，只是調(diào)試的時候會提示錯誤（也沒試驗過）
綜上，我的理解是，如果不用malloc，這兩個默認值是不用改的。
按照這個默認值來算，這才占用了1.5K的空間，所以大部分RAM空間都屬于全局區(qū)。
在FreeRTOS中：
在CubeMX配置時，我們配置了一個TOTAL_HEAP_SIZE
雖然叫HEAP，但跟系統(tǒng)堆沒關(guān)系，我們暫且叫RTOS堆。
RTOS堆使用的空間，是從全局區(qū)申請的。
| 成分 | 描述 |
|---|---|
| RTOS堆 | 在FreeRTOS初始化時，定義了大小，屬于系統(tǒng)的全局區(qū)部分。FreeRTOS使用的全部RAM，都從這里分配，包括任務(wù)棧、隊列、pvPortMalloc()申請的空間等等 |
所以在一個FreeRTOS工程里，只要不閑著沒事用malloc()，就不用管系統(tǒng)堆和系統(tǒng)棧了，況且FreeRTOS中并不推薦用malloc()，而是用pvPortMalloc()代替，二者的區(qū)別就是，前者在系統(tǒng)堆中分配空間，后者在RTOS堆中分配空間。
所以第一件事，就是合理設(shè)定一個TOTAL_HEAP_SIZE，總共的RAM有20K，我們可以先把它設(shè)為10K。
FreeRTOS提供了一個API:
//獲取剩余的堆空間xPortGetFreeHeapSize();
可以獲取剩余的堆空間，在適當(dāng)?shù)奈恢么蛴〕鰜恚龠M行優(yōu)化，另外如果某個任務(wù)創(chuàng)建失敗，一般就是堆空間不足，調(diào)試的時候把創(chuàng)建任務(wù)的結(jié)果打印出來比較好。
任務(wù)棧
| 成分 | 描述 |
|---|---|
| 任務(wù)棧 | 任務(wù)運行所需的空間，從RTOS堆中申請空間。用來存儲任務(wù)中的變量，函數(shù)嵌套保存現(xiàn)場所需的空間等等 |
任務(wù)棧在任務(wù)創(chuàng)建時設(shè)定
osThreadDef(Interactive_TASK,Interactive_Task, osPriorityNormal, 0, 128);osThreadCreate(osThread(Interactive_TASK), NULL);
單位是word，1word=4byte，棧溢出有可能會導(dǎo)致系統(tǒng)崩潰，現(xiàn)象往往是程序卡住，棧溢出原因是任務(wù)棧不足。
如何知曉一個任務(wù)棧不足呢？FreeRTOS提供了一個API
uxTaskGetStackHighWaterMark(NULL);
HighWaterMark譯為高水位，返回值是任務(wù)創(chuàng)建至今任務(wù)棧剩余量的最小值，這個值越接近0，任務(wù)越有棧溢出的風(fēng)險，一般要留有一定的余量。
做一個小測試：
//測試任務(wù)osThreadDef(TEST_TASK,test_Task, osPriorityNormal, 0, 128);osThreadCreate(osThread(TEST_TASK), NULL);//創(chuàng)建測試任務(wù)//測試任務(wù)void test_Task(){ for(;;) { //打印剩余的任務(wù)棧 printf("TEST剩余棧%d\r\n",(int)uxTaskGetStackHighWaterMark(NULL)); osDelay(1000); }}
測試結(jié)果：
可以大體推得，一個空任務(wù)占用的任務(wù)棧大概為128 - 52 = 76 word
與裸機編程類似，在任務(wù)中進行函數(shù)嵌套時，進入函數(shù)前，需要保存現(xiàn)場，保存現(xiàn)場的空間也是從任務(wù)棧中分配的，因此在RAM比較吃緊的情況下，要盡量避免過多的函數(shù)嵌套。
使用FreeRTOS后，反而不經(jīng)常使用在線仿真，大多數(shù)時候用printf打印LOG。
代碼和測試視頻在這里：
https://oshwhub.com/doee/wai-mai-zi-ti-gui-she-bei-duan-z
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
