记录.freeRtos系统在中断中恢复挂起的线程总是不是实时的恢复而是延后了一段时间

一、问题

        在编程时发现，一个线程的响应总是落后于某个外部信号。这个外部信号使用中断捕抓，然后恢复一个运行一次会挂起自身的线程。但是在测试中发现，该线程的响应总是落后于该外部信号从0ms-10ms的一个范围。

二、思考

        - 思考：在freeRtos中函数后缀带ISR的会不会跟正常的API函数不一样？

        - 看官方的应用文档发现多调用了一个API

        - 这个API有什么用：强制任务切换与调度

        - 那是怎么实现切换的：只要xTaskResumeFromISR( xHandle ); 返回真，那么就会调用一段程序：给地址空间为“ 0xe000ed04 ”的地方覆盖上“ 1<<28 ”的值。

        - 0xe000ed04迷思：这个地址空间里存放的其实是Cortex-m内核的中断控制和状态寄存器的指针。具体可以看看这个博文Cortex内核_0xe000ed04-优快云博客

        - 为什么往中断控制与状态寄存器写" 1<<28 "：下图是cortex-m4权威指南里对该寄存器的详细说明：可以看出，除了bit28写1外，其他全部清零。线索到这里就断了，我仍不知道portYIELD()函数以及portYIELD_FROM_ISR()是如何强制切换任务以及调度的。

三、解决

        - 从上面的思考中我们发现，在中断中恢复线程时需要用portYIELD_FROM_ISR()做一次强制切换。所以可知xTaskResumeFromISR()并没有释放cpu的执行权或者中断结束后释放cpu的执行权。也就是执行任务切换。

四、新问题

        - 在中断执行完毕后，按道理以抢占式FreeRTOS系统应该会根据自己设置的心跳时间去恢复当前就绪的高优先级线程。而我的对外部变量做出处理的那线程是最高优先级的了，而且我心跳设置为1次/ms。为什么会有等待10ms后线程才响应的情况，最差情况下也只有1ms才对啊。

        - 待续