0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內(nèi)不再提示

嵌入式軟件優(yōu)先級的重要性

strongerHuang ? 來源:博客園 ? 作者:博客園 ? 2020-09-04 15:29 ? 次閱讀

嵌入式軟件開發(fā)中,我們不可避免的需要接觸優(yōu)先級的概念,掌握優(yōu)先級的概念對于設計一個好的軟件系統(tǒng)尤為重要。

本篇筆記的主要內(nèi)容有以下幾個方面:

1、中斷優(yōu)先級

2、操作系統(tǒng)中的任務優(yōu)先級

3、同等優(yōu)先級處理

4、中斷嵌套

今天借助大家熟悉的 STM32F103 平臺和各位聊聊其中的密事。

首先,我們從一個裸機系統(tǒng)的變量自加開始說起。

這里有三個變量,A、B、C,其中 B 變量除了在 main 函數(shù)中自加外,還會在中斷處理函數(shù)中進行自加。

這里面考慮了B的兩種情況,一是先執(zhí)行 main 中的自加再執(zhí)行中斷的自加,二是先執(zhí)行中斷的自加再進行 main 的自加。

不管發(fā)生哪種情況,當程序執(zhí)行到 C 位置時,B 的值都是一樣的。

當然,以上分析是從 C 語言的角度進行分析的,如果以匯編的視角進行分析(自加操作在匯編中分為三個步驟),你會發(fā)現(xiàn),這里面其實還有第三種情況:

這里面的 B’ 可以認為是寄存器,即變量的 B 的副本。

正因為副本的存在,在main 函數(shù)的寫入過程中導致丟失了中斷中 B 的自加操作。

對于程序而言,就好像根本沒有進入中斷一樣!

這就是全局變量的使用隱患。

但是善于分析的道友可能會提出這樣一個疑問,為什么上面只考慮了main 函數(shù)中的B++被打斷的可能,卻沒有考慮中斷(橙色部分)的B++被打斷的可能,是魚鷹忽略了嗎?

不不,其實這里面就涉及到了今天的主題,優(yōu)先級。

在裸機系統(tǒng)中,中斷優(yōu)先級高于main函數(shù)的處理,也就是說,一且中斷來臨, 不管main函數(shù)執(zhí)行到哪個位置,都會優(yōu)先處理中斷程序,只有中斷程序執(zhí)行完成后,才會繼續(xù)執(zhí)行main函數(shù),所以中斷的 B++ 不可能被main 函數(shù)打斷!

這里插兩個問題:

怎么進入中斷函數(shù)的?

當中斷請求(中斷請求可以認為是種電平信號,在寄存器中就表現(xiàn)為某一位的標志位)來臨時,硬件負責把部分寄存器存儲到棧(一種特殊的數(shù)據(jù)結(jié)構(gòu))中,這里面就包含了PC寄存器(用于指示下一條指令執(zhí)行的位置),之后從向量表中找到中斷處理函數(shù)的入口地址,開始進入中斷處理函數(shù)中執(zhí)行。

怎么回到原來的位置?

因為在進入中斷前已經(jīng)保存了PC等其他寄存器的值,所以只要在執(zhí)行完中斷處理函數(shù)后,將之前的保存到棧中的值恢復回來,那么CPU就可以繼續(xù)從被打斷的指令開始繼續(xù)執(zhí)行。

更多相關(guān)的中斷行為請查看《權(quán)威指南》,魚鷹不再細說。

回到剛才的優(yōu)先級話題,正因為中斷的執(zhí)行優(yōu)先級比main高,所以中斷中的 B++ 不會被打斷,這也是為什么有些時候,我們不需要對中斷中的變量進行臨界保護的原因所在。

在 Cortex-M3 內(nèi)核中,中斷分為可屏蔽和不可屏蔽中斷,同時又有可編程優(yōu)先級和不可編程優(yōu)先級之分。

所謂可屏蔽,就是說這個中斷是可以屏蔽掉的,即使發(fā)生了中斷,也不會讓CPU執(zhí)行中斷里面的程序。

比如我們的定時器中斷,如果我們沒有開啟相應的中斷的話,即使定時器溢出中斷來了,那也不會進入中斷處理函數(shù)處理的。

而不可屏蔽,就是說這個中斷是不可以屏蔽的,比如復位中斷(是不是不可思議,代碼執(zhí)行的第一條指令竟然是中斷處理函數(shù)里面的),如果復位中斷都被屏蔽了,那么系統(tǒng)也就別想運行了。

可編程,意味著這個中斷的優(yōu)先級可以由軟件修改(不可編程,即優(yōu)先級固定死了,不能修改)。

中斷的優(yōu)先級在設置時又有搶占式優(yōu)先級和非搶占式優(yōu)先級兩種設置(根據(jù)單片機不同,搶占式和非搶占式可設置的位數(shù)不同,并且可以分配各自的位數(shù),即所謂的中斷分組,如STM32F103 共有四位,通過設置中斷分組來決定搶占式和非搶占的位數(shù))。

搶占優(yōu)先級,即如果中斷 1 的優(yōu)先級比中斷 2 的搶占優(yōu)先級高的話,一旦中斷1發(fā)出中斷請求,即使已經(jīng)在中斷 2 執(zhí)行了,也會強制進入中斷 1 執(zhí)行,這個類似于 main 函數(shù)與中斷的關(guān)系,只不過這里兩個都是中斷而已。

在搶占優(yōu)先級相同情況下,非搶占優(yōu)先級就會開始起作用了。

如果中斷 1 和中斷 2 的搶占優(yōu)先級設置成一樣,而非搶占優(yōu)先級不一樣,此時如果兩個中斷同時發(fā)出請求,那么優(yōu)先處理非搶占優(yōu)先級高的中斷。

但是如果不是同時發(fā)生呢?那么就會依次處理中斷請求,在其中一個中斷處理過程中,是不可以被另一個中斷打斷的,同時如果本中斷再來一個請求,也不會重新進入中斷函數(shù)處理。

即中斷本身不可打斷自身的處理,換句話說中斷不會執(zhí)行到一半時又因為自身新的中斷請求來臨而重新再次進入本中斷處理函數(shù)執(zhí)行。

如果搶占優(yōu)先級和非搶占優(yōu)先級都設置成一樣呢,此時如果兩個中斷同時發(fā)生,又該選擇哪個先執(zhí)行,隨機嗎?

這里就涉及到硬件優(yōu)先級了。

在上圖中,每一個中斷其實都是有固定的默認優(yōu)先級的,這個優(yōu)先級肯定不同,所以當搶占優(yōu)先級和非搶占優(yōu)先級一樣的情況下,在中斷同時發(fā)生時,先執(zhí)行默認優(yōu)先級高的。

看圖:

講到了中斷,就不可不說如何禁止中斷的問題了。

在常規(guī)操作中,我們會使用禁止全局中斷來禁止中斷的處理,一旦禁止了全局中斷,那么除了不可屏蔽中斷外,所有的中斷都會被屏蔽掉,即如果在禁止中斷后發(fā)生了中斷,也不會再執(zhí)行。

但是一旦中斷打開了,那么之前被屏蔽的中斷就會立刻開始執(zhí)行(有一個中斷掛起位,代表中斷的發(fā)生,只有CPU執(zhí)行了中斷處理函數(shù),并清零相應標志位,該掛起位才會清除)。

如果在關(guān)閉中斷的過程中發(fā)送了兩次中斷,比如外部中斷發(fā)生了兩次,那么在開啟中斷后,也只會響應一次中斷,因為掛起位就只有那么一位(不像隊列一樣可以保留多個標志位)。

對于一般功能而言,禁止全局中斷確實有用,對于保護全局變量也非常有效,但是對于整個系統(tǒng)而言會有一定的影響。

如果禁止中斷的時間很短,那么確實無關(guān)緊要,但是一旦需要禁止較長的時間(毫秒級別),對于那些需要及時處理的中斷而言,就是一個不可忽視的延遲。

而在操作系統(tǒng)中,為了保護那些全局變量,禁止中斷的操作時有發(fā)生,那么是否有一種方法可以屏蔽部分中斷,而讓高優(yōu)先級的中斷不被屏蔽呢?

有的,在 Cortex-M3 內(nèi)核中,有一個寄存器專門干這事,即 BASEPRI。

當設置該寄存器時,將屏蔽所有優(yōu)先級不高于某個具體值的中斷。

比如設置該寄存器為 3,那么優(yōu)先級0~ 2的中斷不會被屏蔽。

所以在操作系統(tǒng)中,我們可以修改禁止中斷的代碼,使其不會屏蔽高優(yōu)先級的中斷,對于高優(yōu)先級中斷來說,可增加實時性。

uCOS II 中默認是直接全局禁止中斷的(可以修改它),但是 FreeRTOS 是可以禁止部分中斷的,使用的就是上述寄存器,當然這個功能需要單片機本身支持才行。

以上就是中斷優(yōu)先級的內(nèi)容,如果只會裸機的話,那么以上內(nèi)容就差不多了,但是如果是操作系統(tǒng),那么需要再增加一個任務優(yōu)先級的概念。

所謂任務,你也可以認為是一種中斷,只不過,這種特殊的中斷優(yōu)先級低于所有的硬件觸發(fā)的中斷。

中斷的優(yōu)先級凌駕于所有任務之上。

也就是說,一旦中斷來臨,不管CPU正在執(zhí)行哪個任務,在全局中斷開啟的情況下,都會立刻執(zhí)行中斷里的程序。

在中斷中,可以進行中斷嵌套,所謂的中斷嵌套即當前中斷被另一個更高優(yōu)先級的中斷所打斷(即搶占),被打斷的中斷必須在高優(yōu)先級任務執(zhí)行完成后才會繼續(xù)執(zhí)行。而在嵌入式實時操作系統(tǒng)中,為了更好的處理實時任務,一般而言也會設置成可搶占的任務(亦稱可剝奪)。

中斷的優(yōu)先級處理是由內(nèi)核進行管理的,這里的內(nèi)核是指單片機內(nèi)核,比如STM32F103的內(nèi)核是Cortex-M3(更準確的說是由 NVIC 管理)。

一旦設置好相應的寄存器之后,只要中斷來了,那么就會自動處理中斷程序,這些工作由硬件完成,它會在多個中斷同時來臨時選擇最高的優(yōu)先處理;也會在中斷執(zhí)行時,如果有一個更高優(yōu)先級的中斷來臨時,打斷當前中斷的執(zhí)行而先執(zhí)行更高優(yōu)先級的中斷。

但是操作系統(tǒng)是純軟件行為,那么操作系統(tǒng)的任務優(yōu)先級又是誰管理的?又是如何管理的呢?

答案就在Systick中斷。

既然要管理所有任務的優(yōu)先級,即在合適時選擇運行優(yōu)先級最高的任務,那么操作系統(tǒng)本身必然需要有能剝奪所有任務執(zhí)行的能力,而中斷是凌駕于任務之上的,可以在任何時候剝奪任務的執(zhí)行,從而獲得CPU的使用權(quán),所以選擇中斷作為操作系統(tǒng)的核心是合適的。

但是中斷那么多,選擇什么中斷比較合適呢?沒有比 Systick 中斷更合適的了,因為它就是為此而生的。

Systick說白了就是一個定時器,但是和普通定時器不同的是,功能比較單一,就是一個計數(shù)器而已,所以使用它管理任務是合適的,不會占用其他定時器。

那么Systick又是如何管理任務的呢?

一般而言,Systick 會設置成幾毫秒中斷一次,在每次中斷時,Systick處理程序(即操作系統(tǒng)內(nèi)核)都會從所有的任務中選擇最高優(yōu)先級的任務執(zhí)行,也就是說,系統(tǒng)總是運行最高的任務。

而這個特性也就導致你的高優(yōu)先級任務不可以無限執(zhí)行而不主動釋放CPU,因為一旦高優(yōu)先級任務無限執(zhí)行了,那么低優(yōu)先級任務將永遠得不到執(zhí)行機會,這就給人一種死機的假象。

可能有道友會疑惑,為什么空閑任務不需要調(diào)用系統(tǒng)延時函數(shù)去主動釋放CPU的使用權(quán)呢?

那是因為空閑任務本身優(yōu)先級就是所有任務中最低的,如果它主動釋放 CPU 了,而其他任務都處于掛起狀態(tài),那么操作系統(tǒng)又該讓誰去執(zhí)行呢?

所以,空閑任務需要永遠處于運行狀態(tài)。

從這個角度來說,操作系統(tǒng)主要的功能就是定時從所有任務中尋找最高優(yōu)先級的任務,然后讓該任務得到運行機會(使用PendSV 中斷切換到任務中,模擬中斷切換過程),功能類似于中斷管理器。

而正因為操作系統(tǒng)只會尋找最高優(yōu)先級的任務來執(zhí)行(對于實時操作系統(tǒng)是這樣,有些操作系統(tǒng)可能先來先處理的策略),所以任務本身主動釋放 CPU 就顯得尤為重要了。

最常用的主動釋放 CPU 的函數(shù)就是系統(tǒng)延時函數(shù)了,調(diào)用這個函數(shù)后,任務將延時一段時候才回來繼續(xù)執(zhí)行,而在延時過程中,操作系統(tǒng)就可以調(diào)用其他任務執(zhí)行了,正因為如此,操作系統(tǒng)才顯得高效。

雖然操作系統(tǒng)需要中斷來剝奪所有任務的執(zhí)行,從而擁有 CPU 的控制權(quán),但是一般而言,它的優(yōu)先級卻是所有中斷中最低的,因為它的優(yōu)先級只需要高于任務即可,如果設置的更高,那么就會影響到真正需要高優(yōu)先處理的中斷,因為Systick中斷的處理還是比較頻繁和繁重的,如果設置的太高,那么在Systick處理時,更低優(yōu)先級的中斷將無法處理,這可不是我們想看到的結(jié)果。

而如果設置成中斷優(yōu)先級最低的話,既可以剝奪任務的執(zhí)行,又可以在高優(yōu)先級中斷來臨時及時處理中斷,讓系統(tǒng)的實時得到提高。

與 Systick 配套的中斷,還有一個 PendSV 中斷,這個優(yōu)先級一般和 Systick 設置成一樣,一般而言該中斷的觸發(fā)是由操作系統(tǒng)內(nèi)核主動觸發(fā)的(在切換任務時軟件觸發(fā)該中斷),而不像 Systick 一樣,定時被動觸發(fā),關(guān)于兩個中斷更具體描述可參考《Cortex-M3 權(quán)威指南》。

既然中斷可以設置成優(yōu)先級一樣的,那么任務應該也可以才對,確實一般的操作系統(tǒng)都可以設置相同優(yōu)先級的任務(uCOS II 不可以, uCOS III 和 FreeRTOS 、RT-Thread可以),那么操作系統(tǒng)又是如何處理同等優(yōu)先級的任務?

一般而言,在任務初始化時,會設置任務的時間片,這個時間片就是在任務優(yōu)先級相同的情況下才會發(fā)生作用。

比如,任務 1 設置 5 個時間片(即Systick中斷時間),任務 2 設置 10 個時間片,如果兩個任務的優(yōu)先級一樣,那么在 15 個時間片內(nèi),任務 1 將執(zhí)行 5 個時間片,之后切換到任務 2 執(zhí)行10個時間片,來回往復。

那么比任務1 和任務 2 優(yōu)先級更高的任務該什么時候執(zhí)行呢?答案是隨時,即只要高優(yōu)先級任務有需要,那么不管任務 1 和 任務 2 是否主動釋放 CPU,都會被操作系統(tǒng)強制切換到高優(yōu)先級任務中執(zhí)行(由 Systick完成,所以可能會有一點延時)。

那么優(yōu)先級比它們低的任務呢?這個就靠它們的自覺了,如果它們自覺的主動釋放CPU(比如調(diào)用系統(tǒng)延時函數(shù)),那么低優(yōu)先級任務就有執(zhí)行機會,否則,低優(yōu)先級任務將不會執(zhí)行!

該用一張圖來說明整個系統(tǒng)的優(yōu)先級關(guān)系了:

最后魚鷹再聊聊該如何設置任務優(yōu)先級。

很多人設計任務優(yōu)先級時都會從 0、1、2、3 這樣的順序來設置,實際上,這種設置是不合理的,因為一旦后面需求變化了,要從中加入一個中間的優(yōu)先級,那么很可能在加入后程序出現(xiàn)問題了。

其實我們可以從 Cortex-M3 的中斷優(yōu)先級得到啟發(fā),即空開部分優(yōu)先級不使用,留待后面擴展用,比如設計優(yōu)先級時可以設置成 3、5、7、9、11,留出最高的0~2用于可能的高優(yōu)先級任務,中間空出一個或兩個優(yōu)先級用于擴展,這樣一旦后面需要增加其他優(yōu)先級的任務,會顯得異常簡單(可能會有額外的一點內(nèi)存損耗,但卻是值得的)。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 嵌入式
    +關(guān)注

    關(guān)注

    5087

    文章

    19145

    瀏覽量

    306134
  • 嵌入式系統(tǒng)
    +關(guān)注

    關(guān)注

    41

    文章

    3604

    瀏覽量

    129562

原文標題:嵌入式系統(tǒng)優(yōu)先級詳解

文章出處:【微信號:strongerHuang,微信公眾號:strongerHuang】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    【「嵌入式Hypervisor:架構(gòu)、原理與應用」閱讀體驗】+第7-8章學習心得

    這是一本很好的學習嵌入式的書籍。 在深入學習《嵌入式Hypervisor:架構(gòu)、原理與應用》的第7-8章后,我對嵌入式Hypervisor的架構(gòu)、原理及其在實際應用中的重要性有了更為深
    發(fā)表于 10-09 18:50

    freertos中斷優(yōu)先級在哪設置

    FreeRTOS是一個流行的實時操作系統(tǒng),它廣泛應用于嵌入式系統(tǒng)開發(fā)。在FreeRTOS中,中斷優(yōu)先級是一個重要的概念,因為它決定了中斷處理的順序和響應時間。 1. 理解中斷優(yōu)先級
    的頭像 發(fā)表于 09-02 14:17 ?712次閱讀

    APS智能優(yōu)化排產(chǎn)軟件優(yōu)先級應用

    資源、訂單需求和約束條件,自動計算出最優(yōu)的生產(chǎn)計劃。在這個過程中,訂單排產(chǎn)的優(yōu)先規(guī)則起著至關(guān)重要的作用。1.交期優(yōu)先級交期優(yōu)先級是訂單排產(chǎn)中最基本的
    的頭像 發(fā)表于 06-26 17:43 ?410次閱讀
    APS智能優(yōu)化排產(chǎn)<b class='flag-5'>軟件</b>的<b class='flag-5'>優(yōu)先級</b>應用

    從事嵌入式方向,一定要軟硬件通吃?

    嵌入式系統(tǒng)開發(fā)領域,軟件和硬件的界限常常模糊不清。一個常見的問題是,嵌入式軟件工程師是否需要了解硬件。本文將探討這一問題的重要性,并分析
    的頭像 發(fā)表于 06-05 08:10 ?1231次閱讀
    從事<b class='flag-5'>嵌入式</b>方向,一定要軟硬件通吃?

    systick的中斷優(yōu)先級是否應該設置為最高優(yōu)先級的嵌套中斷?

    最近在學習ucosii有這樣一個疑問,關(guān)于stm32的systick作為ucosii的基準時鐘,systick的中斷優(yōu)先級是否應該設置為最高優(yōu)先級的嵌套中斷。理由是什么?各位大俠求指教?。?!
    發(fā)表于 05-16 06:44

    創(chuàng)建了兩個task如果一個優(yōu)先級高 一個優(yōu)先級低,高優(yōu)先級的那個一直在做,什么時候會調(diào)度到低優(yōu)先級的呢?

    創(chuàng)建了兩個task如果一個優(yōu)先級高一個優(yōu)先級低, 我看到任務的函數(shù)都是用死循環(huán)做的,那個高優(yōu)先級的那個一直在做,什么時候會調(diào)度到低優(yōu)先級的呢?
    發(fā)表于 05-13 07:13

    嵌入式實時操作系統(tǒng)中的優(yōu)先級反轉(zhuǎn)問題

    死鎖預防是實時系統(tǒng)設計中的一個重要因素。不幸的是,即使使用安全排除技術(shù),這可能也不是困難的終點。在解決資源爭用問題時,可能引入新的優(yōu)先級翻轉(zhuǎn)問題。
    發(fā)表于 04-26 15:47 ?486次閱讀
    <b class='flag-5'>嵌入式</b>實時操作系統(tǒng)中的<b class='flag-5'>優(yōu)先級</b>反轉(zhuǎn)問題

    嵌入式環(huán)境的中斷調(diào)試步驟操作

    確保問題中斷的優(yōu)先級設置正確。它應該高于正常工作的中斷的優(yōu)先級,但低于任何應該優(yōu)先于它的中斷的優(yōu)先級。
    發(fā)表于 04-09 10:41 ?383次閱讀

    嵌入式實時操作系統(tǒng)優(yōu)先級搶占調(diào)度機制解析

    當搶占發(fā)生時,任務即使沒有完成也會被迫放棄處理器,此時任務并沒有被掛起,而是會返回就緒隊列。任務在隊列中的位置是由優(yōu)先級決定的,它會在隊列中等待到下一次被調(diào)度。
    的頭像 發(fā)表于 04-05 05:22 ?2862次閱讀
    <b class='flag-5'>嵌入式</b>實時操作系統(tǒng)<b class='flag-5'>優(yōu)先級</b>搶占<b class='flag-5'>式</b>調(diào)度機制解析

    STM32F103的寄存器NVIC_IPRx搶占優(yōu)先級和子優(yōu)先級是怎么設置的?

    STM32F103的寄存器NVIC_IPRx有些不明白,搶占優(yōu)先級和子優(yōu)先級是怎么設置的? 如果,中斷分組2,搶占優(yōu)先級3,子優(yōu)先級3 那下面這樣寫對嗎? SCB->AIR
    發(fā)表于 03-27 07:48

    嵌入式C語言中斷調(diào)試步驟

    確保問題中斷的優(yōu)先級設置正確。它應該高于正常工作的中斷的優(yōu)先級,但低于任何應該優(yōu)先于它的中斷的優(yōu)先級。
    的頭像 發(fā)表于 03-26 12:20 ?712次閱讀

    Hightec對芯片中斷優(yōu)先級分配時,中斷號越高中斷優(yōu)先級越高嗎?

    請問大佬,Hightec對芯片中斷優(yōu)先級分配時,中斷號越高中斷優(yōu)先級越高嗎?看網(wǎng)上的帖子說中斷號越低優(yōu)先級越高。
    發(fā)表于 02-27 06:13

    RTTnano的用戶main函數(shù)中的優(yōu)先級是多少?

    RTTnano 的用戶main函數(shù)中的優(yōu)先級是多少?為什么會出現(xiàn)創(chuàng)建新的task之后,main函數(shù)會搶占掉低優(yōu)先級的task,例如RT_THREAD_PRIORITY_MAX設置為8 ,低于3
    發(fā)表于 02-26 08:01

    嵌入式軟件設計的原則分享

    嵌入式軟件開發(fā)如果具有更好的閱讀、擴展性以及維護,就需要考慮很多因素。今天給大家分享幾個嵌入式軟件
    發(fā)表于 02-25 10:54 ?714次閱讀
    <b class='flag-5'>嵌入式</b><b class='flag-5'>軟件</b>設計的原則分享

    華為和思科默認路由優(yōu)先級

    優(yōu)先級值不同,則優(yōu)先級值最小的為最優(yōu)路由(無論開銷值是否相同,另一種理解就是對不同路由來源或路由協(xié)議之間的比較)。
    的頭像 發(fā)表于 01-11 10:47 ?1306次閱讀