SVC和PendSV 注意：阅读本节的后面需要一点点多任务编程的基础 .DOC

SVC和 PendSV 注意：阅读本节的后面需要一点点多任务编程的基础知识——译者注 SVC（系统服务调用，亦简称系统调用）和 PendSV（可悬起系统调用），它们多用在上了操作系统的软件开发中。SVC 用于产生系统函数的调用请求。例如，操作系统通常不让用户程序直接访问硬件，而是通过提供一些系统服务函数，让用户程序使用 SVC 发出对系统服务函数的呼叫请求，以这种方法调用它们来间接访问硬件。因此，当用户程序想要控制特定的硬件时，它就要产生一个SVC异常，然后操作系统提供的 SVC异常服务例程得到执行，它再调用相关的操作系统函数，后者完成用户程序请求的服务。 这种“提出要求——得到满足”的方式，很好、很强大、很方便、很灵活、很能可持续发展。首先，它使用户程序从控制硬件的繁文缛节中解脱出来，而是由 OS 负责控制具体的硬件。第二，OS的代码可以经过充分的测试，从而能使系统更加健壮和可靠。第三，它使用户程序无需在特权级下执行，用户程序无需承担因误操作而瘫痪整个系统的风险。第四，通过 SVC的机制，还让用户程序变得与硬件无关，因此在开发应用程序时无需了解硬件的操作细节，从而简化了开发的难度和繁琐度，并且使应用程序跨硬件平台移植成为可能。开发应用程序唯一需要知道的就是操作系统提供的应用编程接口（API），并且在了解了各个请求代号和参数表后，就可以使用 SVC来提出要求了（事实上，为使用方便，操作系统往往会提供一层封皮，以使系统调用的形式看起来和普通的函数调用一致。各封皮函数会正确使用 SVC 指令来执行系统调用——译者注）。其实，严格地讲，操作硬件的工作是由设备驱动程序完成的，只是对应用程序来说，它们也相当于操作系统的一部分。如图 7.14所示 SVC 异常通过执行”SVC”指令来产生。该指令需要一个立即数，充当系统调用代号。SVC 异常服务例程稍后会提取出此代号，从而获知本次调用的具体要求，再调用相应的服务函数。例如， SVC 0x3 ; 调用3号系统服务 在SVC服务例程执行后，上次执行的 SVC指令地址可以根据自动入栈的返回地址计算出。找到了SVC指令后，就可以读取该 SVC指令的机器码，从机器码中萃取出立即数，就获知了请求执行的功能代号。如果用户程序使用的是 PSP，服务例程还需要先执行 MRS Rn, PSP指令来获取应用程序的堆栈指针。通过分析 LR 的值，可以获知在 SVC 指令执行时，正在使用哪个堆栈（细节在第 8 章中讨论）。 由CM3的中断优先级模型可知，我们不能在 SVC服务例程中嵌套使用 SVC指令（事实上这样做也没意义），因为同优先级的异常不能抢占自身。这种作法会产生一个用法 fault。同理，在 NMI服务例程中也不得使用 SVC，否则将触发硬fault。另一个相关的异常是PendSV（可悬起的系统调用），它和 SVC协同使用。一方面，SVC异常是必须在执行 SVC指令后立即得到响应的（对于 SVC异常来说，若因优先级不比当前正处理的高，或是其它原因使之无法立即响应，将上访成硬 fault——译者注），应用程序执行 SVC 时都是希望所需的请求立即得到响应。另一方面，PendSV 则不同，它是可以像普通的中断一样被悬起的（不像SVC 那样会上访）。OS 可以利用它“缓期执行”一个异常——直到其它重要的任务完成后才执行动作。悬起 PendSV 的方法是：手工往 NVIC的PendSV悬起寄存器中写 1。悬起后，如果优先级不够高，则将缓期等待执行。 PendSV的典型使用场合是在上下文切换时（在不同任务之间切换）。例如，一个系统中有两个就绪的任务，上下文切换被触发的场合可以是：执行一个系统调用系统滴答定时器（SYSTICK）中断，（轮转调度中需要）让我们举个简单的例子来辅助理解。假设有这么一个系统，里面有两个就绪的任务，并且通过SysTick异常启动上下文切换。如图 7.15所示。 上图是两个任务轮转调度的示意图。但若在产生 SysTick 异常时正在响应一个中断，则 SysTick异常会抢占其 ISR。在这种情况下，OS是不能执行上下文切换的，否则将使中断请求被延迟，而且在真实系统中延迟时间还往往不可预知——任何有一丁点实时要求的系统都决不能容忍这种事。因此，在 CM3 中也是严禁没商量——如果 OS 在某中断活跃时尝试切入线程模式，将触犯用法 fault异常。 为解决此问题，早期的 OS 大多会检测当前是否有中断在活跃中，只有在无任何中断需要响应时，才执行上下文切换（切换期间无法响应中断）。然而，这种方法的弊端在于，它可以把任务切换动作拖延很久（因为如果抢占了 IRQ，则本次 SysTick在执行后不得作上下文切换，只能等待下一次SysTick异常），尤其是当某中断源的频率和Sys