详解基于 Cortex-M3 的任务调度（上）
文章目錄
- 什么是任務(wù)
- 任務(wù)及其內(nèi)存結(jié)構(gòu)
- 上下文切換
- CM3 的寄存器組
- CM3 的 CONTROL 寄存器
- 雙棧
- CM3 的中斷
- 入棧
- 取向量
- 更新寄存器
- 異常返回
- 切換的時(shí)機(jī)
- 切換
- 非基級(jí)線程模式（補(bǔ)充材料）
- 代碼
什么是任務(wù)
對(duì)于嵌入式 RTOS，我覺得任務(wù)（task） 其實(shí)是線程。為什么這樣說呢？首先，有幾個(gè)知識(shí)點(diǎn)要明確：
其次，每個(gè)進(jìn)程都有其自己的存儲(chǔ)空間，它們是互相隔離的。比如你在瀏覽網(wǎng)頁，瀏覽器崩潰了，但并不會(huì)影響到音樂播放器。但是對(duì)于線程來說，資源是共享的，所以對(duì)于共享資源的訪問就會(huì)存在競(jìng)爭(zhēng)問題，于是就產(chǎn)生臨界區(qū)，互斥、信號(hào)量等概念。如果一個(gè)線程崩潰了，極大可能會(huì)影響到該進(jìn)程中的其他線程。
對(duì)于 MCU 上的資源，每個(gè)任務(wù)都是共享的，可以認(rèn)為是單進(jìn)程多線程模型。MCU一般沒有內(nèi)存管理模塊，這樣無法很好地保證進(jìn)程的安全，這也是當(dāng)某個(gè)任務(wù)跑飛會(huì)導(dǎo)致整個(gè)程序崩潰的原因。
通常認(rèn)為，嵌入式系統(tǒng)在運(yùn)行時(shí)只有一個(gè)進(jìn)程，而把這個(gè)進(jìn)程進(jìn)行分解之后的那些程序模塊，由于沒有獨(dú)立的內(nèi)存空間，實(shí)質(zhì)上就是線程。在 μC/OS-II 中，把這樣的線程叫做任務(wù)。
直觀上來講，
任務(wù)及其內(nèi)存結(jié)構(gòu)
既然是任務(wù)調(diào)度，那就需要系統(tǒng)把任務(wù)管理起來，系統(tǒng)管理任務(wù)的數(shù)據(jù)結(jié)構(gòu)叫做任務(wù)控制塊（TCB）
以 μC/OS-II 為例，任務(wù)控制塊記錄一個(gè)任務(wù)的各個(gè)屬性，相當(dāng)于是任務(wù)的身份證。TCB 中有兩個(gè)指針特別重要：
- 指向任務(wù)的指針：在任務(wù)初始化的時(shí)候，這個(gè)指針指向任務(wù)的代碼入口
- 指向任務(wù)堆棧的指針：指向任務(wù)的棧。每個(gè)任務(wù)都有自己的棧，用來保存局部變量，還有寄存器的快照。在這些寄存器中，最重要的就是 PC，指向任務(wù)當(dāng)前運(yùn)行的代碼
系統(tǒng)中一般會(huì)有多個(gè)任務(wù)，這些任務(wù)的 TCB 用鏈表串起來，也可以用數(shù)組。
上下文切換
要進(jìn)行任務(wù)調(diào)度，就要進(jìn)行上下文切換。
先看看線程是如何對(duì)付中斷的。當(dāng)線程在執(zhí)行時(shí)，所做的事情就是從存儲(chǔ)器中取指令、譯碼、執(zhí)行。在整個(gè)過程中，CPU 里寄存器的值會(huì)不斷更新。此時(shí)如果一個(gè)中斷來了，那么 CPU 就要把核心寄存器的值先保存到內(nèi)存的某個(gè)地方（比如這個(gè)線程的棧），然后響應(yīng)中斷。等中斷執(zhí)行完了，再把剛才保存的值加載到對(duì)應(yīng)的寄存器，從剛才中斷的地方繼續(xù)執(zhí)行（由程序計(jì)數(shù)器 PC 記錄）。
任務(wù)切換也是這個(gè)道理，如果要把當(dāng)前任務(wù) A 換出，就要先找到 A 任務(wù)的棧，把當(dāng)前的寄存器信息保存到棧上，然后找出要換入的任務(wù) B，再找到 B 任務(wù)的棧，把棧上保存的寄存器值恢復(fù)到寄存器里，最后讓 B 開始運(yùn)行。
前面做了很多鋪墊，接下來我們就結(jié)合具體的一款 CPU 來講任務(wù)調(diào)度。
CM3 的寄存器組
注意，在 CM3 處理器內(nèi)核中共有兩個(gè)堆棧指針，于是也就支持兩個(gè)堆棧。當(dāng)引用 R13（或?qū)懽?SP）時(shí)，引用到的是當(dāng)前正在使用的那一個(gè)，另一個(gè)必須用特殊的指令來訪問（MRS，MSR指令）。這兩個(gè)堆棧指針分別是：
- 主堆棧指針（MSP）， 或?qū)懽?SP_main。這是缺省的堆棧指針，它由 OS 內(nèi)核、異常服務(wù)例程以及所有需要特權(quán)訪問的應(yīng)用程序代碼來使用。
- 進(jìn)程堆棧指針（PSP）， 或?qū)懽?SP_process。用于常規(guī)的應(yīng)用程序代碼（不處于異常服用例程中時(shí)）。
要注意的是，并不是每個(gè)程序都要用齊兩個(gè)堆棧指針才算圓滿。簡(jiǎn)單的應(yīng)用程序只使用 MSP 就夠了。
在本文的示例代碼中，采用了雙棧。
CM3 的 CONTROL 寄存器
復(fù)位后，CONTROL[0]=0 ，也就是說線程模式處于特權(quán)級(jí)。
Cortex-M3 處理器支持兩種處理器的操作模式，還支持兩級(jí)特權(quán)操作。
兩種操作模式分別為：handler 模式和線程模式（thread mode）。引入兩個(gè)模式的本意，是用于區(qū)別普通應(yīng)用程序的代碼和異常服務(wù)例程的代碼。
兩級(jí)特權(quán)分別是：特權(quán)級(jí)和用戶級(jí)。這可以提供一種存儲(chǔ)器訪問的保護(hù)機(jī)制，使得普通的用戶程序代碼不能意外地、甚至是惡意地執(zhí)行涉及到要害的操作。
示例代碼中有一句：
__set_CONTROL(0x3); // Switch to use Process Stack, unprivileged state
意思是強(qiáng)行切換到用戶級(jí)，且用 PSP（后面馬上就說）
雙棧
我們已經(jīng)知道了 CM3 的堆棧有兩個(gè)：主棧和進(jìn)程棧，CONTROL[1] 決定如何選擇。
當(dāng) CONTROL[1]=0 時(shí)，只使用 MSP，此時(shí)用戶程序和異常 handler 共享同一個(gè)棧，這也是復(fù)位后的缺省使用方式。
我們的示例代碼采用了雙棧。
當(dāng) CONTROL[1]=1 時(shí)，線程模式將不再使用 MSP，而改用 PSP（注意：handler 模式永遠(yuǎn)使用 MSP）。這樣做的好處在哪里？原來，在使用 OS 的環(huán)境下，我們想讓 OS 內(nèi)核僅在 handler 模式下執(zhí)行，用戶程序僅在用戶模式下執(zhí)行，這種雙棧機(jī)制的好處是：萬一用戶棧崩潰了，并不會(huì)累及 OS 的棧。
在雙棧模式下，進(jìn)入異常時(shí)的自動(dòng)壓棧使用的是進(jìn)程棧，進(jìn)入異常后會(huì)自動(dòng)改為 MSP，退出異常時(shí)切換回 PSP，并且從進(jìn)程棧上彈出數(shù)據(jù)。 如下圖所示：
CM3 的中斷
任務(wù)切換一般是在中斷中進(jìn)行的，所以了解 CPU 的中斷過程非常必要。
當(dāng) CM3 開始響應(yīng)一個(gè)中斷時(shí)，會(huì)在它小小的體內(nèi)奔涌起三股暗流：
- 入棧： 把 8 個(gè)寄存器的值壓入棧
- 取向量：從向量表中找出對(duì)應(yīng)服務(wù)程序的入口地址
- 更新寄存器：選擇堆棧指針 MSP/PSP，更新堆棧指針 SP，更新連接寄存器 LR，更新程序計(jì)數(shù)器 PC
好，我們一個(gè)一個(gè)來說。
入棧
自動(dòng)入棧的寄存器有 8 個(gè)，見表 9.1：
取向量
當(dāng)數(shù)據(jù)總線（系統(tǒng)總線）正在為入棧操作而忙得風(fēng)風(fēng)火火時(shí)，指令總線（I-Code）可不是袖手旁觀——它正在為響應(yīng)中斷緊張有序地執(zhí)行另一項(xiàng)重要的任務(wù)：從向量表中找出正確的異常向量，然后在服務(wù)程序的入口處預(yù)取指。由此可以看到各自都有專用總線的好處：入棧與取指這兩個(gè)工作能同時(shí)進(jìn)行。
更新寄存器
在入棧和取向量操作完成之后，執(zhí)行服務(wù)例程之前，還要更新一系列的寄存器：
- SP：在入棧后會(huì)把堆棧指針（PSP 或 MSP）更新到新的位置。在執(zhí)行服務(wù)例程時(shí)，將由 MSP 負(fù)責(zé)對(duì)堆棧的訪問。
- PSR：更新 IPSR 位段的值為新響應(yīng)的異常編號(hào)。
- PC：在取向量完成后，PC 將指向服務(wù)例程的入口地址。
- LR：在出入 ISR 的時(shí)候，LR 的值將有新意義，這種特殊的值稱為“EXC_RETURN”，在異常進(jìn)入時(shí)由系統(tǒng)計(jì)算并賦給 LR，并在異常返回時(shí)使用它。EXC_RETURN 的值除了最低 4 位外全為 1，而其最低4位則有另外的含義（見表9.3和表9.4）。
以上是在響應(yīng)異常時(shí)通用寄存器的變化。另一方面，在 NVIC 中，也會(huì)更新若干個(gè)相關(guān)寄存器。例如，新響應(yīng)異常的懸起位將被清除，同時(shí)其活動(dòng)位將被置位。
異常返回
當(dāng)異常服務(wù)例程執(zhí)行完畢后，需要很正式地做一個(gè)“異常返回”的動(dòng)作序列，從而恢復(fù)先前的系統(tǒng)狀態(tài)，才能使被中斷的程序得以繼續(xù)執(zhí)行。從形式上看，有 3 種途徑可以觸發(fā)異常返回序列，如表 9.2 所示。而不管使用哪一種，都需要用到先前儲(chǔ)到 LR 的 EXC_RETURN。
在示例代碼中，使用的是第一個(gè)方法：
BX LR // Return
在啟動(dòng)了中斷返回序列后，下述的處理就將進(jìn)行：
切換的時(shí)機(jī)
已經(jīng)說了，任務(wù)切換在中斷中進(jìn)行，但是在哪個(gè)中斷呢？
例如，一個(gè)系統(tǒng)中有兩個(gè)任務(wù)，上下文切換被觸發(fā)的場(chǎng)合可以是：
- 執(zhí)行一個(gè)系統(tǒng)調(diào)用（SVC 異常）
- 系統(tǒng)滴答定時(shí)器（SYSTICK）中斷，（輪轉(zhuǎn)調(diào)度中需要）
讓我們舉個(gè)簡(jiǎn)單的例子。假設(shè)有這么一個(gè)系統(tǒng)，里面有兩個(gè)就緒的任務(wù)，并且通過 SysTick 異常啟動(dòng)上下文切換。如圖 7.15 所示。
上圖是兩個(gè)任務(wù)輪轉(zhuǎn)調(diào)度的示意圖。但若在產(chǎn)生 SysTick 異常時(shí)正在響應(yīng)一個(gè)中斷，則 SysTick 異常會(huì)搶占其 ISR。在這種情況下，OS 是不能執(zhí)行上下文切換的，否則將使中斷請(qǐng)求被延遲，而且在真實(shí)系統(tǒng)中延遲時(shí)間還往往不可預(yù)知——任何有一丁點(diǎn)實(shí)時(shí)要求的系統(tǒng)都決不能容忍這種事。因此，在 CM3 中也是嚴(yán)禁沒商量——如果 OS 在某中斷活躍時(shí)嘗試切入線程模式，將觸發(fā)用法 fault 異常（但是有例外情況，感興趣的讀者可以看本文末尾的“非基級(jí)線程模式”）。
為解決此問題，早期的 OS 大多會(huì)檢測(cè)當(dāng)前是否有中斷在活躍中，只有在無任何中斷需要響應(yīng)時(shí)，才執(zhí)行上下文切換（切換期間無法響應(yīng)中斷）。然而，這種方法的弊端在于，它可以把任務(wù)切換動(dòng)作拖延很久（因?yàn)槿绻麚屨剂?IRQ，則本次 SysTick 在執(zhí)行后不得作上下文切換，只能等待下一次 SysTick 異常），尤其是當(dāng)某中斷源的頻率和 SysTick 異常的頻率比較接近時(shí)，會(huì)發(fā)生“共振”，使上下文切換遲遲不能進(jìn)行。
現(xiàn)在好了，有 PendSV 來完美解決這個(gè)問題。PendSV 異常會(huì)自動(dòng)延遲上下文切換的請(qǐng)求。為實(shí)現(xiàn)這個(gè)機(jī)制，需要把 PendSV 編程為最低優(yōu)先級(jí)的異常。若 OS 需要執(zhí)行上下文切換，它將懸起一個(gè) PendSV 異常，并在 PendSV 異常內(nèi)執(zhí)行上下文切換。如圖 7.17 所示
解釋：
遺留問題：在調(diào)試的時(shí)候，我認(rèn)為 SysTick 異常返回后會(huì)立刻進(jìn)入 PendSV 服務(wù)例程，應(yīng)該看到 Tail chaining 現(xiàn)象，但測(cè)試結(jié)果是 SysTick 中斷處理后返回到了任務(wù) B，執(zhí)行了一點(diǎn)點(diǎn)，馬上進(jìn)入 PendSV
切換
具體的切換如下圖所示。
我給出的解釋：
非基級(jí)線程模式（補(bǔ)充材料）
在 CM3 中，原則上異常服務(wù)程序要在 handler 模式下執(zhí)行，但是也允許在服務(wù)例程中切換到線程模式。通過設(shè)置 NVIC 配置與控制寄存器的“非基級(jí)線程模式允許”位（NONBASETHRDENA，位偏移：0），可以在服務(wù)例程中把處理器切換入線程模式。為什么要這么做？如果中斷服務(wù)例程是用戶程序的一部分，可能需要讓它在線程模式下執(zhí)行，以限制它訪問特權(quán)級(jí)下的資源，此時(shí)可以讓此功能派上用場(chǎng)。
如果使用此功能，則需要手工調(diào)整堆棧指針，還要重建堆棧中的數(shù)據(jù)。這種乾坤大挪移可是高度危險(xiǎn)的作業(yè)，一不小心就很容易把整個(gè)系統(tǒng)弄垮。所以必須格外嚴(yán)肅地對(duì)待。另外，在使用時(shí)，系統(tǒng)設(shè)計(jì)者還必須保證服務(wù)例程能正確地返回。因?yàn)樵诰€程模式下是不允許作中斷返回的，所以必須用一點(diǎn)手腕才行。如果放任不管，則中斷無法退出，這會(huì)永遠(yuǎn)阻塞其它同級(jí)和更低優(yōu)先級(jí)中斷。通常，由系統(tǒng)軟件負(fù)責(zé)完成這種工作。
此節(jié)內(nèi)容和本文主旨無關(guān)，所以僅放一個(gè)圖片在這里，提示讀者“居然可以如此操作”！
代碼
囿于篇幅，代碼下一篇博文再講。
歡迎讀者批評(píng)指正。
參考資料
【0】RTOS中的任務(wù)是線程、進(jìn)程、還是協(xié)程？-面包板社區(qū)
【1】任務(wù)、進(jìn)程和線程的區(qū)別（轉(zhuǎn)自博客園） - 雷明 - 博客園
【2】《Cortex-M3 權(quán)威指南 》
【3】《The De?nitive Guide to ARM Cortex-M3 and Cortex-M4 Processors（Third Edition）》
總結(jié)
以上是生活随笔為你收集整理的详解基于 Cortex-M3 的任务调度（上）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python人脸识别截图_Python
- 下一篇： 详解基于 Cortex-M3 的任务调度