FreeRTOS学习笔记--临界段代码处关闭中断

一、临界段代码

大家在学习FreeRTOS时对临界段代码都不陌生，引用野火实战指南的一句话：“临界段代码是指不能被中断的代码”。实际上，不只在进行全局操作的代码需要对中断进行管控，在某些严格时序上也需要对中断进行管控。例如A任务需要利用IIC、SPI、并口等协议进行数据交互时，往往一个中断的到来就会使得时序紊乱，而导致通信失败。所以我们在执行这类代码时，需要将不必要的中断进行屏蔽，这就涉及到部分M4内核的中断管理。

二、Cortex-M4中断管理

ARM公司在设计M4内核时就配置了255个异常，其中又分为异常和中断。
实际上，区分异常和中断比较简单，MCU提出的中断申请叫做异常（系统异常），若是外部端口或者芯片设计商挂载的外设提出的中断申请则成为中断。
为了方便管理，ARM固化了部分异常。而芯片设计商根据已有的嵌套中断向量表（NVIC）并结合芯片使用的实际情况对中断进行裁剪后固化嵌套中断向量表（NVIC）。
ARM在设计NVIC时，也配套了优先级屏蔽寄存器(PRIMASK)，该寄存器存放在内核寄存器中

该寄存器用于关闭除了NMI和HardFulat异常以外的所有中断，也可以使用错误屏蔽寄存器(FAULTMASK)来屏蔽除了NMI以外的所有中断。但这样的代价比较大，若在任务中出现异常时，系统将无法进行补救，那么系统会出现跑飞等异常现象。

在FreeRTOS中，经常使用基本优先级屏蔽寄存器，该寄存器用于定义可屏蔽的最高的优先级。
这是由于在Cortex-M4中定义优先级越小优先级越高，这与优先级分组管理是相关的。于是在使用中，当我们需要屏蔽优先级不高于5的中断时，可以向该寄存器写入5。
实际上芯片生产商在拿到内核后，会对优先级组(NVIC_IPRx)进行裁剪，又由于上述说的优先级规则，所以优先级组是先裁剪低位，例如STM32F4xx系列单片机是裁剪掉了低4位，只用高4位来配置抢占、次要优先级。所以我们在屏蔽优先级为5以下的中断时需要进行位移操作。

#ifdef __NVIC_PRIO_BITS
	#define configPRIO_BITS       		__NVIC_PRIO_BITS
#else
	#define configPRIO_BITS       		4                  
#endif

#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY				15                      //中断最低优先级
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY		5                       //系统可管理的最高中断优先级
#define configKERNEL_INTERRUPT_PRIORITY 		( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 	( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )

static portFORCE_INLINE void vPortRaiseBASEPRI( void )
{
uint32_t ulNewBASEPRI = configMAX_SYSCALL_INTERRUPT_PRIORITY;

	__asm
	{
		/* Set BASEPRI to the max syscall priority to effect a critical
		section. */
		msr basepri, ulNewBASEPRI
		dsb
		isb
	}
}

static portFORCE_INLINE void vPortSetBASEPRI( uint32_t ulBASEPRI )		
{	
	/* Usually,the value of the ulBASEPRI equals 0 . */
	__asm
	{
		/* Barrier instructions are not used as this function is only used to
		lower the BASEPRI value. */
		msr basepri, ulBASEPRI
	}
}

三、中断屏蔽实验

为了对上诉两个函数进行验证，设计了中断屏蔽实验，开启两个定时器，一个优先为4，一个为5。创建一个中断屏蔽任务，调度周期为1s。在数秒后屏蔽优先级不高于5的中断，再过数秒后重新开启中断。定时器中断处理函数中将会打印运行信息。

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
   if(htim==(&htim3_Hander))
  {
		Tim3_Count++;
		if(Tim3_Count == 250)
		{
			Tim3_Count = 0;
		}
        printf("TIM3输出.......\r\n");
  }
	else if(htim==(&htim4_Hander))
	{
		printf("TIM4输出.......\r\n");
	}
}
void Task1_Static(void *pvParameters)
{
    while(1)
    {
			TimeCount++;
			printf("Task1运行次数为: %d\r\n",Task1_RunTimeCount);
       		LED0=~LED0;
			if(Tim3_Count == 15)
			{
				printf("关闭中断\r\n");
				portDISABLE_INTERRUPTS();			//关闭中断
			}
			else if (Tim3_Count == 25)
			{
				printf("开启中断\r\n");			
				portENABLE_INTERRUPTS();			//开启中断
				
			}
				vTaskDelay(1000);
			}
}   

根据实验设计原理，实验将出现以下结果：

1. 程序开始运行时，串口调试助手将会打印出
   TIM3输出…
   TIM4输出…

2. 程序运行15s后，串口调试助手将会打印出
   关闭中断

3. 此后10s内，串口调试助手只会打印出
   TIM3输出…

4. 程序运行25s后，串口调试助手将会打印出
   TIM3输出…
   TIM4输出…

但在实验时，序号3的结果未出现，仍然打印出序号1、4的内容。进入Debug模式，发现TIM4的中断并没有处于挂起状态。
经过多方面的调试，终于确认，在系统调度函数过程中会重新打开中断。所以才会出现中断没有被屏蔽的错觉。调试方法：在关闭中断处打断点，程序运行到此处后，在函数vPortSetBASEPRI()中打断点。全速运行，发现程序进入了该断点。
个人猜测：系统调度时会执行临界段代码，所以会先关闭中断，在执行完后，再次打开中断。故任务中关闭的中断并没有起效。
基于目前所知的信息，为了实现中断屏蔽，只能在关闭中断后进行不产生调度的延时操作。

void Task1_Static(void *pvParameters)
{
    while(1)
    {
			Task1_RunTimeCount++;
			printf("Task1运行次数为: %d\r\n",Task1_RunTimeCount);
		    LED0=~LED0;
			if(Tim3_Count == 15)
			{
				printf("关闭中断\r\n");
				portDISABLE_INTERRUPTS();			//关闭中断
				delay_xms(5000);					//纯延时
				portENABLE_INTERRUPTS();			//可有可无
			}
//			else if (Tim3_Count == 25)
//			{
//				printf("开启中断\r\n");			
//				portENABLE_INTERRUPTS();			//关闭中断
//				
//			}
				vTaskDelay(1000);
	}
}   

实验效果正常，在关闭终端后，TIM4处于挂起状态。

四、结语

经过本次实验，可以一定程度上了解Cortex-M4内核的中断机制以及FreeRTOS屏蔽中断的操作。对于目前的结果来看，FreeRTOS只能在任务内进行屏蔽中断操作，一旦任务产生调度，中断则会被重新打开。当然这已经满足在任务内进行时序通信！也可以深入FreeRTOS内核，在调度函数中进行修订。是否可以函数压入栈的时候将当前BASEPRI寄存器的值同时压入栈。当系统调度到该任务时根据相关值配置BASEPRI寄存器？