FreeRTOS中任务切换过程中遇到中断会怎么样
最近在移植freeRTOS，发现一个问题，freeRTOS为了保证实时性，是通过basepri来屏蔽优先级高的中断，那如果FreeRTOS中任务切换过程中遇到中断会怎么样？
比如在压栈中刚好中断，会不会有问题？ 优先级再高，也得等人家保存现场之后，再去你执行高优先级的中断吧。我猜的 （逃 压栈的时候应该是关闭所有中断。完成后再打开总的中断开关。 查了一下资料，参考cortex-m3
在《Cortex-M3 Devices Generic User Guide.pdf》中介绍了异常入栈和出栈的情况，详见2.3 Exception model。Cortex-M3内核的寄存器如下。
异常发生时，入栈的寄存器是R0~R3+R12+PC+LR+SP。为啥袒护R0‐R3以及R12呢， R4‐R11就是下等公民？（摘自《Cortex-M3权威指南 》第9章）
原来，在ARM上，有一套的C函数调用标准约定（《 C/C++ rocedure Call Standard for the ARM Architecture》，AAPCS, Ref5）。个中原因就在它上面：它使得中断服务例程能用C语言编写，编译器优先使用被入栈的寄存器来保存中间结果（当然，如果程序过大也可能要用到R4‐R11，此时编译器负责生成代码来push它们。但是， ISR应该短小精悍，不要让系统如此操心——译者注）。如果读者再仔细看，会发现R0‐R3, R12是最后被压进去的。这里也有一番良苦用心：为的是可以更容易地使用SP基址来索引寻址，（ 以及为了LDM等多重加载指令，因为LDM必须加载地址连续的一串数据）。参数的传递也是受益者：使之可以方便地通过压入栈的R0‐R3取出（ 主要为系统软件所利用，多见于SVC与PendSV中的参数传递）。
这就是说，C编译器中断（异常）服务函数封装的这样的需求：当R0~R3+R12不够用时会使用R4‐R11，在使用R4‐R11之前会进行入栈保护；在使用完之后进行出栈恢复现场。
看来c语言和汇编在中断服务函数中是不一样的 这是RTOS最核心的问题之一，如何处理这个问题是评价一个RTOS实时响应性能的关键。一个RTOS性能的好坏，从它的“任务（线程）切换程序”就能看出大概。
严格来说，把内核关中断的OS称之为RTOS是名不符实的。都关中断了，还有啥实时性可言。
嵌套向量、入栈出栈抢占、未尾连锁……ARM 费尽心机千辛万苦把 Cortex-M 的中断响应等待时间缩短到引以为豪的6个周期，就是为了适合嵌入式系统的实时快速响应要求，你们把中断说关就关，这对得起ARM吗，对得起自己良心吗{:titter:}
页:
[1]