cortex-M3 异常-- SVC、PendSV介绍

左手的ㄟ右手 2022-06-12 10:37 264阅读 0赞

出处：[http://blog.csdn.net/guozhongwei1/article/details/49544671][http_blog.csdn.net_guozhongwei1_article_details_49544671]

问：ucos 任务切换时机，如何满足实时性？  
找上SVC、PendSV啦，先了解下….

--------------------

以下出自–《cortex-M3权威指南》

## 特殊功能寄存器组： ##

*  程序状态寄存器组（PSRs 或曰xPSR）
 *  中断屏蔽寄存器组（PRIMASK, FAULTMASK,以及BASEPRI）
 *  控制寄存器（CONTROL）  
    xPSR：  
    记录ALU算数逻辑单元(Arithmetic Logic Unit) 标志（0 标志，进位标志，负数标志，溢出标志），执行状态，以及当前正服务的中断号。
 *  应用程序 PSR（APSR）
 *  中断号 PSR（IPSR）
 *  执行 PSR（EPSR）  
    这里唠叨下，只因不熟悉。。。。  
    通过MRS/MSR 指令，这3 个PSRs 即可以单独访问，也可以组合访问（2 个组合，3 个组合都可以）。当使用三合一的方式访问时，应使用名字“xPSR”或者“PSR”。![20170721155946174][]  
    关于ICI/IT、T：  
    ICI：在中断延迟中有提到，与LDM/STM的处理机制有关。LDM/STM是一串LDR/STR的速度优化版。于是，为了加速中断的响应，CM3支持LDM/STM指令的中止和继续，就好像它们只是普通的一串LDR/STR一样。为了实现“指令撕裂与粘合”的目的，需要记录中断时数据传送的进程。为此，CM3在xPSR中开出若干个“ICI位”，记录下一个即将传送的寄存器是哪一个（LDM/STM在汇编时，都把寄存器号升序排序）。在服务例程返回后，xPSR被弹出，CM3再从ICI bits中获取当时LDM/STM执行的进度，从而可以继续传送。  
    这个办法听起来是个好主意，只是在个别情况下还有一点限制：IF‐THEN(IT)指令的执行也需要在xPSR中使用几个位，可它需要的位刚好与ICI位重合（类似C中的union）——both ICI bits和IT条件都记录在EPSR中。所以，如果在IF‐THEN中使用了LDM/STM，则不再记录LDM/STM  
    的执行进度。但尽管如此，及时响应中断依然是首要任务。此时只好把LDM/STM取消，待中断返回后继续执行。–这里待续++

中断屏蔽寄存器组：

*  PRIMASK：除能所有的中断——当然了，不可屏蔽中断（NMI）才不甩它呢。
 *  FAULTMASK：除能所有的fault——NMI 依然不受影响，而且被除能的faults 会“上访”。
 *  BASEPRI：除能所有优先级不高于某个具体数值的中断。

控制寄存器：

*  CONTROL：定义特权状态（见后续章节对特权的叙述），并且决定使用哪一个堆栈指针

只有在特权级下，才允许访问这3 个寄存器。  
![20170721155951520][]  
一个指定PSP 进行更新的例子：

LDR R0, =0x20008000
    MSR PSP, R0
    BX LR ;如果是从异常返回到线程状态，则使用新的PSP 的值作为栈顶指针
     
      
       1 
       2 
       3 
      
     
      
       1 
       2 
       3

cortex-M3权威指南，有这样一段：

--------------------

为了快速地开关中断，CM3 还专门设置了一条CPS 指令，有4 种用法

CPSID   I   ;PRIMASK=1;关中断 
    CPSIE   I   ;PRIMASK=0;开中断
    CPSID   F   ;FAULTMASK=1;关异常
    CPSIE   F   ;FAULTMASK=0;开异常
     
      
       1 
       2 
       3 
       4 
      
     
      
       1 
       2 
       3 
       4

--------------------

？CPS指令是？==改变处理器状态==change processor state  
这款内核也许就这两个CPS指令  
![20170721155956430][]

## SVC和PendSV ##

SVC（系统服务调用，亦简称系统调用）和PendSV（可悬起系统调用），它们多用于在[操作系统][Link 1]之上的软件开发中。SVC 用于产生系统函数的调用请求。例如，操作系统不让用户程序直接访问硬件，而是通过提供一些系统服务函数，用户程序使用SVC 发出对系统服务函数的呼叫请求，以这种方法调用它们来间接访问硬件。因此，当用户程序想要控制特定的硬件时，它就会产生一个SVC 异常，然后操作系统提供的SVC 异常服务例程得到执行，它再调用相关的操作系统函数，后者完成用户程序请求的服务。  
这种“提出要求——得到满足”的方式，很好、很强大、很方便、很灵活、很能可持续发展。首先，它使用户程序从控制硬件的繁文缛节中解脱出来，而是由OS 负责控制具体的硬件。第二，OS 的代码可以经过充分的[测试][Link 2]，从而能使系统更加健壮和可靠。第三，它使用户程序无需在特权级下执行，用户程序无需承担因误操作而瘫痪整个系统的风险。第四，通过SVC 的机制，还让用户程序变得与硬件无关，因此在开发应用程序时无需了解硬件的操作细节，从而简化了开发的难度和繁琐度，并且使应用程序跨硬件平台移植成为可能。开发应用程序唯一需要知道的就是操作系统提供的应用编程接口（API），并且了解各个请求代号和参数表，然后就可以使用SVC 来提出要求了（事实上，为使用方便，操作系统往往会提供  
一层封皮，以使系统调用的形式看起来和普通的函数调用一致。各封皮函数会正确使用SVC指令来执行系统调用——译者注）。其实，严格地讲，操作硬件的工作是由设备驱动程序完成的，只是对应用程序来说，它们也是操作系统的一部分。如图7.14 所示  
![20170721160000288][]  
SVC 异常通过执行”SVC”指令来产生。该指令需要一个立即数，充当系统调用代号。SVC异常服务例程稍后会提取出此代号，从而解释本次调用的具体要求，再调用相应的服务函数。例如，

SVC 0x3 ; 调用3 号系统服务
     
      
       1 
      
     
      
       1

在SVC 服务例程执行后，上次执行的SVC 指令地址可以根据自动入栈的返回地址计算出。找到了SVC 指令后，就可以读取该SVC 指令的机器码，从机器码中萃取出立即数，就获知了请求执行的功能代号。如果用户程序使用的是PSP，服务例程还需要先执行

MRS Rn,PSP
     
      
       1 
      
     
      
       1

指令来获取应用程序的堆栈指针。通过分析LR 的值，可以获知在SVC 指令执行时，正在使用哪个堆栈。  
由CM3 的中断优先级模型可知，你不能在SVC 服务例程中嵌套使用SVC 指令（事实上这样做也没意义），因为同优先级的异常不能抢占自身。这种作法会产生一个用法fault。同理，在NMI 服务例程中也不得使用SVC，否则将触发硬fault。

PendSV：  
另一个相关的异常是PendSV（可悬起的系统调用），它和SVC 协同使用。一方面，SVC异常是必须立即得到响应的（若因优先级不比当前正处理的高，或是其它原因使之无法立即响应，将上访成硬fault——译者注），应用程序执行SVC 时都是希望所需的请求立即得到响应。另一方面，PendSV 则不同，它是可以像普通的中断一样被悬起的（不像SVC 那样会上访）。OS 可以利用它“缓期执行”一个异常——直到其它重要的任务完成后才执行动作。悬起PendSV 的方法是：手工往NVIC 的PendSV 悬起寄存器中写1。悬起后，如果优先级不够高，则将缓期等待执行。  
PendSV 的典型使用场合是在上下文切换时（在不同任务之间切换）。例如，一个系统中有两个就绪的任务，上下文切换被触发的场合可以是：

*  执行一个系统调用
 *  系统滴答定时器（SYSTICK）中断，（轮转调度中需要）  
    举个简单的例子来辅助理解。假设有这么一个系统，里面有两个就绪的任务，并且通过SysTick 异常启动上下文切换。如图7.15 所示。  
    ![20170721160005238][]  
    上图是两个任务轮转调度的示意图。但若在产生SysTick 异常时正在响应一个中断，则SysTick 异常会抢占其ISR。在这种情况下，OS 不得执行上下文切换，否则将使中断请求被延迟，而且在真实系统中延迟时间还往往不可预知——任何有一丁点实时要求的系统都决不能容忍这种事。因此，在CM3 中也是严禁没商量——如果OS 在某中断活跃时尝试切入线程模式，将触犯用法fault 异常。  
    ![20170721160012824][]  
    为解决此问题，早期的OS 大多会检测当前是否有中断在活跃中，只有没有任何中断需要响应时，才执行上下文切换（切换期间无法响应中断）。然而，这种方法的弊端在于，它可以把任务切换动作拖延很久（因为如果抢占了IRQ，则本次SysTick 在执行后不得作上下文切换，只能等待下一次SysTick 异常），尤其是当某中断源的频率和SysTick 异常的频率比较接近时，会发生“共振”。  
    现在好了，PendSV 来完美解决这个问题了。PendSV 异常会自动延迟上下文切换的请求，直到其它的ISR 都完成了处理后才放行。为实现这个机制，需要把PendSV 编程为最低优先级的异常。如果OS 检测到某IRQ 正在活动并且被SysTick 抢占，它将悬起一个PendSV 异常，以便缓期执行上下文切换。如图7.17 所示  
    ![20170721160016866][]  
    个中事件的流水账记录如下：  
    
    
    1.  任务 A 呼叫SVC 来请求任务切换（例如，等待某些工作完成）
    2.  OS 接收到请求，做好上下文切换的准备，并且pend 一个PendSV 异常。
    3.  当 CPU 退出SVC 后，它立即进入PendSV，从而执行上下文切换。
    4.  当 PendSV 执行完毕后，将返回到任务B，同时进入线程模式。
    5.  发生了一个中断，并且中断服务程序开始执行
    6.  在 ISR 执行过程中，发生SysTick 异常，并且抢占了该ISR。
    7.  OS 执行必要的操作，然后pend 起PendSV 异常以作好上下文切换的准备。
    8.  当 SysTick 退出后，回到先前被抢占的ISR 中，ISR 继续执行
    9.  ISR 执行完毕并退出后，PendSV 服务例程开始执行，并且在里面执行上下文切换
    10. 当 PendSV 执行完毕后，回到任务A，同时系统再次进入线程模式。

留存…..

[http_blog.csdn.net_guozhongwei1_article_details_49544671]: http://blog.csdn.net/guozhongwei1/article/details/49544671
[20170721155946174]: /images/20220612/58dd84738d1443df8b8c4e775577d725.png
[20170721155951520]: /images/20220612/ac680e3f77734710813e469ad9f34fb2.png
[20170721155956430]: /images/20220612/5b65c1724b6c4a04b8f03986621cfb03.png
[Link 1]: http://lib.csdn.net/base/operatingsystem
[Link 2]: http://lib.csdn.net/base/softwaretest
[20170721160000288]: /images/20220612/e1db4f53cecd47779b516e76977c6459.png
[20170721160005238]: /images/20220612/b8cc6ed38cd24d408dfabd3faa02cdef.png
[20170721160012824]: /images/20220612/22c4dbeb866342f4a78d3b0ab82b1c59.png
[20170721160016866]: /images/20220612/528a4e6a9f104c1fac7e3e6dcc1e1f06.png