我們在使用ARM Cortex-M內核芯片進行產品開發時，有時可能需要暫時開辟一個相對清靜、不被打擾的程序執行環境，以確保某些操作可靠順利完成。這時我們往往會使用所謂開、關總中斷的指令代碼來完成。我們可以對特殊功能寄存器PRIMASK寫1來關閉/屏蔽優先級不高于0【數字大于0】的所有可配置中斷的中斷響應。對其寫0，放棄關閉/屏蔽功能，即所謂的開總中斷。

關于使用PRIMASK寄存器關閉/屏蔽所有可配置中斷的做法還有其它等效操作，比如使用CPSID指令和CPSIE指令或調用相關CMSIS函數。【如下圖所示，左邊是匯編指令，右邊是對應CMSIS函數】

不過，在實際應用中很多人對這這個關、開總中斷操作有些誤解，尤其對關總中斷誤解更甚。以為關總中斷就在NVIC那里關閉了所有中斷響應允許，或者說連外設端的中斷請求的使能也關閉了，中斷請求事件標志也無效了，其實并不是這樣的。若出于誤解而使用開、關總中斷指令或函數往往就得不到自己想要的結果、或者結果讓人困惑不解。

下面基于Cortex -M4內核的STM32L4芯片做些驗證。這里我們拿STM32L476開發板驗證下相關內容【具體使用哪款STM32芯片不重要】。

我這里開啟片內TIM1/TIM2/TIM3/TIM4四個定時器的更新事件中斷，其中TIM1/TIM2/TIM3的時間參數完全一樣，而TIM4跟前三者相比，除了溢出時間參數【就是ARR】稍微小一點外，其它配置一樣，四者同時啟動，并確保讓TIM4一定先進入中斷服務程序[即ISR]。

它們的中斷優先級設置各不相同，TIM4的最低。現在假設TIM4中斷服務程序里要執行一段特別重要的事情，通過代碼設計保證CPU剛進入TIM4中斷服務程序時另外3個定時器一定還沒有觸發更新事件。為了便于測試，我也確保啟動程序后每個TIMER都只產生一次更新事件。他們的優先級配置如下圖所示【此處優先級高4位全部用作搶占優先級，子優先級都一樣，不做配置】：

上面各中斷優先級的數字是基于優先級寄存器的高4位而言的，顯然TIM4的優先級最低【數字越大優先級越低】。我在CPU進入TIM4 ISR時立即調用所謂的關閉總中斷函數，然后一段時間后才調用所謂的打開總中斷的函數，確保TIM4 ISR執行完畢之前另外3個TIMER的更新中斷請求都產生了。

我在每個中斷ISR里執行一條輸提示，基于上面的測試代碼我們看看輸出結果【我借助于RTC把執行各中斷的時間點也輸出了】：

盡管在TIM4中斷里一開始就調用了disable_irq()函數，可是，它并沒有關閉TIM1/TIM2/TIM3的中斷請求和后續響應。從上圖不難看出，TIM4/TIM1/TIM2/TIM3依次得到響應執行。怎么感覺那個關閉總中斷的函數啥也沒關掉呢？這也正是被很多人誤會的地方。

其實，這里調用disable_irq()函數的目的就是關閉/屏蔽所有優先級不高于0的可配置中斷的響應，以保障當前TIM4 ISR的順暢執行。這就相當于將當前TIM4 的中斷優先級從4提升到0了。因此，讓原本優先級高于TIM4的TIM1/TIM2/TIM3中斷優先級反而低于當前TIM4 ISR的執行優先級，即使在TIM4 ISR過程中發生了TIM1/TIM2/TIM3中斷請求也沒法得到響應。

而且，調用disable_irq()函數并不對被關閉/屏蔽中斷的原有參數和配置做任何改變。什么意思呢？那些暫時被屏蔽中斷的中斷響應允許位、中斷請求使能位以及觸發事件標志等都不會因暫時被屏蔽而發生改變。同樣，enable_irq()函數也不改變之前被屏蔽中斷的原有參數和配置，它只是放棄剛才的屏蔽功能【或說優先級提升功能】。所以，當執行enable_irq()函數后，那些一度被屏蔽/關閉的中斷請求都會按照之前各自優先級而被CPU響應執行。

我們可以在TIM4 ISR的適當位置后打上斷點【斷點處4個TIMER的更新事件一定都產生了】看看各個中斷的響應情況：【詳見下圖】

圖中 E 、 P 、 A是下方Eable/Pending/Active單詞的首字母。Enable表示中斷請求是否在NVIC端得到響應允許；Pending表示中斷請求等待CPU的響應執行；Active表示中斷服務程序正在被執行。

顯然，只有TIM4服務程序在被執行中，其它3個都是掛起狀態，等待被響應。也就是說disable_irq()函數并不直接影響別的中斷請求的產生和響應掛起狀態，它通過提升當前執行程序的優先級變相地實現了屏蔽/關閉其它優先級不高于0的中斷請求的響應，即這個關閉是從執行效果上來說的，相當于變相提升了中斷響應門檻；enable_irq()函數相當于將提升的門檻拿走恢復原貌。

如果其它參數都不變，我注釋掉TIM4 ISR里的關閉總中斷的代碼，看看運行結果會怎么樣呢？【見下圖中TIM4 ISR 代碼和輸出結果】

雖然代碼保障了TIM4最先進入中斷服務程序，但由于其它幾個更高優先級的更新事件隨即產生而發生搶占，反而TIM4最后完成中斷執行。我們可以觀察上面輸出順序及記錄的時間點，請特別留意TIM3 ISR與 TIM4 ISR的輸出時間點是相同的，因分辨率問題時間太接近沒區分開來。不過這反而可以更清晰地看出TIM4被搶占了，TIM3一執行完馬上回到TIM4的輸出【這個結果跟TIM4的被搶占時間點密切相關】。

如果說，我在上面配置和代碼基礎上，進入TIM4 ISR后依然先關閉總中斷，在打開總中斷前對TIM1/TIM2/TIM3的幾個更新事件標志做清零，結果會怎么樣呢？【相信很多人想看看這個結果，不妨先心里猜測下。】

基于上面調整后的代碼，編譯運行。不論我怎么反復點擊運行，上圖右邊的輸出結果紋絲不動？這個結果是正確、合理的嗎？符合你心里預期否？

我這里清除的只是外設端的中斷請求事件標志，怎么早已生效的中斷請求就消失了呢？結合前面的分析，在TIM4 ISR里運行延時程序就是為了確保另外的TIM1/TIM2/TIM3的中斷請求得以生效，請求生效后并會在NVIC的中斷響應掛起寄存器的相應位置1，等待執行。

這是怎么回事呢？原理上說不通啊？

其實，我們看到的只是表象。真相是TIM1/TIM2/TIM3的ISR都得到執行了，為什么沒看到TIM1/TIM2/TIM3 ISR運行的結果輸出呢？這跟我們ISR代碼處理有關。

首先可以肯定，這里做中斷請求事件標志清零時，它們3個中斷請求早就生效并處于響應掛起狀態。對事件標志清零也不會影響到NVIC的中斷掛起位的。當TIM4 ISR執行完畢后，TIM1/TIM2/TIM3照樣基于優先級高低相繼運行各自ISR。但有個問題，就是各自的ISR代碼里都會檢測更新事件標志，由于該標志在TIM4 ISR早就被做了清除而成為無效標志，所以在它們3個各自ISR里因檢測到事件標志無效就都沒有繼續往下運行而提前退場，說直接點就是沒有運行到結果輸出代碼就返回了。

既然這樣，我不妨將輸出結果的代碼放在各自ISR的入口處，免掉檢查標志位這個環節，然后我們繼續看看結果。【結果輸出在各自更新中斷回調函數里完成。修改后的中斷代碼如下圖所示：】

基于上面的代碼調整，再看看結果輸出：

這個輸出結果就跟我們分析和預期的一致。通過這個實驗表明，對于在NVIC端生效處于響應掛起的中斷請求，只是清除相應的事件標志是不會影響它的后續執行的。如果我在上面TIM4 ISR里面執行開啟總中斷操作前希望處于掛起狀態的TIM1/TIM2/TIM3中斷請求不要再被執行了，那要如何操作呢？

首先，清除請求事件標志是應該的，而且還要清除它們各自的NVIC端的中斷響應掛起位。我們可以通過調用__NVIC_ClearPendingIRQ(IRQn)函數對特定中斷響應掛起位清零。

對TIM4 ISR代碼再稍加調整【見上圖】，運行后就只能看到TIM4 ISR的輸出結果了。其它3個中斷請求半路被TIM4 ISR給清除了，即使再開總中斷也于事無補。

關于被誤解的開、關總中斷的話題，拉拉扯扯不知不覺也聊了這么多。所謂關總中斷，實質上將當前執行程序的優先級提升到0，變相提高了期望打斷當前執行程序的中斷事件的響應門檻，開總中斷就是取消對當前執行程序的優先級提升，恢復原貌。這里順便貼出幾個常用的有關中斷響應的CMSIS函數供參考備忘。

今天的分享就到這里，愿本文的分享能帶給您一些收獲。祝君好運。下次再聊。