日本黄色一级经典视频|伊人久久精品视频|亚洲黄色色周成人视频九九九|av免费网址黄色小短片|黄色Av无码亚洲成年人|亚洲1区2区3区无码|真人黄片免费观看|无码一级小说欧美日免费三级|日韩中文字幕91在线看|精品久久久无码中文字幕边打电话

當(dāng)前位置:首頁 > 嵌入式 > 技術(shù)讓夢(mèng)想更偉大
[導(dǎo)讀]關(guān)注、星標(biāo)公眾號(hào),直達(dá)精彩內(nèi)容ID:技術(shù)讓夢(mèng)想更偉大整理:李肖遙FreeRTOS任務(wù)相關(guān)的代碼大約占總代碼的一半左右,這些代碼都在為一件事情而努力,即找到優(yōu)先級(jí)最高的就緒任務(wù),并使之獲得CPU運(yùn)行權(quán)。任務(wù)切換是這一過程的直接實(shí)施者,為了更快的找到優(yōu)先級(jí)最高的就緒任務(wù),任務(wù)切換的代...


關(guān)注、星標(biāo)公眾號(hào),直達(dá)精彩內(nèi)容

ID:技術(shù)讓夢(mèng)想更偉大

整理:李肖遙


FreeRTOS任務(wù)相關(guān)的代碼大約占總代碼的一半左右,這些代碼都在為一件事情而努力,即找到優(yōu)先級(jí)最高的就緒任務(wù),并使之獲得CPU運(yùn)行權(quán)。

任務(wù)切換是這一過程的直接實(shí)施者,為了更快的找到優(yōu)先級(jí)最高的就緒任務(wù),任務(wù)切換的代碼通常都是精心設(shè)計(jì)的,甚至?xí)玫絽R編指令或者與硬件相關(guān)的特性,比如Cortex-M3的CLZ指令。

因此任務(wù)切換的大部分代碼是由硬件移植層提供的,不同的平臺(tái),實(shí)現(xiàn)發(fā)方法也可能不同。

?這篇文章以Cortex-M3為例,講述FreeRTOS任務(wù)切換的過程。

?
「FreeRTOS有兩種方法觸發(fā)任務(wù)切換:」

  • 執(zhí)行系統(tǒng)調(diào)用,比如普通任務(wù)可以使用taskYIELD()強(qiáng)制任務(wù)切換,中斷服務(wù)程序中使用portYIELD_FROM_ISR()強(qiáng)制任務(wù)切換;
  • 系統(tǒng)節(jié)拍時(shí)鐘中斷
對(duì)于Cortex-M3平臺(tái),這兩種方法的實(shí)質(zhì)是一樣的,都會(huì)使能一個(gè)PendSV中斷,在PendSV中斷服務(wù)程序中,找到最高優(yōu)先級(jí)的就緒任務(wù),然后讓這個(gè)任務(wù)獲得CPU運(yùn)行權(quán),從而完成任務(wù)切換。

對(duì)于第一種任務(wù)切換方法,不管是使用taskYIELD()還是portYIELD_FROM_ISR(),最終都會(huì)執(zhí)行宏portYIELD(),這個(gè)宏的定義如下:

#define?portYIELD()??????\
{????????\
?/*產(chǎn)生PendSV中斷*/??????????????????????????\
?portNVIC_INT_CTRL_REG?=?portNVIC_PENDSVSET_BIT;??\
}
對(duì)于第二種任務(wù)切換方法,在系統(tǒng)節(jié)拍時(shí)鐘中斷服務(wù)函數(shù)中,首先會(huì)更新tick計(jì)數(shù)器的值、查看是否有任務(wù)解除阻塞,如果有任務(wù)解除阻塞的話,則使能PandSV中斷,代碼如下所示:

void?xPortSysTickHandler(?void?)
{
?/*?設(shè)置中斷掩碼?*/
?vPortRaiseBASEPRI();
?{
??/*?增加tick計(jì)數(shù)器值,并檢查是否有任務(wù)解除阻塞?*/
??if(?xTaskIncrementTick()?!=?pdFALSE?)
??{
???/*?需要任務(wù)切換。產(chǎn)生PendSV中斷?*/
???portNVIC_INT_CTRL_REG?=?portNVIC_PENDSVSET_BIT;
??}
?}
?vPortClearBASEPRIFromISR();
}
從上面的代碼中可以看出,PendSV中斷的產(chǎn)生是通過代碼:

portNVIC_INT_CTRL_REG?=?portNVIC_PENDSVSET_BIT
實(shí)現(xiàn)的,它向中斷狀態(tài)寄存器bit28位寫入1,將PendSV中斷設(shè)置為掛起狀態(tài);

等到優(yōu)先級(jí)高于PendSV的中斷執(zhí)行完成后,PendSV中斷服務(wù)程序?qū)⒈粓?zhí)行,進(jìn)行任務(wù)切換工作。

Cortex-M3架構(gòu)下,PendSV中斷服務(wù)程序源碼如下所示,這篇文章重點(diǎn)分析這段代碼。

__asm?void?xPortPendSVHandler(?void?)
{
?extern?uxCriticalNesting;
?extern?pxCurrentTCB;????????????/*?指向當(dāng)前激活的任務(wù)?*/
?extern?vTaskSwitchContext;??????
?
?PRESERVE8
?
?mrs?r0,?psp???????????????????/*?PSP內(nèi)容存入R0?*/????
?isb???????????????????????????/*?指令同步隔離,清流水線?*/
?
?ldr?r3,?=pxCurrentTCB?????/*?當(dāng)前激活的任務(wù)TCB指針存入R2?*/
?ldr?r2,?[r3]
?
?stmdb?r0!,?{r4-r11}??????????/*?保存剩余的寄存器,異常處理程序執(zhí)行前,硬件自動(dòng)將xPSR、PC、LR、R12、R0-R3入棧?*/
?str?r0,?[r2]???????/*?將新的棧頂保存到任務(wù)TCB的第一個(gè)成員中?*/
?
?stmdb?sp!,?{r3,?r14}?????????/*?將R3和R14臨時(shí)壓入堆棧,因?yàn)榧磳⒄{(diào)用函數(shù)vTaskSwitchContext,調(diào)用函數(shù)時(shí),返回地址自動(dòng)保存到R14中,所以一旦調(diào)用發(fā)生,R14的值會(huì)被覆蓋,因此需要入棧保護(hù);?R3保存的當(dāng)前激活的任務(wù)TCB指針(pxCurrentTCB)地址,函數(shù)調(diào)用后會(huì)用到,因此也要入棧保護(hù)*/
?mov?r0,?#configMAX_SYSCALL_INTERRUPT_PRIORITY???/*?進(jìn)入臨界區(qū)?*/
?msr?basepri,?r0
?dsb?????????????????????????/*?數(shù)據(jù)和指令同步隔離?*/
?isb
?bl?vTaskSwitchContext????????/*?調(diào)用函數(shù),尋找新的任務(wù)運(yùn)行,通過使變量pxCurrentTCB指向新的任務(wù)來實(shí)現(xiàn)任務(wù)切換?*/
?mov?r0,?#0???????????????????/*?退出臨界區(qū)*/
?msr?basepri,?r0
?ldmia?sp!,?{r3,?r14}?????????/*?恢復(fù)R3和R14*/
?
?ldr?r1,?[r3]
?ldr?r0,?[r1]???????/*?當(dāng)前激活的任務(wù)TCB第一項(xiàng)保存了任務(wù)堆棧的棧頂,現(xiàn)在棧頂值存入R0*/
?ldmia?r0!,?{r4-r11}??????/*?出棧*/
?msr?psp,?r0
?isb
?bx r14 ?????????????????????/*?異常發(fā)生時(shí),R14中保存異常返回標(biāo)志,包括返回后進(jìn)入線程模式還是處理器模式、使用PSP堆棧指針還是MSP堆棧指針,當(dāng)調(diào)用 bx r14指令后,硬件會(huì)知道要從異常返回,然后出棧,這個(gè)時(shí)候堆棧指針PSP已經(jīng)指向了新任務(wù)堆棧的正確位置,當(dāng)新任務(wù)的運(yùn)行地址被出棧到PC寄存器后,新的任務(wù)也會(huì)被執(zhí)行。*/
?nop
}
為了便于理解上面的代碼,我們先用流程圖的方式將整個(gè)過程畫出來,然后再逐句分析代碼。因?yàn)閳D形可以簡化程序,并且信息更容易接受。

圖1-1:任務(wù)切換流程
先強(qiáng)調(diào)圖1-1中的幾個(gè)術(shù)語,首先是“主堆棧指針MSP”和“進(jìn)程堆棧指針PSP”。

對(duì)于Cortex-M3硬件,當(dāng)系統(tǒng)復(fù)位后,默認(rèn)使用MSP指針。

MSP指針用于操作系統(tǒng)內(nèi)核以及處理異常(也就是說中斷服務(wù)程序中默認(rèn)強(qiáng)制使用MSP指針,這是硬件自動(dòng)設(shè)置的)。

任務(wù)(進(jìn)程)使用PSP指針,操作系統(tǒng)負(fù)責(zé)從MSP指針切換到PSP指針。

這個(gè)過程在《FreeRTOS高級(jí)篇3---啟動(dòng)調(diào)度器》一文的最后部分中「進(jìn)行了講解」

在SVC中斷服務(wù)程序中啟動(dòng)第一個(gè)任務(wù),當(dāng)從SVC中斷服務(wù)退出前,通過向r14寄存器最后4位按位或上0x0D,使得硬件在退出時(shí)使用進(jìn)程堆棧指針PSP完成出棧操作并返回后進(jìn)入線程模式、返回Thumb狀態(tài)。

其次,“堆?!焙汀叭蝿?wù)堆?!币仓档脧?qiáng)調(diào)一下。

每個(gè)任務(wù)都有自己的“任務(wù)堆棧”,在任務(wù)創(chuàng)建時(shí)會(huì)創(chuàng)建指定大小的任務(wù)堆棧,這是任務(wù)能夠獨(dú)立運(yùn)行的前提條件之一。

在任務(wù)中定義的局部變量,會(huì)優(yōu)先使用寄存器,寄存器不夠時(shí)就使用任務(wù)堆棧的空間。

如果在任務(wù)中調(diào)用其它函數(shù),則調(diào)用前的保存信息也存到任務(wù)堆棧中去。

根據(jù)任務(wù)代碼來估算任務(wù)堆棧的大小是件十分重要的技能。

前面也說了,Cortex-M3硬件有兩個(gè)堆棧指針,操作系統(tǒng)內(nèi)核以及異常處理程序中使用MSP指針,所以它們也需要一個(gè)堆??臻g,我們稱之為“堆棧”;

這個(gè)堆棧空間和任務(wù)堆??臻g在物理上是絕對(duì)不可以重疊的,圖1-2展示了一個(gè)編譯好的程序可能的RAM分配情況(堆棧向下生長)。

圖1-2:RAM中的變量和堆棧分布示意圖
有了上面的基礎(chǔ),接下來我們來分析PendSV中斷服務(wù)程序。

mrs?r0,?psp?
是將任務(wù)堆棧指針PSP的值保存到寄存器R0中,因?yàn)榻酉聛砦覀儠?huì)將寄存器R4~R11也保存到任務(wù)堆棧中,但是我們沒有哪個(gè)匯編指令能直接操作PSP完成入棧,所以只能借助R0。

ldr?r3,?=pxCurrentTCB??????/*?當(dāng)前激活的任務(wù)TCB指針存入R2?*/
ldr?r2,?[r3]
這兩句代碼是獲取當(dāng)前激活的任務(wù)TCP指針,指針pxCurrentTCB前面文章已經(jīng)提到過很多次了,它是位于tasks.c文件中定義的唯一一個(gè)全局指針型變量,指向當(dāng)前激活的任務(wù)TCB。

stmdb?r0!,?{r4-r11}
這句代碼用于將寄存器R4~R11保存到當(dāng)前激活的程序任務(wù)堆棧中,并且同步更新寄存器R0的值。

str?r0,?[r2]
寄存器R2中保存當(dāng)前激活的任務(wù)TCB指針,在《FreeRTOS高級(jí)篇2---FreeRTOS任務(wù)創(chuàng)建分析》中講任務(wù)TCB數(shù)據(jù)結(jié)構(gòu)時(shí)我們知道,任務(wù)TCB數(shù)據(jù)結(jié)構(gòu)第一個(gè)成員一定是指向任務(wù)當(dāng)前堆棧棧頂?shù)闹羔樧兞?code style="overflow-wrap: break-word;margin-right: 2px;margin-left: 2px;font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(53, 148, 247);background: rgba(59, 170, 250, 0.1);display: inline-block;padding-right: 2px;padding-left: 2px;border-radius: 2px;height: 21px;line-height: 22px;">pxTopOfStack。

這句代碼將R0的內(nèi)容保存到任務(wù)TCB數(shù)據(jù)結(jié)構(gòu)的第一個(gè)成員pxTopOfStack中,也就是將最新的任務(wù)堆棧指針保存到任務(wù)TCB的pxTopOfStack字段中。

當(dāng)任務(wù)被激活時(shí),就是從這個(gè)字段中獲取任務(wù)堆棧指針,然后完成數(shù)據(jù)出棧操作的。

stmdb?sp!,?{r3,?r14}
將R3和R14臨時(shí)壓入堆棧,因?yàn)榧磳⒄{(diào)用函數(shù)vTaskSwitchContext。調(diào)用函數(shù)時(shí),返回地址自動(dòng)保存到R14中,所以一旦調(diào)用發(fā)生,R14的值會(huì)被覆蓋,因此需要入棧保護(hù)。

R3保存的當(dāng)前激活的任務(wù)TCB指針(pxCurrentTCB)地址,函數(shù)調(diào)用后會(huì)用到,因此也要入棧保護(hù)。

mov?r0,?#configMAX_SYSCALL_INTERRUPT_PRIORITY???
msr?basepri,?r0
這兩句代碼用來進(jìn)入臨界區(qū),中斷優(yōu)先級(jí)號(hào)大于等于configMAX_SYSCALL_INTERRUPT_PRIORITY的中斷都會(huì)被屏蔽。

bl?vTaskSwitchContext
調(diào)用函數(shù),選擇下一個(gè)要執(zhí)行的任務(wù),也就是尋找處于就緒態(tài)的最高優(yōu)先級(jí)任務(wù)。

變量pxCurrentTCB指向找到的任務(wù)TCB。這個(gè)函數(shù)是核心中的核心,所有的其它代碼都是為了保證這個(gè)函數(shù)能正確運(yùn)行。

某些運(yùn)行FreeRTOS的硬件有兩種方法:「通用方法和特定于硬件的方法」(以下簡稱“特殊方法”)。

  1. 對(duì)于通用方法:
  • configUSE_PORT_OPTIMISED_TASK_SELECTION設(shè)置為0或者硬件不支持這種特殊方法。
  • 可以用于所有FreeRTOS支持的硬件。
  • 完全用C實(shí)現(xiàn),效率略低于特殊方法。
  • 不強(qiáng)制要求限制最大可用優(yōu)先級(jí)數(shù)目
  1. 對(duì)于特殊方法:
  • 并非所有硬件都支持。
  • 必須將configUSE_PORT_OPTIMISED_TASK_SELECTION設(shè)置為1。
  • 依賴一個(gè)或多個(gè)特定架構(gòu)的匯編指令(一般是類似計(jì)算前導(dǎo)零[CLZ]指令)。
  • 比通用方法更高效。
  • 一般強(qiáng)制限定最大可用優(yōu)先級(jí)數(shù)目為32(0~31)。
Cortex-M3即支持通用方法也支持特殊方法,默認(rèn)的移植層使用特殊方法。我們先來看一下通用方法如何找到下一個(gè)要執(zhí)行的任務(wù)。

在函數(shù)vTaskSwitchContext中使用宏taskSELECT_HIGHEST_PRIORITY_TASK()完成任務(wù)尋址工作,使用通用方法時(shí),這個(gè)宏的代碼如下所示。

pxReadyTasksLists是定義在tasks.c中的靜態(tài)列表數(shù)組,表示就緒任務(wù)列表數(shù)組。

在《FreeRTOS高級(jí)篇2---FreeRTOS任務(wù)創(chuàng)建分析》中講過這個(gè)變量:新創(chuàng)建任務(wù)的過程中,任務(wù)TCB中的狀態(tài)列表項(xiàng)xStateListItem會(huì)掛接到就緒任務(wù)列表數(shù)組中。

uxTopReadyPriority也是定義在tasks.c中的靜態(tài)變量,在此之前,它已經(jīng)代表處于就緒態(tài)任務(wù)的最高優(yōu)先級(jí)值;

在FreeRTOS任務(wù)創(chuàng)建與分析一文中,我們也講到了這個(gè)變量:每次任務(wù)創(chuàng)建,都會(huì)判斷新任務(wù)的優(yōu)先級(jí)是否大于這個(gè)變量,如果大于,還會(huì)更新這個(gè)變量的值。

while()循環(huán)從優(yōu)先級(jí)uxTopReadyPriority開始,從就緒列表數(shù)組pxReadyTasksLists中找出優(yōu)先級(jí)最高的任務(wù),然后調(diào)用宏listGET_OWNER_OF_NEXT_ENTRY獲取最高優(yōu)先級(jí)列表中的下一個(gè)列表項(xiàng),并從該列表項(xiàng)中獲取任務(wù)TCB指針賦給變量pxCurrentTCB。

#define?taskSELECT_HIGHEST_PRIORITY_TASK()????????\
{?????????????????\
??/*?從就緒列表數(shù)組中找出最高優(yōu)先級(jí)列表*/????\
??while(?listLIST_IS_EMPTY(?
本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

LED驅(qū)動(dòng)電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關(guān)鍵字: 驅(qū)動(dòng)電源

在工業(yè)自動(dòng)化蓬勃發(fā)展的當(dāng)下,工業(yè)電機(jī)作為核心動(dòng)力設(shè)備,其驅(qū)動(dòng)電源的性能直接關(guān)系到整個(gè)系統(tǒng)的穩(wěn)定性和可靠性。其中,反電動(dòng)勢(shì)抑制與過流保護(hù)是驅(qū)動(dòng)電源設(shè)計(jì)中至關(guān)重要的兩個(gè)環(huán)節(jié),集成化方案的設(shè)計(jì)成為提升電機(jī)驅(qū)動(dòng)性能的關(guān)鍵。

關(guān)鍵字: 工業(yè)電機(jī) 驅(qū)動(dòng)電源

LED 驅(qū)動(dòng)電源作為 LED 照明系統(tǒng)的 “心臟”,其穩(wěn)定性直接決定了整個(gè)照明設(shè)備的使用壽命。然而,在實(shí)際應(yīng)用中,LED 驅(qū)動(dòng)電源易損壞的問題卻十分常見,不僅增加了維護(hù)成本,還影響了用戶體驗(yàn)。要解決這一問題,需從設(shè)計(jì)、生...

關(guān)鍵字: 驅(qū)動(dòng)電源 照明系統(tǒng) 散熱

根據(jù)LED驅(qū)動(dòng)電源的公式,電感內(nèi)電流波動(dòng)大小和電感值成反比,輸出紋波和輸出電容值成反比。所以加大電感值和輸出電容值可以減小紋波。

關(guān)鍵字: LED 設(shè)計(jì) 驅(qū)動(dòng)電源

電動(dòng)汽車(EV)作為新能源汽車的重要代表,正逐漸成為全球汽車產(chǎn)業(yè)的重要發(fā)展方向。電動(dòng)汽車的核心技術(shù)之一是電機(jī)驅(qū)動(dòng)控制系統(tǒng),而絕緣柵雙極型晶體管(IGBT)作為電機(jī)驅(qū)動(dòng)系統(tǒng)中的關(guān)鍵元件,其性能直接影響到電動(dòng)汽車的動(dòng)力性能和...

關(guān)鍵字: 電動(dòng)汽車 新能源 驅(qū)動(dòng)電源

在現(xiàn)代城市建設(shè)中,街道及停車場照明作為基礎(chǔ)設(shè)施的重要組成部分,其質(zhì)量和效率直接關(guān)系到城市的公共安全、居民生活質(zhì)量和能源利用效率。隨著科技的進(jìn)步,高亮度白光發(fā)光二極管(LED)因其獨(dú)特的優(yōu)勢(shì)逐漸取代傳統(tǒng)光源,成為大功率區(qū)域...

關(guān)鍵字: 發(fā)光二極管 驅(qū)動(dòng)電源 LED

LED通用照明設(shè)計(jì)工程師會(huì)遇到許多挑戰(zhàn),如功率密度、功率因數(shù)校正(PFC)、空間受限和可靠性等。

關(guān)鍵字: LED 驅(qū)動(dòng)電源 功率因數(shù)校正

在LED照明技術(shù)日益普及的今天,LED驅(qū)動(dòng)電源的電磁干擾(EMI)問題成為了一個(gè)不可忽視的挑戰(zhàn)。電磁干擾不僅會(huì)影響LED燈具的正常工作,還可能對(duì)周圍電子設(shè)備造成不利影響,甚至引發(fā)系統(tǒng)故障。因此,采取有效的硬件措施來解決L...

關(guān)鍵字: LED照明技術(shù) 電磁干擾 驅(qū)動(dòng)電源

開關(guān)電源具有效率高的特性,而且開關(guān)電源的變壓器體積比串聯(lián)穩(wěn)壓型電源的要小得多,電源電路比較整潔,整機(jī)重量也有所下降,所以,現(xiàn)在的LED驅(qū)動(dòng)電源

關(guān)鍵字: LED 驅(qū)動(dòng)電源 開關(guān)電源

LED驅(qū)動(dòng)電源是把電源供應(yīng)轉(zhuǎn)換為特定的電壓電流以驅(qū)動(dòng)LED發(fā)光的電壓轉(zhuǎn)換器,通常情況下:LED驅(qū)動(dòng)電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關(guān)鍵字: LED 隧道燈 驅(qū)動(dòng)電源
關(guān)閉