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运行时，它们将调用安全的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 reertos assertion), so there will be no accident.

那么，你一定会问，中断1~3呢，会被阻塞吗？答案是：不会。那么他们会调用安全的freertos api，上面提到的事故就不会发生吗？这是我最近遇到的问题，现在我知道答案了。 FreeRTOS中有一个MAX_SYSCALL_INTERRPUT_PRIORITY机制。 MAX_SYSCALL_INTERRPUT_PRIORITY以上的中断将不允许你调用安全的freertos api（如果调用的话，由于reertos断言的存在，代码将不会通过编译），所以不会出现意外。

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

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