1、Cortex-M3 的PSP和MSP

     曾经在STM32上使用过RT thread和uC/OS,对于任务切换代码一直是一知半解,没有自己手动写出来过,对于任务切换后的ORR   LR, LR, #0x04; Ensure exception return uses process stack也不是很理解,一次偶然的机会,遇到网上有人问这个问题,才去深入研究一下。Cortex‐M3 拥有两个堆栈指针,然而它们是banked,因此任一时刻只能使用其中的一个:

     主堆栈指针(MSP):复位后缺省使用的堆栈指针,用于操作系统内核以及异常处理例程(包括中断服务例程)。

     进程堆栈指针(PSP):由用户的应用程序代码使用。堆栈指针的最低两位永远是0,这意味着堆栈总是4 字节对齐的。

    由此可以看出,在一个系统里有两大部分,一是操作系统和中断,一是用户用户程序,他们使用的资源是不一样的,在任务调度的时候,中断(任务调度的中断)返回到用户程序所以要使用PSP。

2、Linux系统中断中能否使用Sleep

      这个是我一个同学的面试题,说给我的时候我第一反应是可以,在中断中使用Sleep不会使得中断挂起,在任务中使用Sleep会将当前的任务挂起,Sleep的原理是根据Sleep的参数N暂停当前的任务,N个周期(也可能是MS)后将该任务置为就绪态,换言之,Sleep实际上就是一次任务调度,那为什么不可以的,我还进一步解释,在uC/OS中,在中断的结尾都会调用OS_INT_EXIT()函数来进行任务的调度,Sleep与OS_INT_EXIT只是函数名不同,最终都是会调用调度器的。

      哈哈,对于正确答案我想大家都猜到了,那就是当然不可以的啦,但是我的解释貌似天衣无缝哦,那是因为我是使用uC/OS来解释的,Linux系统当然和uC/OS不同,回头看看,在Cortex-M3的硬件中有MSP和PSP,那么他的设计初衷是什么,那就是操作系统(包括中断)和用户程序分(隔)离,或者说是保护操作系统,防止遭到破坏,在这种思想下,Linux系统中,对于涉及到系统核心的东西使用保护的,不是所有的地方都是可见的,uC/OS是系统和应用程序一起编译,只要是全局变量都是可以见的,而Linux不同,在中断上下为中,current宏是无效的,所以此时是无法进行任务调度的。

     以上是我结合Cortex-M3内核的硬件,从隔离和保护的思想去解释为什么Linux下,中断中不能使用Sleep。下面给出我查阅资料的官方解释,主要是《linux内核设计与实现》上的内容。

     1、进程上下文

      可执行代码是进程的重要组成部分,这些代码从一个可执行文件载入到进程的地址空间执行。一般的程序在用户空间执行,当一个程序执行了系统调用或者触发了某个异常,它就陷入了内核空间,此时,我们称内核代表进程执行并处于进程上下文中。在此上下文中current宏是有效的。(系统调用和异常处理程序是对内核明确定义的接口,进程只有通过这些接口才能陷入内核执行—对内核的所有访问都必须通过这些接口。

     2、中断上下文

      当执行一个中断处理程序时,内核处于中断上下文中,中断上下文和进程并没有任何瓜葛。与current宏也是不相干的(尽管它会指向被被中断的进程)。因为没有后备进程,所以中断上下文不可以睡眠,否则又怎能再对它重新调度呢?因此,不能从中断上下文中调用某些函数(就是被中断处理程序限制的函数,Sleep就是其中一个)。

     事实上,除了MSP和PSP之外,处理器很多的寄存器都是banked,用户程序和中断程序使用的寄存器是不同的,所以进程上下文和中断上下文环境是不同的,如果在中断上下文中进行任务调度,是没有办法保存进程上下文信息的,所以如果这个时候调度就是有问题的,软件上阻止了该调度——即current宏此时是不可见的,从而无法进行调度。