前言
很多工程师在裸机转 RTOS 时，最头疼的就是：代码逻辑明明没改，系统跑着跑着就莫名其妙死机（HardFault），或者变量的值被莫名其妙篡改。这 90% 的情况都指向同一个元凶：堆栈（Stack/Heap）失控。
1:为什么系统运行几天后莫名 HardFault？
栈溢出（Stack Overflow）：局部变量开太大，或者函数嵌套太深（尤其是递归或
printf），直接踩到了隔壁任务的领地。堆碎片（Heap Fragmentation）：频繁使用
malloc/free，导致内存被切成细碎的“小块”，虽然总数够，但想申请大块时却失败了。内存泄漏：任务退出前忘记释放动态分配的对象。
2:知识点：栈与堆的“生存法则”
2.1 栈（Stack）：任务的“私人空间”
在 RTOS 中，每个任务都有自己独立的栈。
存什么：函数返回地址、寄存器现场、局部变量。
危险点：
printf这种带格式化的函数，内部往往会开辟巨大的缓冲区，是栈空间的“吞噬者”。
2.2 堆（Heap）：大家的“公共空间”
RTOS 提供了一套堆管理机制（如 FreeRTOS 的heap_4.c）。
heap_4.c 的妙处：它能自动合并相邻的空闲块，减少碎片，比标准 C 库的
malloc更适合嵌入式。
3:实战代码：探测并抓取“栈溢出”
我们不能靠猜来设定栈大小，要靠测量。
3.1 开启栈溢出检测（在FreeRTOSConfig.h）
#define configCHECK_FOR_STACK_OVERFLOW 2 // 模式 2：最严格检测3.2 编写溢出钩子函数
一旦发生溢出，内核会调用这个函数，让你在死机前留下“遗言”。
void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { /* 这里的 pcTaskName 就是那个犯错的任务名字 */ printf("ERROR: Stack Overflow in Task: [%s]\r\n", pcTaskName); while(1); // 停在这里，方便用调试器看调用栈 }3.3 实操：利用 CMSIS-V2 查询“高水位线”
“高水位线”是指任务自运行以来，剩余栈空间的最小值。
void MonitorTask(void *argument) { for(;;) { // 获取当前任务剩余栈大小（以字为单位） uint32_t free_stack = osThreadGetStackSpace(MyTaskHandle); // 如果 free_stack 接近 0，说明危险了！ if(free_stack < 32) { // 报警或记录日志 } osDelay(1000); } }老鸟建议：如何估算栈大小？
静态分析：把任务里所有局部变量大小加起来（注意：
char buf[128]占 128 字节）。调用深度：估算函数嵌套层数，每层约占 32 字节。
中断预留：如果是 Cortex-M 内核，硬件会自动压栈 8 个寄存器。
黄金法则：在 Debug 阶段，先分配一个较大的栈（如
512*4），运行一段时间后通过osThreadGetStackSpace查看消耗情况，最后减去 20% 的余量。
堆管理：内存池（Memory Pool）
为了彻底杜绝碎片，资深工程师在传输固定大小的数据（如串口报文）时，会放弃malloc，改用Memory Pool。
内存池真实代码
typedef struct { uint8_t data[64]; } Message_t; osMemoryPoolId_t mp_id; void Init_Memory(void) { // 创建一个可以容纳 10 个 Message_t 的内存池 mp_id = osMemoryPoolNew(10, sizeof(Message_t), NULL); } void ProducerTask(void *argument) { for(;;) { // 1. 从池子里申请一个块 Message_t *msg = (Message_t *)osMemoryPoolAlloc(mp_id, osWaitForever); if(msg != NULL) { // 2. 填充数据 // 3. 投递到队列... } } }总结本章
在 RTOS 里，栈是每个任务的“私有空间”，要量入为出；堆是大家的“公共区域”，要防止浪费和混乱。
