實時計算經常要求中斷針對事件快速做出響應。只要掌握Zynq SoC中斷結構的工作原理，就不難設計出中斷驅動型系統。

在嵌入式處理中，中斷表示暫時停止處理器的當前活動。處理器會保存當前的狀態并執行中斷服務例程，以便對引起中斷的原因進行尋址。中斷可能來自下列三個地方之一：
? 硬件 – 直接連接處理器的電子信號
? 軟件 – 處理器加載的軟件說明
? 異常情況 – 發生錯誤或異常事件時處理器出現的異常情況

無論中斷的來源在何處，都可將中斷的類別歸為可屏蔽和不可屏蔽兩種。您可通過在中斷掩碼寄存器中設置相應的位來安全地忽略可屏蔽中斷。但不能忽略不可屏蔽中斷，因為這類中斷通常用于定時器和看門狗監控器。

中斷的觸發既可以是邊緣觸發也可以是水平觸發。我們將在后面部分看到，賽靈思Zynq?-7000 All Programmable SoC支持中斷的這兩種配置方式。

為什么使用中斷驅動方案？

實時設計通常要求采用中斷驅動方案，因為眾多系統都會有很多輸入單元（如鍵盤、鼠標、按鈕、傳感器以及類似設備等）偶爾需要處理。這些設備的輸入單元通常會被異步至當前正在執行的進程或任務，因而用戶不可能始終準確預測事件的發生時間。

使用中斷，處理器能繼續進行處理，直到事件發生，這時處理器便可處理這一事件。此外，與輪詢方案相比，中斷驅動方案對事件的響應時間更短，在中斷驅動方案中，程序會以同步的方式主動對外部設備的狀態進行采樣。

Zynq SoC的中斷結構

隨著處理器技術不斷進步，中斷的來源也多種多樣。如圖1所示，Zynq SoC可使用通用中斷控制器（GIC）來處理中斷。GIC可處理源自以下方面的中斷：
? 軟件生成的中斷 – 每個處理器有16個此類中斷，能夠中斷一個或兩個Zynq SoC的ARM?CortexTM-A9處理器內核；
? 共享外設中斷 – 共計60個，這些中斷來自I/O外圍設備，或往返于設備的可編程邏輯（PL）側。Zynq SoC的兩個CPU共享這些中斷；
? 專用外設中斷 – 這種類型中包含的5個中斷對每個CPU都屬于專用中斷，比如CPU定時器、CPU看門狗監視器定時器以及專屬PL至CPU中斷。

共享外設中斷非常有趣，因為它們非常靈活。可將它們從I/O外設（共44個中斷）或FPGA邏輯（共16個中斷）路由至兩個CPU中的一個，但也可以將中斷從I/O外設路由至設備的可編程邏輯側，參見圖2。

在Zynq SoC上處理中斷
在Zynq SoC中發生中斷時，處理器會采取以下措施：
1. 將中斷顯示為掛起；
2. 處理器停止執行當前線程；
3. 處理器在協議棧中保存線程狀態，以便在中斷處理后繼續進行處理；
4. 處理器執行中斷服務例程，其中定義了如何處理中斷；
5. 在處理器從協議棧恢復之前，被中斷的線程繼續運行；

中斷屬于異步事件，因此可能同時發生多個中斷。為了解決這一問題，處理器會對中斷進行優先級排序，從而首先服務于優先級別最高的中斷掛起。

為了正確實現這一中斷結構，需要編寫兩個函數：一是中斷服務例程，用于定義中斷發生時的應對措施；二是用于配置中斷的中斷設置。中斷設置例程可重復使用，允許構建不同的中斷。該例程適用于系統中的所有中斷，將針對通用I/O（GPIO）設置和使能中斷。

如何在SDK中使用中斷

可使用賽靈思軟件開發套件（SDK）中的獨立板支持包（BSP）在物理硬件上支持并實現中斷。BSP具備眾多功能，可顯著降低創建中斷驅動系統的任務難度。它們位于帶有以下報頭的文件中：
? Xparameters.h – 該文件包含處理器的地址空間和設備ID；
? Xscugic.h – 該文件包含配置驅動程序以及GIC的使用范圍；
? Xil_exception.h – 該文件包含Cortex-A9的異常函數。

為了對硬件外設進行尋址，我們需要知道想要使用的設備（也就是GIC）的地址范圍和設備ID，這些信息大多位于BSP報頭文件xparameters下。但是xparameters_ps.h（無需在您的源代碼中申報該報頭文件，因為它包含在xparameters.h文件中）提供了中斷ID。我們可在源文件中使用這個標記有中斷的“ID”（GPIO_Interrupt_ID），使用方式如下：