FreeRTOS任務切換分析
系統調用莫非是把用戶任務轉爲系統/內核任務所以發生了任務切換？
我覺得最有用的是這幾句話
FreeRTOS任務相關的代碼大約佔總代碼的一半左右，這些代碼都在爲一件事情而努力，即找到優先級最高的就緒任務，並使之獲得CPU運行權。任務切換是這一過程的直接實施者，爲了更快的找到優先級最高的就緒任務，任務切換的代碼通常都是精心設計的，甚至會用到彙編指令或者與硬件相關的特性，比如Cortex-M3的CLZ指令。因此任務切換的大部分代碼是由硬件移植層提供的，不同的平臺，實現發方法也可能不同，這篇文章以Cortex-M3爲例，講述FreeRTOS任務切換的過程。
FreeRTOS有兩種方法觸發任務切換：
- 執行系統調用，比如普通任務可以使用taskYIELD()強制任務切換，中斷服務程序中使用portYIELD_FROM_ISR()強制任務切換；
- 系統節拍時鐘中斷
對於Cortex-M3平臺，這兩種方法的實質是一樣的，都會使能一個PendSV中斷，在PendSV中斷服務程序中，找到最高優先級的就緒任務，然後讓這個任務獲得CPU運行權，從而完成任務切換。
對於第一種任務切換方法，不管是使用taskYIELD()還是portYIELD_FROM_ISR()，最終都會執行宏portYIELD()
對於第二種任務切換方法，在系統節拍時鐘中斷服務函數中，首先會更新tick計數器的值、查看是否有任務解除阻塞，如果有任務解除阻塞的話，則使能PandSV中斷
摘自：https://blog.csdn.net/qingzhuyuxian/article/details/80604129
FreeRTOS任務相關的代碼大約佔總代碼的一半左右，這些代碼都在爲一件事情而努力，即找到優先級最高的就緒任務，並使之獲得CPU運行權。任務切換是這一過程的直接實施者，爲了更快的找到優先級最高的就緒任務，任務切換的代碼通常都是精心設計的，甚至會用到彙編指令或者與硬件相關的特性，比如Cortex-M3的CLZ指令。因此任務切換的大部分代碼是由硬件移植層提供的，不同的平臺，實現發方法也可能不同，這篇文章以Cortex-M3爲例，講述FreeRTOS任務切換的過程。
FreeRTOS有兩種方法觸發任務切換：
- 執行系統調用，比如普通任務可以使用taskYIELD()強制任務切換，中斷服務程序中使用portYIELD_FROM_ISR()強制任務切換；
- 系統節拍時鐘中斷
對於Cortex-M3平臺，這兩種方法的實質是一樣的，都會使能一個PendSV中斷，在PendSV中斷服務程序中，找到最高優先級的就緒任務，然後讓這個任務獲得CPU運行權，從而完成任務切換。
對於第一種任務切換方法，不管是使用taskYIELD()還是portYIELD_FROM_ISR()，最終都會執行宏portYIELD()，這個宏的定義如下：
[objc] view plain copy
- #define portYIELD() \
- { \
- /*產生PendSV中斷*/ \
- portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT; \
- }
對於第二種任務切換方法，在系統節拍時鐘中斷服務函數中，首先會更新tick計數器的值、查看是否有任務解除阻塞，如果有任務解除阻塞的話，則使能PandSV中斷，代碼如下所示：
[objc] view plain copy
- 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中斷服務程序源碼如下所示，這篇文章重點分析這段代碼。
[objc] view plain copy
- __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高級篇3---啓動調度器》一文的最後部分中進行了講解：在SVC中斷服務程序中啓動第一個任務，當從SVC中斷服務退出前，通過向r14寄存器最後4位按位或上0x0D，使得硬件在退出時使用進程堆棧指針PSP完成出棧操作並返回後進入線程模式、返回Thumb狀態。
其次，「堆棧」和「任務堆棧」也值得強調一下。每個任務都有自己的「任務堆棧」，在任務創建時會創建指定大小的任務堆棧，這是任務能夠獨立運行的前提條件之一。在任務中定義的局部變量，會優先使用寄存器，寄存器不夠時就使用任務堆棧的空間。如果在任務中調用其它函數，則調用前的保存信息也存到任務堆棧中去。根據任務代碼來估算任務堆棧的大小是件十分重要的技能。前面也說了，Cortex-M3硬件有兩個堆棧指針，操作系統內核以及異常處理程序中使用MSP指針，所以它們也需要一個堆棧空間，我們稱之爲「堆棧」，這個堆棧空間和任務堆棧空間在物理上是絕對不可以重疊的，圖1-2展示了一個編譯好的程序可能的RAM分配情況（堆棧向下生長）。
圖1-2：RAM中的變量和堆棧分佈示意圖
有了上面的基礎,接下來我們來分析PendSV中斷服務程序。
[objc] view plain copy
- mrs r0, psp
是將任務堆棧指針PSP的值保存到寄存器R0中，因爲接下來我們會將寄存器R4~R11也保存到任務堆棧中，但是我們沒有哪個彙編指令能直接操作PSP完成入棧，所以只能藉助R0。
[objc] view plain copy
- ldr r3, =pxCurrentTCB /* 當前激活的任務TCB指針存入R2 */
- ldr r2, [r3]
這兩句代碼是獲取當前激活的任務TCP指針，指針pxCurrentTCB前面文章已經提到過很多次了，它是位於tasks.c文件中定義的唯一一個全局指針型變量，指向當前激活的任務TCB。
[objc] view plain copy
- stmdb r0!, {r4-r11}
這句代碼用於將寄存器R4~R11保存到當前激活的程序任務堆棧中，並且同步更新寄存器R0的值。
[objc] view plain copy
- str r0, [r2]
寄存器R2中保存當前激活的任務TCB指針，在《FreeRTOS高級篇2---FreeRTOS任務創建分析》中講任務TCB數據結構時我們知道，任務TCB數據結構第一個成員一定是指向任務當前堆棧棧頂的指針變量pxTopOfStack。這句代碼將R0的內容保存到任務TCB數據結構的第一個成員pxTopOfStack中，也就是將最新的任務堆棧指針保存到任務TCB的pxTopOfStack字段中。當任務被激活時，就是從這個字段中獲取任務堆棧指針，然後完成數據出棧操作的。
[objc] view plain copy
- stmdb sp!, {r3, r14}
將R3和R14臨時壓入堆棧，因爲即將調用函數vTaskSwitchContext。調用函數時，返回地址自動保存到R14中，所以一旦調用發生，R14的值會被覆蓋，因此需要入棧保護。R3保存的當前激活的任務TCB指針(pxCurrentTCB)地址，函數調用後會用到，因此也要入棧保護。
[objc] view plain copy
- mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY
- msr basepri, r0
這兩句代碼用來進入臨界區，中斷優先級大於等於configMAX_SYSCALL_INTERRUPT_PRIORITY的中斷都會被屏蔽。
[objc] view plain copy
- 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高級篇2---FreeRTOS任務創建分析》中講過這個變量：新創建任務的過程中，任務TCB中的狀態列表項xStateListItem會掛接到就緒任務列表數組中。uxTopReadyPriority也是定義在tasks.c中的靜態變量，在此之前，它已經代表處於就緒態任務的最高優先級值，在FreeRTOS任務創建與分析一文中，我們也講到了這個變量：每次任務創建，都會判斷新任務的優先級是否大於這個變量，如果大於，還會更新這個變量的值。
while()循環從優先級uxTopReadyPriority開始，從就緒列表數組pxReadyTasksLists中找出優先級最高的任務，然後調用宏listGET_OWNER_OF_NEXT_ENTRY獲取最高優先級列表中的下一個列表項，並從該列表項中獲取任務TCB指針賦給變量pxCurrentTCB。
[objc] view plain copy
- #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()的代碼如下所示。
[objc] view plain copy
- #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來實現，將宏定義替換後，代碼爲：
[objc] view plain copy
- 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。
[objc] view plain copy
- mov r0, #0 /* 退出臨界區*/
- msr basepri, r0
這兩句代碼用來退出臨界區，通過向寄存器BASEPRI寫入數值0來實現。
[objc] view plain copy
- ldmia sp!, {r3, r14}
這句代碼將寄存器R3和R14從堆棧中恢復，現在R3保存變量pxCurrentTCB的地址，需要注意的是，變量pxCurrentTCB在函數vTaskSwitchContext中可能已被修改，指向新的最高優先級就緒任務；R14保存退出異常需要的信息。
[objc] view plain copy
- ldr r1, [r3]
- ldr r0, [r1]
這兩句代碼獲取變量pxCurrentTCB指向的任務TCB指針，並將TCB的第一個成員——當前堆棧棧頂的指針變量pxTopOfStack的值保存到寄存器R0中，也就是將即將運行的任務堆棧棧頂值存入R0。
[objc] view plain copy
- ldmia r0!, {r4-r11}
將寄存器R4~R11出棧，並同時更新R0的值。
[objc] view plain copy
- msr psp, r0
將最新的任務堆棧棧頂賦值給線程堆棧指針PSP。
[objc] view plain copy
- bx r14
從異常中斷服務程序退出。異常發生時，R14中保存異常返回標誌，包括返回後進入線程模式還是處理器模式、使用PSP堆棧指針還是MSP堆棧指針。當調用 bx r14指令後，硬件會知道要從異常返回，然後出棧，這個時候堆棧指針PSP已經指向了新任務堆棧的正確位置，當新任務的運行地址被出棧到PC寄存器後，新的任務也會被執行。 至此，任務切換完成。