我们知道 Cortex-M3 系列单片机内部有双堆栈机制。即 Cortex‐M3 拥有两个堆栈指针：主堆栈（MSP）和进程堆栈（PSP）。任一时刻只能使用其中的一个。通过控制寄存器 CONTROL 中的选择位进行控制。
两个堆栈指针如下：
- 主堆栈指针（ MSP）：复位后缺省使用的堆栈指针，用于操作系统内核以及异常处理例程（包括中断服务例程）
- 进程堆栈指针（ PSP）：由用户的应用程序代码使用。
将RTOS 移植到 Cortex-M3 系列单片机上后，任务堆栈用的是 PSP，然而任务切换是在中断处理函数 PendSV() 中完成的。
那么在任务切换期间，MCU 在执行指令的过程中，是如何选择堆栈指针呢？
下面逐步进行分析。
堆栈的基本操作
堆栈操作就是对内存的读写操作，其地址由 SP 给出。寄存器的数据通过 PUSH 操作存入堆栈，以后用 POP 操作从堆栈中取回。在 PUSH 与 POP 的操作中， SP 的值会按堆栈的使用法则自动调整，以保证后续的 PUSH 不会破坏先前 PUSH 进去的内容。
堆栈的功能就是把寄存器的数据放入内存，当一个任务或一段子程序执行完毕后，能够恢复继续执行。正常情况下， PUSH 与 POP 必须成对使用，而且参与的寄存器，不论是身份还是先后顺序都必须完全一致。当 PUSH/POP 指令执行时， SP 指针的值也根着自减/自增。
Cortex‐M3 使用的是“向下生长的满栈”模型。堆栈指针 SP 指向最后一个被压入堆栈的 32位数值。在下一次压栈时， SP 先自减 4，再存入新的数值。
POP 操作刚好相反：先从 SP 指针处读出上一次被压入的值，再把 SP 指针自增 4 。
在进入 ESR 时， CM3 会自动把一些寄存器压栈，这里使用的是发生本异常的瞬间正在使用的 SP 指针（MSP 或者是 PSP）。离开 ESR 后，只要 ESR 没有更改过 CONTROL[1]，就依然使用发生本次异常的瞬间正在使用的 SP 指针来执行出栈操作。
堆栈使用控制
已经知道了 CM3 的堆栈是分为两个：主堆栈和进程堆栈， 具体使用哪个堆栈（MSP 还是 PSP） 通过特殊寄存器 CONTROL[1] 来控制。
控制寄存器 CONTROL，有两个用途：其一用于定义特权级别，其二用于选择当前使用哪个堆栈指针。
当 CONTROL[1]=0 时，只使用 MSP，此时用户程序和异常 handler 共享同一个堆栈。这也是复位后的缺省使用方式。
当 CONTROL[1]=1 时，线程模式将不再使用 MSP，而改用 PSP（handler 模式永远使用 MSP）。这样做的好处在哪里？原来，在使用 OS 的环境下，只要 OS 内核仅在 handler 模式下执行，用户应用程序仅在用户模式下执行，这种双堆栈机制防止用户程序的堆栈错误破坏 OS 使用的堆栈。
再介绍一下两个操作模式，Cortex-M3 支持 两个模式和两个特权等级：
- 两个模式：handler模式和线程模式
- 两个特权等级：特权级和用户级
当处理器处在线程状态下时，既可以使用特权级，也可以使用用户级；另一方面， handler 模式总是特权级的。在复位后，处理器进入线程模式＋特权级。
在特权级下的代码可以通过置位 CONTROL[0]来进入用户级。而不管是任何原因产生了任何异常，处理器都将以特权级来运行其服务例程，异常返回后，系统将回到产生异常时所处的级别。
用户级下的代码不能再试图修改 CONTROL[0]来回到特权级。它必须通过一个异常 handler，由那个异常handler 来修改 CONTROL[0]，才能在返回到线程模式后拿到特权级。
运行在线程模式的用户代码使用 PSP，而异常服务例程则使用 MSP。这两个堆栈指针的切换是智能全自动的，就在异常服务的始末由 CM3 硬件处理。
中断处理过程
响应异常的第一个行动，就是自动保存现场的必要部分：依次把 xPSR, PC, LR, R12 以及 R3-R0 由硬件自动压入适当的堆栈中。
当响应异常时，如果当前的代码正在使用 PSP，则压入 PSP，也就是使用进程堆栈；否则就压入MSP，使用主堆栈。
一旦进入了服务例程，就将一直使用主堆栈。
在进入异常服务程序后，将自动更新 LR（链接寄存器R14） 的值为特殊的 EXC_RETURN。这是一个高28位全为1的值，只有 [3:0] 的值有特殊含义，如下表所示。当异常服务例程把这个值送往 PC 时，就会启动处理器的中断返回序列。因为LR 的值是由 CM3 自动设置的，所以只要没有特殊需求，就不要改动它。
总结一下，可以得出三个合法的 EXC_RETURN 值 ：
如果主程序在线程模式下运行，并且在使用MSP时被中断，则在服务例程中 LR=0xFFFF_FFF9（主程序被打断前的LR已被自动入栈）。
如果主程序在线程模式下运行，并且在使用 PSP 时被中断，则在服务例程中 LR=0xFFFF_FFFD（主 程序被打断前的LR已被自动入栈）。
PendSV 中断介绍
SVC（系统服务调用，亦简称系统调用）和 PendSV（可悬起系统调用），它们多用于在操作系统之上的软件开发中。 SVC 用于产生系统函数的调用请求。
SVC 异常通过执行 ”SVC” 指令来产生。 该指令需要一个立即数， 充当系统调用代号。SVC异常服务例程稍后会提取出此代号， 从而解释本次调用的具体要求， 再调用相应的服务函数。
例如，
SVC 0x3 ; 调用 3 号系统服务
在 SVC 服务例程执行后，上次执行的 SVC 指令地址可以根据自动入栈的返回地址计算出。找到了 SVC 指令后， 就可以读取该 SVC 指令的机器码，从机器码中萃取出立即数，就获知了请求执行的功能代号。
如果用户程序使用的是 PSP， 服务例程还需要先执行 MRS Rn,PSP 指令来获取应用程序的堆栈指针 。通过分析 LR 的值，可以获知在 SVC 指令执行时，正在使用哪个堆栈
PendSV（可悬起的系统调用）和 SVC 协同使用。
SVC 异常是必须立即得到响应的（对于 SVC 异常来说，若因优先级不比当前正处理的高，或是其它原因使之无法立即响应，将造成成硬 fault ）， 应用程序执行 SVC 时都是希望所需的请求立即得到响应。
PendSV 则不同，它是可以像普通的中断一样被悬起的。 OS 可以利用它“缓期执行” 一个异常——直到其它重要的任务完成后才执行动作。 悬起 PendSV 的方法是： 手动往 NVIC 的 PendSV 悬起寄存器中写 1。 悬起后， 如果优先级不够
高，则将缓期等待执行。
PendSV 的典型使用场合是在上下文切换时（在不同任务之间切换）。 例如， 一个系统中 有两个就绪的任务，上下文切换被触发的场合可以是：
- 执行一个系统调用
- 系统滴答定时器（SYSTICK）中断，（轮转调度中需要）
PendSV 异常会自动延迟上下文切换的请求，直到其它的 ISR 都完成了处理后才放行。为实现这个机制，需要把 PendSV 编程为最低优先级的异常。
如果 OS 检测到某 IRQ 正在活动并且被 SysTick 抢占，它将悬起一个 PendSV 异常，以便缓期执行上下文切换。
- 任务 A 呼叫 SVC 来请求任务切换（例如，等待某些工作完成）
- OS 接收到请求，做好上下文切换的准备，并且 pend 一个 PendSV 异常。
- 当 CPU 退出 SVC 后，它立即进入 PendSV，从而执行上下文切换。
- 当 PendSV 执行完毕后，将返回到任务 B，同时进入线程模式。
- 发生了一个中断，并且中断服务程序开始执行
- 在 ISR 执行过程中，发生 SysTick 异常，并且抢占了该 ISR。
- OS 执行必要的操作，然后 pend 起 PendSV 异常以作好上下文切换的准备。
- 当 SysTick 退出后，回到先前被抢占的 ISR 中， ISR 继续执行
- ISR 执行完毕并退出后， PendSV 服务例程开始执行，并且在里面执行上下文切换
- 当 PendSV 执行完毕后，回到任务 A，同时系统再次进入线程模式
RTOS系统中双堆栈操作
一个真正健壮的 CM3 软件系统是要使用实时操作系统内核的，通常会符合如下的要求：
- 服务例程使用 MSP
- 尽管异常服务例程使用 MSP，但是它们在形式上返回后，内容上却可以依然继续——而且此时还能使用 PSP，从而实现“可抢占的系统调用”，大幅提高实时性能
- 通过 SysTick，实时内核的代码每隔固定时间都被调用一次，运行在特权级水平上，负责任务的调度、任务时间管理以及其它系统例行维护
- 用户应用程序以线程的形式运行，使用 PSP，并且在用户级下运行
- 内核在执行关键部位的代码时，使用 MSP，并且在辅以 MPU 时， MSP 对应的堆栈只允许特权级访问
在操作系统中，对于 EXC_RETURN 的修改，只是再寻常不过基本需求。在开始调度用户程序后，一定还伴随着 SysTick 异常，它周期性把执行权转入操作系统，从而使例行的系统管理以及必要轮转调度得以维持，任务切换过程如图所示：
上图为 SysTick 异常推动时间片轮转调度模式图。在这里，使用 PendSV（一个优先级最低的异常）来执行上下文切换，从而消灭了在中断服务例程中出现上下文切换的可能。
在 SysTick 中断例程中执行必要的操作，然后悬挂起 PendSV 异常以作好上下文切换的准备。退出 SysTime 中断处理函数后，PendSV 服务例程开始执行，并且在里面执行上下文切换。
在任务-1 和 任务2 程序执行过程中使用的是 PSP（线程堆栈）。进入中断服务程序后（SysTime 和 PendSV）在内部使用的是MSP（主堆栈）。
感谢阅读，加油~
