堆栈溢出是嵌入式开发中比较难排查的bug，很多朋友都以增加足够的堆栈空间来尽量避免该bug。但是这样的"黑盒"处理并没有抓住问题的本质，因为堆栈溢出没有明显的特征与之对应，自认为增加堆栈就解决了问题，而实际有些问题并非堆栈溢出引起，所以定位堆栈溢出必须从其本质出发对其进行监测并定位。如果你还不理解或没有在MCU程序开发中考虑堆栈溢出问题，务必要读一读之前发布的两篇文章，相信看完你就能把握住这一块:
因为这段时间开发新的项目，算了一下内存，不是特别够用，所以准备把之前公司用的OS进一步精简一下，目前使用的芯片自带MPU，一直都是使用前面文章介绍的三种办法中的"MPU替代法”，然而这种办法有个缺点 : 其占用的内存比较大，每个任务的堆栈检测MPU保护区都会浪费较大的内存，太小的话容易导致漏检。为了弥补这种检测机制的缺陷，同时目前OS的所有任务堆栈都是连续分配的，所以就对该检测机制进行了优化，达到节省内存的目的。
左侧是之前的检测机制，每个任务的MPU内存保护区域均位于自身所分配的堆栈区域，且该区域无法访问，否则会触发内存访问异常中断。
由于各任务之间的堆栈是独立的，我们只需要让这些堆栈内存区域连续分配，从而可以把MPU内存保护区域设置在相邻的任务堆栈中，一旦当前任务存在堆栈溢出问题，基本上会直接访问到仅挨着的内存区域，从而访问到MPU内存保护区域触发异常中断，接着我们可以在对应的中断服务函数中进行最后的收尾处理。这样就可以节省几个被MPU所限制的内存区域，任务数越多节省的内存越大，当然如果是裸机单任务就不需要这么麻烦了~ 好了,今天的内容就到这里了，如果觉得有所收获，记得跟bug菌点个赞~
在公众号聊天界面回复1024，可获取嵌入式资源；回复 m ，可查看文章汇总。