FreeRTOS LIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 存在的意义以及高于它的中断不能调用 safe freertos api

This is how I understand it.

我是这样理解的。

If we now have 2 tasks and 6 interrupts, among which, and when interrupts 4, 5, 6 are running, they will call the safe freertos api.

假如我们现在有2个任务以及6个中断，其中，中断4、5、6运行的时候将会调用 safe freertos api。

Just like (1) in the picture.

就像图中的（1）一样。

So now if we are executing task 1 or task 2, interrupt 5 is triggered, and it will do what it needs to do in the callback, including calling the safe freertos api, and during the execution, it will enter the critical section to block all interrupts and tasks with a lower priority than it (for now, let’s not consider the MAX_SYSCALL_INTERRPUT_PRIORITY mechanism in FreeRTOS, that is, it will not block interrupts 1~4).

那么现在假如我们正在执行任务1或任务2，此时中断5触发，在回调中会执行它需要做的，包含调用 safe freertos api，并在执行过程中会进入临界段屏蔽所有低于它优先级的中断和任务（现在先不考虑 FreeRTOS 中的 MAX_SYSCALL_INTERRPUT_PRIORITY 机制，也就是它不会屏蔽中断1~4）。

Just like (2) in the picture.

就像图中的（2）一样。

Moving forward, when interrupt 5 calls the safe freertos api and is in the process of execution, interrupt 4 is triggered at this time, it will preempt interrupt 5 execution, and further call the safe freertos api. At this time, I guess that interrupt 5 involves the operation of the freertos kernel (because of preemption, only half of it is executed) will lose protection, causing serious irreversible effects (there may be problems with context scheduling and task management).

继续前进，当中断5调用 safe freertos api，并在执行过程中时，这个时候中断4触发，它将会抢占中断5执行，进一步也将调用 safe freertos api，这个时候我猜测中断5涉及freertos内核的操作（因为抢占，仅执行了一半）将会失去保护，造成严重的不可逆的影响（可能有上下文调度、任务管理的问题）。

Just like (3) in the picture.

就像图中的（3）一样。

So now let’s go back to the beginning. If there is MAX_SYSCALL_INTERRPUT_PRIORITY in FreeRTOS The mechanism exists. During the execution of interrupt 5, all interrupts below MAX_SYSCALL_INTERRPUT_PRIORITY will be blocked, so the accident caused by the interrupt 4 preemption execution mentioned above will not happen.

那么现在让我们回到一开始的地方，如果有FreeRTOS 中的 MAX_SYSCALL_INTERRPUT_PRIORITY 机制存在，在中断5执行过程中，会屏蔽低于 MAX_SYSCALL_INTERRPUT_PRIORITY 的所有中断，也就不会发生我前面说过的中断4抢占执行造成的事故。

Just like (4) in the picture.

就像图中的（4）一样。

Then, you will definitely ask, what about interrupts 1~3, will they be blocked? The answer is: No. Then will they call the safe freertos api and the above mentioned accident will not happen? This is the problem I encountered recently, and now I know the answer. There is a MAX_SYSCALL_INTERRPUT_PRIORITY mechanism in FreeRTOS. Interrupts above MAX_SYSCALL_INTERRPUT_PRIORITY will not allow you to call the safe freertos api (if you call it, the code will not pass the compilation due to the existence of the Freertos assert), so there will be no accident.

那么，你肯定会问，中断1~3呢，它们会被屏蔽吗？答案是：不会。那么它们调用 safe freertos api 不会发生上面说的事故吗？这个就是我最近遇到的问题，现在也知道了答案。有FreeRTOS 中的 MAX_SYSCALL_INTERRPUT_PRIORITY 机制存在，高于 MAX_SYSCALL_INTERRPUT_PRIORITY 的中断将会不允许你调用 safe freertos api（如果你调用，会因为Freertos断言 存在导致代码不会通过编译），也就不会发生事故。

This is my own understanding. If you find any errors, please leave a message to reply.

这是我个人的理解。如果发现错误，请留言回复。