改进uC/OS II，减少内存使用量

vector_leizi

在以uC/OS为操作系统的项目中，系统可能要处理各种不同的中断请求，如果某个中断处理程序需要调用uC/OS的各种Post函数向任务发出消息，那么uC/OS建议中断服务程序的写法是：
　　1、保存全部CPU寄存器
　　2、调用OSIntEnter或OSIntNesting直接加1
　　3、执行用户代码做中断服务
　　4、调用OSIntExit
　　5、恢复所有CPU寄存器
　　6、执行中断返回指令
　　暂且称为“标准中断”方式，这种方式实际上是将这个中断处理加入了任务调度系统，也就是说这个中断可以引起任务的切换。
　　如果在中断处理中没有调用各种Post函数的话，则可以用一般的、象原来没有操作系统时的写法：
　　1、保存中断处理程序需要用到的CPU寄存器
　　2、执行中断处理
　　3、恢复保存了的CPU寄存器
　　4、执行中断返回指令
　　暂且称为“快中断”方式，按照这种方法定义的中断永远不会引起任务切换。
　　在uC/OS系统中，每个任务都要定义独立的栈空间，一个栈空间的使用包括5个部分：
　　1、任务包括的各个函数的调用返回地址
　　2、任务包括的各个函数中可能在栈上分配的局部变量
　　3、发生了“标准中断”方式定义的中断或任务被挂起时，所要保存的任务上下文
　　4、发生了“快中断”方式定义的中断时，中断处理程序所需要的栈空间
　　5、中断嵌套时，所要保存的中断嵌套上下文
　　在这些使用的部分中，1，2，3，4的内存占用量是比较容易估算的，最精确和保险的确定方法是：查看由C生成的asm文件，并计算各个函数的栈使用量。但是第5部分的栈空间使用量是随中断嵌套的深度而不断增加的，是不确定的，一般的方法只能定义一个充分大的栈空间，使之不会溢出。
　　为每个任务都定义一个充分大的栈空间，这在某些内存稀缺的小项目中是非常痛苦的，有时不得不增扩内存，这就会使成本增加。
　　我深入研究了uC/OS后，认为，可以将所有任务栈空间使用的第5部分合并，这样将会大大的降低整个系统对内存的需求。
　　uC/OS的任务调度是靠OS_Sched和OSIntExit来完成的，这两个函数中都要先判断一个叫 OSIntNesting的系统变量，如果OSIntNesting不为0，则不进行任务切换。也就是说：在OSIntNesting为1（当前只有一个中断在处理中，并且没有嵌套的中断）时起，如果发生了嵌套的中断（不管嵌套的层数有深），那么在所有嵌套的中断一层一层地都返回直到 OSIntNesting再次为1时止，任务栈是不会切换的（栈指针都在一个任务的栈空间中变化）。
　　据此，我们可以这样改动：设置一个缓冲区OSInterruptStk，作为嵌套中断的栈空间，由所有任务共享，中断服务程序改为：
　　1、保存全部CPU寄存器
　　2、调用OSIntEnter或OSIntNesting直接加1
　　增加：2.1、判断OSIntNesting是否等于1，如果不是则转到3
　　增加：2.2、将栈指针SP保存到OSTCBCur->OSTCBStkPtr
　　增加：2.3、将SP指向OSInterruptStk的栈顶（注意栈增长的方向）。
　　3、执行用户代码做中断服务
　　4、调用OSIntExit
　　增加：4.1、判断OSIntNesting是否等于0，如果不是则转到5
　　增加：4.2、从OSTCBCur->OSTCBStkPtr中恢复栈指针SP
　　5、恢复所有CPU寄存器
　　6、执行中断返回指令
　　并且要修改OSIntCtxSw函数，原始的OSIntCtxSw函数的写法是：
　　1、调整栈指针来去掉在调用：OSIntExit，OSIntCtxSw过程中入栈的多余内容
　　2、将当前任务栈指针保存到OSTCBCur中（OSTCBCur->OSTCBStkPtr = __SP__）
　　3、如果需要则调用OSTaskSwHook
　　4、OSTCBCur = OSTCBHighRdy
　　5、OSPrio = OSPrioHighRdy
　　6、从OSTCBCur中恢复栈指针（__SP__ = OSTCBCur->OSTCBStkPtr）
　　7、恢复保存了的CPU寄存器
　　8、执行中断返回指令
　　新的写法只需将原写法中的1，2去掉即可，因为1，2步只是保存旧任务的栈指针，而新的写法中，这些步被移到了“中断服务程序”中的2.2。

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/96265/showart_2147644.html