FreeRTOS 中断配置和临界段是整个 FreeRTOS 移植和使用中最关键、最容易出错的部分之一。我们从 Cortex-M 硬件机制讲起逐层深入到 FreeRTOS 的配置宏、开关中断实现、临界段保护最后通过实验验证。一、Cortex-M 中断基础硬件层面要理解 FreeRTOS 的中断配置首先得掌握 Cortex-M 内核如 STM32的中断管理机制。1. NVIC 与中断优先级NVIC嵌套向量中断控制器管理所有外部中断和系统异常。每个中断有一个8 位优先级寄存器但实际使用多少位由芯片厂商决定。STM32 只使用了高 4 位因此有 16 个优先级0~15数值越小优先级越高。优先级分组PRIGROUP将优先级分为“抢占优先级”和“子优先级”两部分。FreeRTOS强制要求使用分组 4即所有 4 位全部作为抢占优先级没有子优先级。这样做的目的是简化中断管理避免子优先级带来的复杂性。ST 的 HAL 库在HAL_Init()中默认设置的就是NVIC_PRIORITYGROUP_4见图 5.1.2所以使用 HAL 库时通常不需要修改。但如果从其他非 FreeRTOS 例程移植代码务必检查并统一为分组 4。2. 三个关键的中断屏蔽寄存器寄存器作用FreeRTOS 使用情况PRIMASK屏蔽除 NMI 和 HardFault 外的所有中断μC/OS 常用FreeRTOS不用FAULTMASK比 PRIMASK 更强连 HardFault 都能屏蔽FreeRTOS不用BASEPRI屏蔽优先级低于某个阈值的中断更精细的控制FreeRTOS 使用这是核心重点理解BASEPRI向它写入一个数值比如 5则所有优先级数值大于等于 5的中断都会被屏蔽而优先级为 0~4 的高优先级中断不受影响。这种“选择性屏蔽”非常适合 RTOS——既要保护临界区又不能耽误高优先级实时中断。二、FreeRTOS 中断配置宏软件层面FreeRTOS 通过FreeRTOSConfig.h中的几个宏来配置中断行为。这些宏容易混淆我们逐一理清宏名称示例值STM32含义与用途configPRIO_BITS4MCU 实际使用的优先级位数。STM32 用 4 位所以为 4。configLIBRARY_LOWEST_INTERRUPT_PRIORITY15用户视角的最低优先级即数值 15。configKERNEL_INTERRUPT_PRIORITY15 (8-4) 0xF0写入寄存器时使用的值。因为优先级只存在高 4 位需要左移 4 位。用于设置 PendSV 和 SysTick 的中断优先级设为最低。configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY5用户视角的“系统调用最大优先级阈值”。优先级数值小于 5 的中断不受 FreeRTOS 屏蔽。configMAX_SYSCALL_INTERRUPT_PRIORITY5 4 0x50写入 BASEPRI 寄存器时使用的值。用于开关中断时屏蔽“低于此优先级”的中断。关键结论图 5.1.3 的核心优先级 0~4高于阈值不会被 FreeRTOS 关中断屏蔽。这些中断绝对实时但不能在 ISR 中调用任何 FreeRTOS API 函数因为 API 可能被屏蔽导致不可预知。优先级 5~15低于或等于阈值会被 FreeRTOS 关中断屏蔽。这些中断可以安全调用FromISR版本的 API如xQueueSendFromISR。PendSV 和 SysTick被设为最低优先级 15确保所有外设中断都能优先于内核服务。为什么优先级值要左移 4 位因为 STM32 只使用了优先级寄存器的高 4 位低 4 位不存在读回 0。所以写入寄存器时必须将优先级值左移 4 位让它对齐到高 4 位。例如优先级 5 在寄存器中实际写入的是0x50优先级 15 写入的是0xF0。PendSV 和 SysTick 优先级设置详解从xPortStartScheduler()源码可以看到FreeRTOS 通过直接操作地址0xE000ED20即portNVIC_SYSPRI2_REG一次性写入 32 位数据其中SysTick 优先级对应最高 8 位左移 24 位PendSV 优先级对应次高 8 位左移 16 位两者都被设置为最低优先级15确保任务切换发生在所有外设中断之后。三、FreeRTOS 开关中断的实现机制有了上面的基础开关中断的实现就一目了然了。1. 关中断portDISABLE_INTERRUPTS()实际执行的是ulNewBASEPRIconfigMAX_SYSCALL_INTERRUPT_PRIORITY;// 0x50msr basepri,ulNewBASEPRI效果所有优先级 ≥ 5 的中断被屏蔽优先级 0~4 的中断继续响应。2. 开中断portENABLE_INTERRUPTS()实际执行的是vPortSetBASEPRI(0);// 向 BASEPRI 写入 0效果取消所有屏蔽所有中断恢复正常。为什么不用 PRIMASK因为 BASEPRI 更灵活允许高优先级中断如电机控制、紧急停机的 IO 中断在临界区中依然得到及时响应这是 RTOS 实时性的重要保障。四、临界段代码保护应用层面临界段是“必须完整执行、不能被中断打断”的代码区域。FreeRTOS 提供了两种保护方式区别在于调用上下文。1. 任务级临界段taskENTER_CRITICAL()/taskEXIT_CRITICAL()在任务代码中使用不能在中断中使用。支持嵌套通过全局变量uxCriticalNesting记录嵌套深度。只有最外层的EXIT才会真正开中断内层的EXIT只减少计数。这在复杂函数调用中非常有用避免过早开中断破坏内层临界区的保护。使用原则临界区代码要尽可能短因为关中断会影响系统实时性即使只屏蔽低优先级中断。典型用法taskENTER_CRITICAL();// 操作共享资源如全局变量、外设配置total_num0.01f;printf(total_num %.4f\n,total_num);taskEXIT_CRITICAL();2. 中断级临界段taskENTER_CRITICAL_FROM_ISR()/taskEXIT_CRITICAL_FROM_ISR()在中断服务函数中使用且该中断的优先级必须低于configMAX_SYSCALL_INTERRUPT_PRIORITY。用法有区别进入函数时会返回当前 BASEPRI 的值退出时必须将返回值作为参数传入以恢复之前的中断屏蔽状态。这保证了嵌套中断场景下中断屏蔽状态能正确还原。为什么返回值很重要假如中断 A 被更高优先级的中断 B 抢占B 中又调用了临界段那么退出 B 时必须恢复到 A 的中断屏蔽状态而不是简单打开中断。返回值机制确保了这个恢复过程的正确性。正确用法voidHAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef*htim){uint32_tstatus_value;status_valuetaskENTER_CRITICAL_FROM_ISR();// 保存当前 BASEPRI// 操作共享资源taskEXIT_CRITICAL_FROM_ISR(status_value);// 恢复保存的 BASEPRI}五、中断测试实验深度解析验证理论实验设计TIM3优先级设为 4高于阈值每秒打印 “TIM3 output…”。TIM5优先级设为 5等于阈值每秒打印 “TIM5 output…”。任务interrupt_task运行 5 次后调用portDISABLE_INTERRUPTS()关闭中断延时 5 秒再调用portENABLE_INTERRUPTS()打开中断。实验结果与结论关中断前两个定时器都正常输出。关中断期间5 秒TIM3优先级 4继续输出—— 因为它不受 BASEPRI 屏蔽。TIM5优先级 5停止输出—— 因为它被 BASEPRI 屏蔽了。重新开中断后TIM5 恢复输出。这个实验完美验证了configMAX_SYSCALL_INTERRUPT_PRIORITY这个阈值确实将中断分成了“不可屏蔽的高实时通道”和“可屏蔽的普通通道”。这为实际项目中选择中断优先级提供了清晰的依据。六、核心要点总结与实践建议要点说明优先级分组必须是 4在HAL_Init()中已设置不要改动。阈值configMAX_SYSCALL_INTERRUPT_PRIORITY是分水岭高于它的中断可以响应但不能调用 API低于或等于它的中断可以调用 API但会被临界段屏蔽。PendSV 和 SysTick 优先级必须最低FreeRTOS 内核依赖它们进行任务切换和时间管理。临界区代码要极短进入临界区会关中断即使只关一部分过长会影响系统实时性。任务级与中断级临界段函数不可混用在任务中用taskENTER_CRITICAL()在 ISR 中用taskENTER_CRITICAL_FROM_ISR()并注意返回值传递。中断优先级设置要避开临界区如果你有一个极端重要的中断比如故障保护把它设为 0~4并确保它的 ISR 不调用任何 FreeRTOS API。七、与 SVC 和内核态/用户态的关联在标准 FreeRTOS无 MPU中所有中断和任务都运行在特权态SVC 只用于启动第一个任务。开关中断BASEPRI 操作是全局的影响所有低于阈值的任务和中断。在启用 MPU 的 FreeRTOS 中用户态任务通过 SVC 陷入内核态调用 API。此时中断配置逻辑不变但configMAX_SYSCALL_INTERRUPT_PRIORITY阈值同样决定了哪些中断可以“穿透”临界区哪些会被屏蔽。高优先级中断0~4即使在用户态任务执行时也能响应但它们的 ISR 仍然不能调用 FreeRTOS API因为可能访问内核数据触发 MPU 错误。