傳統上，程序員和組織對使用中斷有一種不合理的恐懼。如果沒有遵循正確的中斷實現，系統肯定會發生奇怪的事情。那么，嵌入式開發人員怎樣才能確保中斷被正確地實現，并按照預期的那樣被利用呢?

　　技巧1——創建ISR表

　　中斷服務例程表是一個數組，包含微控制器上可能發生的所有中斷的列表。每個中斷都由中斷發生時執行的函數(指向函數的指針)填充，這樣做有很多好處。首先，將一個函數調用分配給一個中斷變得非常容易。只需更改表中的函數名，重新編譯，現在中斷發生時該函數將被調用。

　　接下來，程序員為每個中斷包含一個函數，這是一個很好的實踐，因為每個中斷都是用代碼初始化的!在調試期間，如果發生了錯誤的中斷，而不是跳開并執行未知代碼，則可以改為執行“DummyISR”，這讓錯誤的中斷被捕獲和調試。最后，以這種方式使用中斷表迫使中斷代碼采取易于理解和配置的有組織的結構。

　　有許多不同的方法可以實現該表。最常見的是通過使用#pragma。這允許將表放在閃存中的特定存儲位置。最常見的兩種實現是允許指定閃存位置的起始地址或定義鏈接器內存標簽。嵌入式開發人員應該盡量避免使用#pragma，但是如果這是實現中斷表的唯一方法，那么這將是一個很好的例外。

　　技巧2——保持簡短快速

　　根據定義，中斷是對正在執行的應用程序的正常流程的中斷。為了處理中斷，程序實際上停止了正在做的任何事情。在這種情況下，中斷服務程序顯然應該簡短扼要，以便主應用程序可以繼續執行。

　　中斷的真正目的是處理需要系統注意的緊急事件。為了保持日常工作的簡短，只做當時真正需要做的最少的事情。例如，如果通信數據觸發中斷，將數據放入緩沖區，設置一個標志，讓主程序處理數據，不要試圖在中斷中處理它!

　　保持代碼簡短而快速有時會有欺騙性。例如，做一個簡單的浮點計算(只有一行代碼)可能看起來很短，但是一個沒有硬件浮點單元的微控制器可能會花費嵌入式開發人員很長的時間來處理數學運算(也可能是毫秒)!有幾個簡單的規則可以確保中斷服務程序快速運行：

　　l 不要從你的中斷中調用函數(除非它們是內聯函數)，函數調用開銷會浪費你的時間。

　　l 任何處理器密集型活動，如處理數據緩沖區、執行計算等，都應該設置一個標志，并讓主應用程序進行處理。

　　l 應該避免Wait語句。

　　l 也應該避免循環或任何時間密集型邏輯，如循環、除法或模數運算。

　　技巧3——仔細檢查你的初始化

　　出于這樣或那樣的原因，中斷似乎總是讓正常工作變得很痛苦，它們在概念上是直截了當的，但有些實現需要大量的前瞻性思考才能正確。在設置和調試中斷時，嵌入式開發人員應該問一些問題。其中一些看起來很簡單，但是仍然應該檢查和詢問。

　　中斷是否啟用?(當然，我以為我啟用了它，但是MCU寄存器顯示什么?)

　　是否設置了中斷的優先級?

　　ISR在中斷表中的位置是否正確?

　　中斷是否映射到正確的硬件引腳?到正確的外圍設備?

　　中斷是否盡快得到確認?

　　ISR中的中斷標志是否在正確的時間被清除?

　　技巧4——盡可能少地禁用中斷

　　禁用中斷可能是一項極其危險的工作。禁用中斷會導致錯過應該處理的中斷!為什么會有人想要禁用中斷呢?有時候，開發人員希望在不中斷的情況下自動運行某些代碼部分。允許發生可能會改變計算中使用的變量的中斷可能會導致災難!因此，嵌入式開發人員可能會在“臨界區”之前禁用中斷，在啟用中斷之前執行計算或運行代碼。

　　現代32位處理器有助于最小化禁用中斷的需求，如果可能的話，當然應該不惜一切代價避免這樣做。但是，如果發現需要，安全禁用中斷是一個很好的起點，可以安全地做到這一點。禁用中斷前，應讀取并保存中斷的當前狀態。關鍵代碼段在將中斷狀態恢復到之前的狀態運行。

　　技巧5——對共享變量使用volatile

　　在ISR中遇到的最大錯誤之一是共享變量處理不當。一個中斷可能被用來填充一個緩沖區或者修改一個被應用程序其余部分使用的變量。如果應用程序將要使用這個變量，并且中斷觸發并更新這個變量，應用程序可能仍然使用舊的值!這當然會導致系統潛在的一些不可預測的行為。

　　C語言有一個名為volatile的關鍵字，其目的是在每次使用時強制重新讀取變量。每當變量可能被程序正常運行時之外的進程修改時，嵌入式開發人員就可以使用它。它通常在訪問硬件寄存器時使用。硬件可以在程序不知道的情況下改變存儲的值，所以內存映射變量被聲明為volatile。由于中斷可以在程序不知道的情況下隨時改變值，所以與ISR共享的變量也應該聲明為volatile。

　　技巧6——了解ISR的時間安排

　　微控制器最常用于具有硬實時或至少軟實時要求的實時系統。以簡單的上下文切換到中斷為例。這可能需要四到二十個時鐘周期。這似乎不值得一提，但事實上情況可能更糟!對于以8 MHz運行的微控制器，這可能是500到2500納秒的延遲。這只是一個上下文切換到中斷!離開中斷的時候還有一個!

　　上下文切換計時值得理解，但更有趣的是中斷運行時的剩余部分。開發人員的代碼運行需要多長時間?畢竟，這才是真正可以改變和控制的部分。就像應用程序的其余部分一樣，理解這種時序的最簡單方法是在ISR的開始和結束時切換anI/O位，這可以讓開發人員了解中斷時序。

　　嵌入式開發人員確實需要了解周期性和異步中斷發生的頻率，這樣他們才能確保程序的其余部分有機會運行。了解中斷是否有可能同時發生，以及它們是否了解一次完成和下一次運行之間的延遲，也很重要。嵌套中斷會極大地影響系統的運行，為了實現實時性能，工程師需要了解與時序相關的電位問題。

　　技巧7——利用中斷驅動架構

　　越來越多的應用程序正在走向移動化，并依賴電池為它們提供運行時電源。為了最大化電池壽命和運行時間，微控制器需要盡可能多的時間處于睡眠狀態。最好的方法是利用中斷驅動架構。在這種架構中，系統處于非常低的功耗狀態，微控制器內核基本上處于關閉狀態，這在輪詢系統中是無法實現的，然后系統被一個中斷喚醒，這可能是一個外部事件或內部計時器。系統醒來，做它需要做的事情，然后回到睡眠狀態。

　　目前可用的微控制器架構有一些很好的技巧，可以用來幫助最大限度地延長低功耗模式下的時間。例如，通過使用中斷來喚醒系統，可以確保只有一個事件可以喚醒系統，但更重要的是，系統可以設置為不會發生到中斷的上下文切換!系統在中斷中喚醒，然后使用一種特殊的模式，稱為“休眠退出”，一旦中斷完成，系統立即返回休眠狀態!

　　這些只是一些技巧，可以幫助任何開發人員在調用中斷時做出正確的選擇。當然，有些時候需要使用輪詢技術，但是當中斷是合理的并且具有設計意義時，嵌入式開發人員使用這些技巧來確保正確設置中斷，這將節省大量的時間和調試基于中斷的系統的麻煩。