本文用于记录学习freertos过程中的configASSERT( ucCurrentPriority >= ucMaxSysCallPriority )故障。所有思路基本上都在下面的文章中表述清楚https://blog.csdn.net/sinat_23338865/article/details/52640028，在此我仅仅记录我个人的理解。
freertos为了便于管理，划定了一些低优先级的中断受其管理，操作系统可以通过函数挂起中断或暂时关闭中断，从而可以把低优先级的中断和操作系统的API统一管理。在cube生成的底层文件中，对于划定界限以及相关操作的描述如下
大概的意思是说，如果需要在中断中调用操作系统的API函数，那该中断的优先级需要≥configMAX_SYSCALL_INTERRUPT_PRIORITY。但在keil的底层定义中发现configMAX_SYSCALL_INTERRUPT_PRIORITY=0x50，而网友却说这个是0x05。定义如下
虽然通过定义看configMAX_SYSCALL_INTERRUPT_PRIORITY=0x50，但是只要稍微了解STM32的M4内核就知道，内部的中断优先级寄存器被阉割成了4位，即仅保留了高4位（寄存器为8位），因此，虽然左移4位，但是对于我们来说系统可操作中断界限扔为5。
