@TOC

FreeRTOS任務相關的程式碼大約佔總程式碼的一半左右，這些程式碼都在為一件事情而努力，即找到優先順序最高的就緒任務，並使之獲得CPU執行權。任務切換是這一過程的直接實施者，為了更快的找到優先順序最高的就緒任務，任務切換的程式碼通常都是精心設計的，甚至會用到彙編指令或者與硬體相關的特性，比如Cortex-M3的CLZ指令。因此任務切換的大部分程式碼是由硬體移植層提供的，不同的平臺，實現發方法也可能不同，這篇文章以Cortex-M3為例，講述FreeRTOS任務切換的過程。
FreeRTOS有兩種方法觸發任務切換：

• 執行系統呼叫，比如普通任務可以使用taskYIELD()強制任務切換，中斷服務程式中使用portYIELD_FROM_ISR()強制任務切換；
• 系統節拍時鐘中斷

對於Cortex-M3平臺，這兩種方法的實質是一樣的，都會使能一個PendSV中斷，在PendSV中斷服務程式中，找到最高優先順序的就緒任務，然後讓這個任務獲得CPU執行權，從而完成任務切換。
對於第一種任務切換方法，不管是使用taskYIELD()還是portYIELD_FROM_ISR()，最終都會執行巨集portYIELD()，這個巨集的定義如下：

#define portYIELD()						\
{								\
	/*產生PendSV中斷*/		                        \
	portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;		\
}
 

對於第二種任務切換方法，在系統節拍時鐘中斷服務函式中，首先會更新tick計數器的值、檢視是否有任務解除阻塞，如果有任務解除阻塞的話，則使能PandSV中斷，程式碼如下所示：

void xPortSysTickHandler( void )
{
	/* 設定中斷掩碼 */
	vPortRaiseBASEPRI();
	{
		/* 增加tick計數器值，並檢查是否有任務解除阻塞 */
		if( xTaskIncrementTick() != pdFALSE )
		{
			/* 需要任務切換。產生PendSV中斷 */
			portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;
		}
	}
	vPortClearBASEPRIFromISR();
}
 

從上面的程式碼中可以看出，PendSV中斷的產生是通過程式碼：portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT實現的，它向中斷狀態暫存器bit28位寫入1，將PendSV中斷設定為掛起狀態，等到優先順序高於PendSV的中斷執行完成後，PendSV中斷服務程式將被執行，進行任務切換工作。

Cortex-M3架構下，PendSV中斷服務程式原始碼如下所示，這篇文章重點分析這段程式碼。

__asm void xPortPendSVHandler( void )
{
	extern uxCriticalNesting;
	extern pxCurrentTCB;            /* 指向當前啟用的任務 */
	extern vTaskSwitchContext;      


	PRESERVE8


	mrs r0, psp                   /* PSP內容存入R0 */    
	isb                           /* 指令同步隔離,清流水線 */


	ldr	r3, =pxCurrentTCB     /* 當前啟用的任務TCB指標存入R2 */
	ldr	r2, [r3]


	stmdb r0!, {r4-r11}          /* 儲存剩餘的暫存器,異常處理程式執行前,硬體自動將xPSR、PC、LR、R12、R0-R3入棧 */
	str r0, [r2]		     /* 將新的棧頂儲存到任務TCB的第一個成員中 */


	stmdb sp!, {r3, r14}         /* 將R3和R14臨時壓入堆疊，因為即將呼叫函式vTaskSwitchContext,呼叫函式時,返回地址自動儲存到R14中,所以一旦呼叫發生,R14的值會被覆蓋,因此需要入棧保護; R3儲存的當前啟用的任務TCB指標(pxCurrentTCB)地址,函式呼叫後會用到,因此也要入棧保護*/
	mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY   /* 進入臨界區 */
	msr basepri, r0
	dsb                         /* 資料和指令同步隔離 */
	isb
	bl vTaskSwitchContext        /* 呼叫函式,尋找新的任務執行,通過使變數pxCurrentTCB指向新的任務來實現任務切換 */
	mov r0, #0                   /* 退出臨界區*/
	msr basepri, r0
	ldmia sp!, {r3, r14}         /* 恢復R3和R14*/


	ldr r1, [r3]
	ldr r0, [r1]		     /* 當前啟用的任務TCB第一項儲存了任務堆疊的棧頂,現在棧頂值存入R0*/
	ldmia r0!, {r4-r11}	     /* 出棧*/
	msr psp, r0
	isb
	bx r14                      /* 異常發生時,R14中儲存異常返回標誌,包括返回後進入執行緒模式還是處理器模式、使用PSP堆疊指標還是MSP堆疊指標，當呼叫 bx r14指令後，硬體會知道要從異常返回，然後出棧，這個時候堆疊指標PSP已經指向了新任務堆疊的正確位置，當新任務的執行地址被出棧到PC暫存器後，新的任務也會被執行。*/
	nop
}

為了便於理解上面的程式碼，我們先用流程圖的方式將整個過程畫出來，然後再逐句分析程式碼。因為圖形可以簡化程式，並且資訊更容易接受。

圖1-1：任務切換流程

先強調圖1-1中的幾個術語，首先是“主堆疊指標MSP”和“程序堆疊指標PSP”。對於Cortex-M3硬體，當系統復位後，預設使用MSP指標。MSP指標用於作業系統核心以及處理異常（也就是說中斷服務程式中預設強制使用MSP指標，這是硬體自動設定的）。任務（程序）使用PSP指標，作業系統負責從MSP指標切換到PSP指標。這個過程在《FreeRTOS（15）—FreeRTOS 排程器啟動過程分析》一文的最後部分中進行了講解：在SVC中斷服務程式中啟動第一個任務，當從SVC中斷服務退出前，通過向r14暫存器最後4位按位或上0x0D，使得硬體在退出時使用程序堆疊指標PSP完成出棧操作並返回後進入執行緒模式、返回Thumb狀態。

其次，“堆疊”和“任務堆疊”也值得強調一下。每個任務都有自己的“任務堆疊”，在任務建立時會建立指定大小的任務堆疊，這是任務能夠獨立執行的前提條件之一。在任務中定義的區域性變數，會優先使用暫存器，暫存器不夠時就使用任務堆疊的空間。如果在任務中呼叫其它函式，則呼叫前的儲存資訊也存到任務堆疊中去。根據任務程式碼來估算任務堆疊的大小是件十分重要的技能。前面也說了，Cortex-M3硬體有兩個堆疊指標，作業系統核心以及異常處理程式中使用MSP指標，所以它們也需要一個堆疊空間，我們稱之為“堆疊”，這個堆疊空間和任務堆疊空間在物理上是絕對不可以重疊的，圖1-2展示了一個編譯好的程式可能的RAM分配情況（堆疊向下生長）。

圖1-2：RAM中的變數和堆疊分佈示意圖

有了上面的基礎,接下來我們來分析PendSV中斷服務程式。

mrs r0, psp 

是將任務堆疊指標PSP的值儲存到暫存器R0中，因為接下來我們會將暫存器R4~R11也儲存到任務堆疊中，但是我們沒有哪個彙編指令能直接操作PSP完成入棧，所以只能藉助R0。

ldr	r3, =pxCurrentTCB		    /* 當前啟用的任務TCB指標存入R2 */
ldr	r2, [r3]

這兩句程式碼是獲取當前啟用的任務TCP指標，指標pxCurrentTCB前面文章已經提到過很多次了，它是位於tasks.c檔案中定義的唯一一個全域性指標型變數，指向當前啟用的任務TCB。

stmdb r0!, {r4-r11}

這句程式碼用於將暫存器R4~R11儲存到當前啟用的程式任務堆疊中，並且同步更新暫存器R0的值。

str r0, [r2]

暫存器R2中儲存當前啟用的任務TCB指標，在《 FreeRTOS（14）—FreeRTOS 任務建立分析》中講任務TCB資料結構時我們知道，任務TCB資料結構第一個成員一定是指向任務當前堆疊棧頂的指標變數pxTopOfStack。這句程式碼將R0的內容儲存到任務TCB資料結構的第一個成員pxTopOfStack中，也就是將最新的任務堆疊指標儲存到任務TCB的pxTopOfStack欄位中。當任務被啟用時，就是從這個欄位中獲取任務堆疊指標，然後完成資料出棧操作的。

stmdb sp!, {r3, r14}

將R3和R14臨時壓入堆疊，因為即將呼叫函式vTaskSwitchContext。呼叫函式時，返回地址自動儲存到R14中，所以一旦呼叫發生，R14的值會被覆蓋，因此需要入棧保護。R3儲存的當前啟用的任務TCB指標(pxCurrentTCB)地址，函式呼叫後會用到，因此也要入棧保護。

mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY   
msr basepri, r0

這兩句程式碼用來進入臨界區，中斷優先順序大於等於configMAX_SYSCALL_INTERRUPT_PRIORITY的中斷都會被遮蔽。

bl vTaskSwitchContext

呼叫函式，選擇下一個要執行的任務，也就是尋找處於就緒態的最高優先順序任務。變數pxCurrentTCB指向找到的任務TCB。這個函式是核心中的核心，所有的其它程式碼都是為了保證這個函式能正確執行。

某些執行FreeRTOS的硬體有兩種方法：通用方法和特定於硬體的方法（以下簡稱“特殊方法”）。

1. 對於通用方法：

• configUSE_PORT_OPTIMISED_TASK_SELECTION設定為0或者硬體不支援這種特殊方法。
• 可以用於所有FreeRTOS支援的硬體。
• 完全用C實現，效率略低於特殊方法。
• 不強制要求限制最大可用優先順序數目
  2. 對於特殊方法：
• 並非所有硬體都支援。
• 必須將configUSE_PORT_OPTIMISED_TASK_SELECTION設定為1。
• 依賴一個或多個特定架構的彙編指令（一般是類似計算前導零[CLZ]指令）。
• 比通用方法更高效。
• 一般強制限定最大可用優先順序數目為32（0~31）。

Cortex-M3即支援通用方法也支援特殊方法，預設的移植層使用特殊方法。我們先來看一下通用方法如何找到下一個要執行的任務。

在函式vTaskSwitchContext中使用巨集taskSELECT_HIGHEST_PRIORITY_TASK()完成任務定址工作，使用通用方法時，這個巨集的程式碼如下所示。pxReadyTasksLists是定義在tasks.c中的靜態列表陣列，表示就緒任務列表陣列。在《 FreeRTOS（14）—FreeRTOS 任務建立分析》中講過這個變數：新建立任務的過程中，任務TCB中的狀態列表項xStateListItem會掛接到就緒任務列表陣列中。uxTopReadyPriority也是定義在tasks.c中的靜態變數，在此之前，它已經代表處於就緒態任務的最高優先順序值，在FreeRTOS任務建立與分析一文中，我們也講到了這個變數：每次任務建立，都會判斷新任務的優先順序是否大於這個變數，如果大於，還會更新這個變數的值。

while()迴圈從優先順序uxTopReadyPriority開始，從就緒列表陣列pxReadyTasksLists中找出優先順序最高的任務，然後呼叫巨集listGET_OWNER_OF_NEXT_ENTRY獲取最高優先順序列表中的下一個列表項，並從該列表項中獲取任務TCB指標賦給變數pxCurrentTCB。

	#define taskSELECT_HIGHEST_PRIORITY_TASK()								\
	{																	\
		/* 從就緒列表陣列中找出最高優先順序列表*/				\
		while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) )		\
		{																\
			configASSERT( uxTopReadyPriority );								\
			--uxTopReadyPriority;											\
		}																\
																		\
		/* 相同優先順序的任務使用時間片共享處理器就是通過這個巨集實現*/  	\
		listGET_OWNER_OF_NEXT_ENTRY(pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) );   \
	} /* taskSELECT_HIGHEST_PRIORITY_TASK */

對於Cortex-M3硬體，還支援特殊方法選擇下一個要執行的任務，那就是利用硬體提供的計算前導零指令CLZ。特殊方法時，巨集taskSELECT_HIGHEST_PRIORITY_TASK()的程式碼如下所示。

	#define taskSELECT_HIGHEST_PRIORITY_TASK()								\
	{																	\
	UBaseType_t uxTopPriority;												\
																		\
		/* 從就緒列表陣列中找出最高優先順序列表*/          				\
		portGET_HIGHEST_PRIORITY( uxTopPriority, uxTopReadyPriority );			\
		listGET_OWNER_OF_NEXT_ENTRY(pxCurrentTCB, &( pxReadyTasksLists[ uxTopPriority ] ) ); \
	} /* taskSELECT_HIGHEST_PRIORITY_TASK() */

與通用方法相比，可以發現從就緒列表陣列中找出最高優先順序列表程式碼不同了，特殊方法使用巨集portGET_HIGHEST_PRIORITY來實現，將巨集定義替換後，程式碼為：

uxTopPriority = ( 31UL - ( uint32_t ) __clz( (uxTopReadyPriority) ) )

在此之前，靜態變數uxTopReadyPriority同樣已經包含處於就緒態任務的最高優先順序的資訊。與通用方法中使用任務優先順序數值不同，在特殊方法中，uxTopReadyPriority使用每一位來表示任務，比如變數uxTopReadyPriority的bit0為1，則表示存在優先順序為0的就緒任務，bit10為1則表示存在優先順序為10的就緒任務。由於32位整形數最多隻有32位，因此使用這種特殊方法限定最大可用優先順序數目為32，即優先順序0~31。

我們這來看看__clz( (uxTopReadyPriority)是什麼意思，__clz()會被彙編指令CLZ替換掉，這個指令用來計算一個變數從最高位開始的連續零的個數。舉個例子，假如變數uxTopReadyPriority為0x09（二進位制為：0000 0000 0000 0000 0000 0000 0000 1001），即bit3和bit0為1，表示存在優先順序為0和3的就緒任務。則__clz( (uxTopReadyPriority)的值為28，uxTopPriority =31-28=3，即優先順序為3的任務是就緒態最高優先順序任務。下面的程式碼跟通用方法一樣，呼叫巨集listGET_OWNER_OF_NEXT_ENTRY獲取最高優先順序列表中的下一個列表項，並從該列表項中獲取任務TCB指標賦給變數pxCurrentTCB。

mov r0, #0                   /* 退出臨界區*/
msr basepri, r0

這兩句程式碼用來退出臨界區，通過向暫存器BASEPRI寫入數值0來實現。

ldmia sp!, {r3, r14}

這句程式碼將暫存器R3和R14從堆疊中恢復，現在R3儲存變數pxCurrentTCB的地址，需要注意的是，變數pxCurrentTCB在函式vTaskSwitchContext中可能已被修改，指向新的最高優先順序就緒任務；R14儲存退出異常需要的資訊。

ldr r1, [r3]
ldr r0, [r1]	

這兩句程式碼獲取變數pxCurrentTCB指向的任務TCB指標，並將TCB的第一個成員——當前堆疊棧頂的指標變數pxTopOfStack的值儲存到暫存器R0中，也就是將即將執行的任務堆疊棧頂值存入R0。

ldmia r0!, {r4-r11}

將暫存器R4~R11出棧，並同時更新R0的值。

msr psp, r0

將最新的任務堆疊棧頂賦值給執行緒堆疊指標PSP。

bx r14

從異常中斷服務程式退出。異常發生時，R14中儲存異常返回標誌，包括返回後進入執行緒模式還是處理器模式、使用PSP堆疊指標還是MSP堆疊指標。當呼叫 bx r14指令後，硬體會知道要從異常返回，然後出棧，這個時候堆疊指標PSP已經指向了新任務堆疊的正確位置，當新任務的執行地址被出棧到PC暫存器後，新的任務也會被執行。

至此，任務切換完成。