中斷設計應注意哪些事項

上一期結合了UART教程講了什麼是前後台系統，然後剛好有群友討論到因為在中斷放了太多代碼導致單片機頻繁重啟。所以本期一起跟大家討論下，在嵌入式軟體中，什麼是中斷以及如何設計中斷服務函數（ISR）。

那麼什麼是中斷呢？中斷指在程序運行過程中，系統出現了一個必須由CPU立即處理的情況，此時CPU暫時中止程序的執行轉而處理這個新的情況的過程就叫做中斷。中斷處理包括發現中斷請求、響應中斷請求、中斷處理和中斷返回。在響應中斷請求前，需要通過入棧進行現場保存，以讓CPU知道當前執行到了哪裡。中斷服務程序執行以後，則出棧恢復現場，讓CPU回到中斷前的程序地址。

中斷服務程序：在響應中斷的時候，對應執行的服務函數。

中斷向量：中斷服務程序的入口地址。

對中斷有全新的認識，是在六年前剛開始工作的時候。當時項目組遇到一個問題，其中一種方案是在一個串口接收中斷函數中加上若干毫秒的硬延遲。我仍然清楚的記得當我說出這個方案的時候，項目組另外兩位大牛用像看到外星人一般的看著我說，怎麼能在中斷服務函數中加延遲？我當時還不明所以，因為之前我根本沒有深入理解什麼是中斷，而且在校期間看到不少單片機教材或者網上常式經常在中斷服務程序中加各種延遲。

為什麼不建議在中斷加入延遲？無論是在前後台系統還是RTOS中，中斷的優先順序都比後台程序或者任務更高。另外即便是中斷，不同的中斷也會有不同的優先順序。如果在某個中斷中因為代碼冗雜或者內部加了延遲，會阻塞任務或者低優先順序的中斷，大大降低嵌入式系統的實時性。舉個例子，假定你的程序中有兩個中斷，一個是定時中斷，一個是數據接收中斷。如果在定時中斷中耗時太久，那麼很有可能導致數據接收中斷無法快速響應而造成數據丟失。

回到開篇群友的問題，為什麼中斷中放了很多代碼以後，導致單片機頻繁重啟？有兩種可能，一種是開啟了看門狗，而且喂狗在後台程序中，因為中斷處理耗時太久，所以CPU一直忙於處理中斷，無暇喂狗，引發看門狗複位。還有一種可能這種情況就是RAM本就不是很充足，因為其中的一個中斷耗時長，此時又發生了中斷嵌套，上一個中斷佔用的現場保護空間還沒有釋放，另一個中斷又要重新佔用大量空間進行現場數據的保存，造成空間不夠用，從而導致堆棧溢出觸發重啟。

個人認為，中斷服務程序的一個核心原則為：短而高效。當然這邊的短不是單純指代碼量少，而是執行時間短。除了上述提到的不能加入長延遲外，這邊還建議，盡量不要在中斷中做複雜運算，例如浮點運算，函數遞歸，冗長的for循環等等。此外，合理設計中斷的優先順序也是需要重點考慮的。

本期討論就這樣啦，如果有其他想法，歡迎留言。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！