STM32CubeMX FreeRTOS堆栈分配和调试技巧

免责声明:本文材料的源网络,版权属于原作者。如果涉及该作品的版权问题,请与我联系以将其删除。堆栈空间分配这部分非常重要。如果单片机的RAM太紧,则必须仔细计划。这个问题涉及许多令人困惑的概念。在学习时,我还阅读了很多帖子,并根据自己的理解进行了整理。请指出评论部分或私人消息中的任何错误。参考博客:https://www.cnblogs.com/CaesarTao/p/9816965.html RAM首先,我选择了具有20K RAM的stm32f103RBT6。 20K分为4个部分:其中,“内部使用,中断向量等”。是由系统固定的,我们不需要对其进行管理。其中,HEAP和STACK与FreeRTOS中的堆和堆栈无关。为了避免混淆,在裸机编程中,我们在这里将HEAP称为系统堆,在这里将STACK称为系统堆栈:组成描述系统堆HEAP当我们使用malloc函数申请内存时,我们对其进行申请从这里。它的大小必须由程序员预先定义。如果没有足够的空间,则malloc将使应用程序失败。到目前为止,我了解到的是它只有一种效果。系统堆栈STACK用于存储临时变量,函数参数等。当我们嵌套函数时,在进入函数之前,我们需要保存场景。当函数执行完后返回到原始位置时,我们需要还原场景,并保存从系统堆栈中获得的用于场景的内存,如果系统堆栈不足,通常会​​出现堆栈溢出,导致程序运行失败。与系统堆栈不同,系统堆栈不需要预先指定大小,这不会影响程序的运行。全局区域用于存储全局变量和静态变量。在stm32项目的启动文件中,堆系统堆和系统堆栈定义大小:Stack_Size默认为0x400 1024byte Heap_Size默认为0x200 512byte对于系统堆Heap,如果使用malloc申请600byte对于系统堆栈, 1024字节的限制并不限制实际使用的程序的大小,但是在调试时会提示错误(未经测试)。 )总之,我的理解是,如果不使用malloc,则不需要更改这两个默认值。根据此默认值计算,这仅占用1.5K空间,因此大多数RAM空间属于全局区域。在FreeRTOS中:在CubeMX配置中,我们配置了TOTAL_HEAP_SIZE。尽管它被称为HEAP,但它与系统堆无关。现在将其称为RTOS堆。从全局区域请求RTOS堆使用的空间。组件说明RTOS堆初始化FreeRTOS时,大小已定义并属于系统的全局区域。 FreeRTOS使用的所有RAM均从此处分配,包括任务堆栈,队列,pvPortMalloc()请求的空间等。因此,在FreeRTOS项目中,只要malloc()不空闲且不使用任何东西,系统堆和系统堆栈将被忽略。此外,在FreeRTOS中不建议使用malloc(),而是使用pvPortMalloc()。两者之间的区别在于,前者在系统堆中分配空间,而后者在RTOS堆中分配空间。因此,第一件事是设置一个合理的TOTAL_HEAP_SIZE,总RAM为20K,我们可以首先将其设置为10K。 FreeRTOS提供了一个API://获取剩余的堆空间xPortGetFreeHeapSize();您可以获取剩余的堆空间,将其打印在适当的位置,然后对其进行优化。此外,如果任务创建失败,通常是由于堆空间不足,请进行调试。最好打印出任务创建的结果。任务堆栈组件说明任务堆栈任务操作所需的空间,向RTOS堆请求空间。 osThreadDef(Interactive_TASK,Interactive_Task,osPriorityNormal,0,128);用于在任务中存储变量,函数嵌套以节省场景所需的空间等。 osThreadCreate(osThread(Interactive_TASK),NULL);单位是字,1word = 4byte。堆栈溢出可能导致系统崩溃。这种现象通常是程序卡住,并且堆栈溢出的原因是任务堆栈不足。如何知道任务堆栈不足? FreeRTOS提供了一个API uxTaskGetStackHighWaterMark(NULL); HighWaterMark被翻译为高水位标记。返回值是自创建任务以来任务堆栈剩余量的最小值。该值越接近0,任务承担堆栈溢出的风险就越大。通常,应保留一定量。利润。做一个小测试://测试任务osThreadDef(TEST_