概述

通過 Microsoft Windows CE .NET，Microsoft 已經升級了 Windows CE 的中斷體系結構。該操作系統(tǒng) (OS) 所具有的處理共享中斷的能力極大地擴展了 Windows CE .NET 支持許多中斷體系結構的能力。本文從原始設備制造商 (OEM) 和應用程序開發(fā)人員的角度探討了處理中斷的方案。本文還探討了 OEM 適配層 (OAL) 中斷服務例程 (ISR) 處理；提供了可安裝 ISR，包括一個簡單的入門級外殼程序；介紹了中斷服務線程 (IST) 中斷處理，并提供了一個初始化和執(zhí)行模板。最后，本文分析了 ISR 和 IST 的延遲根源。

返回頁首

中斷體系結構

探討 Microsoft Windows CE .NET 中斷體系結構的第一步是定義中斷過程中硬件、內核、OAL 和線程交互的總體模型。下圖大概說明了這些不同級別的職責以及導致狀態(tài)變化的轉換。

圖 1.

該圖闡述了中斷過程中的主要轉換，時間按從左到右的順序遞增。該圖的最低層為硬件和中斷控制器的狀態(tài)。次低層是中斷服務過程中的內核交互。OAL 描述了主板支持軟件包 (BSP) 的職責。最頂層闡述了中斷服務所需的應用程序或驅動程序線程交互。該圖闡述了單個中斷過程中的交互；它表示了 Windows CE .NET 擁有共享中斷的新能力。

活動從該圖最左側部分以直線表示的中斷開始。生成了一個異常，導致內核 ISR 向量被加載到處理器中。內核 ISR 與硬件交互，禁用所有處理器上的所有具有相同和較低優(yōu)先級的中斷（ARM 和 Strong ARM 體系結構除外）。然后，內核推進到已為該特定中斷注冊的 OAL ISR。此后，OAL ISR 既可以直接處理中斷，也可以使用 NKCallIntChain 遍歷已安裝的 ISR 列表。主 ISR 或任何已安裝的 ISR 隨后執(zhí)行任意工作，并且為該設備返回名為 SYSINTR 的映射中斷。如果該 ISR 確定其相關設備沒有導致該中斷，該 ISR 將返回 SYSINTR_CHAIN，這會使 NKCallIntChain( ) 遍歷 ISR 列表以到達鏈中的下一個中斷。ISR 按照它們的安裝順序調用（它們在安裝時會在調用列表上創(chuàng)建一個優(yōu)先級）。

在調用了單個 ISR 或其相關 ISR 鏈之后，返回值可能為下列值之一：

返回值

操作

SYSINTR_NOP	中斷不與設備的任何已注冊 ISR 關聯(lián)。內核啟用所有其他中斷。
SYSINTR	中斷與已知的已注冊 ISR 和設備關聯(lián)。
SYSINTR_RESCHED	中斷是由請求 OS 重新調度的計時器到期引起的。

SYSINTR 返回值是我們討論的重點。一旦 ISR 完成，內核將重新啟用處理器上除已識別的中斷之外的所有中斷。然后，內核將通知與 SYSINTR 值關聯(lián)的事件。

然后，驅動程序或應用程序的 IST 將能夠運行（假設它是準備好運行的最高優(yōu)先級線程）。IST 將與相關設備通訊，并從完成它的中斷交互的設備中讀取所有必要的數(shù)據。然后，IST 用關聯(lián)的 SYSINTR 值來調用 InterruptDone( )，以通知它已完成。

內核在接收到 SYSINTR 值的 InterruptDone 時，將重新啟用指定的中斷。只有從這時開始，才能接收該設備的其他中斷。

這只是對 Windows CE .NET 內部活動的中斷序列的一個粗略介紹。現(xiàn)在，我們將詳細研究上述每個組件及其職責。

返回頁首

OAL ISR 處理

OAL ISR 是屬于平臺的基本中斷處理程序。下面是 X86 平臺的實際 ISR。配置分析和 ILTiming 支持已被刪除。X86 ISR 是所有基于 Windows CE 的平臺的代表。它演示了能夠處理系統(tǒng)中所有中斷的單個 ISR。

該 ISR 的目標是向內核交還引起中斷的相關設備的 SYSINTR 號。ISR 執(zhí)行以下活動序列。

• 從 PICGetCurrentInterrupt (PIC) 中獲取當前硬件中斷

• 如果該中斷是 INTR_TIMER0（系統(tǒng)計時器）

  • 更新OS 的 CurMSec 保持時間

  • 檢查并確認是否已經注冊了重新啟動地址 (RebootHandler)

• 如果中斷是 INTR_RTC

  • ISR 檢查并確認鬧鐘是否已到期 (SYSINTR_RTC_ALARM)

• 如果中斷小于 INTR_MAXIMUM

  • 調用中斷鏈 (NKCallIntrChain)

  • 將 NKCallIntrChain 的返回值設置為該返回值

  • 如果中斷鏈未包含中斷：(SYSINTR_CHAIN)

    映射當前硬件中斷 (OEMTranslateIRQ)

    如果該中斷被注冊到 OEMInit 中的 HookInterrupt

    從 OEMTranslateIRQ 返回 SYINTR 值

    如果該中斷未注冊，則返回 SYSINTR_NOP

  • 啟用除當前中斷以外的所有中斷。(PICEnableInterrupt}

  • 完成恰當?shù)闹袛嘟Y束工作以通知 PIC 中斷已完成 (EOI)

• ISR 返回下列值之一：

  • SYSINTR_NOP — 沒有任何 ISR 包含該中斷

  • SYSINTR_RESCHED — 重新調度計時器已到期

  • SYSINTR — ISR 已經包含該中斷

  • SYSINTR_RTC_ALARM — 鬧鐘已到期

ULONG PeRPISR(void) { ULONG ulRet = SYSINTR_NOP; UCHAR ucCurrentInterrupt;ucCurrentInterrupt = PICGetCurrentInterrupt();if (ucCurrentInterrupt == INTR_TIMER0) {CurMSec += SYSTEM_TICK_MS;CurTicks.QuadPart += TIMER_COUNT;if ((int) (CurMSec - dwReschedTime) >= 0)ulRet = SYSINTR_RESCHED;}//// Check if a reboot was requested.//if (dwRebootAddress) {RebootHandler();}} else if (ucCurrentInterrupt == INTR_RTC) {UCHAR cStatusC;// Check to see if this was an alarm interruptcStatusC = CMOS_Read( RTC_STATUS_C);if((cStatusC & (RTC_SRC_IRQ)) == (RTC_SRC_IRQ))ulRet = SYSINTR_RTC_ALARM;} else if (ucCurrentInterrupt <= INTR_MAXIMUM) { // We have a physical interrupt ID, return a SYSINTR_ID// Call interrupt chain to see if any installed ISRs handle this// interruptulRet = NKCallIntChain(ucCurrentInterrupt);if (ulRet == SYSINTR_CHAIN) {ulRet = OEMTranslateIrq(ucCurrentInterrupt);if (ulRet != -1)PICEnableInterrupt(ucCurrentInterrupt, FALSE);elseulRet = SYSINTR_NOP;} else {PICEnableInterrupt(ucCurrentInterrupt, FALSE);}}if (ucCurrentInterrupt > 7 || ucCurrentInterrupt == -2) {__asm {mov al, 020h ; Nonspecific EOIout 0A0h, al}}__asm {mov al, 020h ; Nonspecific EOIout 020h, al}return ulRet; }

如果 ISR 沒有為已經用 OAL 的 OEMInit 中的 HookInterrupt 初始化的中斷安裝，則該 ISR 將返回適當?shù)?SYSINTR 值。

注 如果只能通過 IST 交互為設備提供服務，則不需要為中斷安裝可安裝的 ISR。通過對 OAL 的 OEMInit 中的 HookInterrupt 進行調用以啟用中斷就足夠了。

ISR 代碼是一段非常小且快速的代碼。它的執(zhí)行時間將直接影響整個系統(tǒng)中的中斷的延遲。Windows CE 3.0 中引入的中斷體系結構更改是能夠嵌套中斷。在進入 OAL ISR 的那一刻，所有具有較高優(yōu)先級的中斷都已被啟用。ISR 可能被占先。如果該 ISR 內部的計時非常關鍵，則可能要求在該時間段內禁用中斷。就像 ISR 執(zhí)行時間一樣，中斷被關閉的這一時間將增加平臺的最差情形延遲。

當 ISR 交還與特定設備相關的 SYSINTR 時，內核將通知 IST 醒來。處理驅動程序或應用程序內部代碼的 IST 中斷負責結束中斷交互。

返回頁首

可安裝的 ISR

可安裝的 ISR 是為響應 Windows CE .NET 為嵌入式空間帶來的開放性而創(chuàng)建的。OEM 再也不必完全負責平臺和應用程序代碼了。現(xiàn)在平臺提供商和應用程序開發(fā)人員都可涉及嵌入式空間這一領域的工作。如果某個應用程序開發(fā)人員在使用 Windows CE 3.0 的平臺上向開放總線添加了新的設備，OEM 將必須說服該 OEM 將 ISR 添加到該平臺。

要將 ISR 安裝到平臺中，需要完成兩個步驟：

• 調用 LoadIntChainHandler 函數(shù)以加載包含 ISR 代碼的 DLL。

• 必須將 ISR 編碼為用 SYSINTR_ . . . 響應進行響應，就像在 OAL ISR 中一樣。

LoadIntChainHandler 函數(shù)將 ISR 動態(tài)鏈接庫 (DLL) 加載到內核的地址空間中。這意味著代碼不能調用任何非內核函數(shù)，包括任何 C 語言運行時庫函數(shù)。記住，某些結構到結構賦值會降格為 memcpy 調用，必須檢查所有代碼以確保不需要任何外部庫（即使這些庫是由編譯器創(chuàng)建的）。

下面的源代碼示例說明了一個用于創(chuàng)建可安裝的 ISR 的基本外殼程序。有四個函數(shù)：

• DLLEntry — 接收進程和線程附加消息

• InfoCopy — 在進行任何結構賦值時使用的復制例程

• IOControl — 任何使用 KernelLibIOControl 的 IST 調用的處理程序

• ISRHandler — 實際的 ISR

BOOL __stdcall DllEntry( HINSTANCE hinstDll,DWORD dwReason,LPVOID lpReserved ) {if (dwReason == DLL_PROCESS_ATTACH) {}if (dwReason == DLL_PROCESS_DETACH) {}return TRUE; }// The compiler generates a call to memcpy() for assignments of large objects. // Since this library is not linked to the CRT, define our own copy routine. void InfoCopy( PVOID dst, PVOID src, DWORD size ) {while (size--) { *((PBYTE)dst)++ = *((PBYTE)src)++; } }BOOL IOControl( DWORD InstanceIndex,DWORD IoControlCode, LPVOID pInBuf, DWORD InBufSize,LPVOID pOutBuf, DWORD OutBufSize, LPDWORD pBytesReturned ) { switch (IoControlCode) {case IOCTL_DEMO_DRIVER: // Your I/O Code Herereturn TRUE;break;default:// Invalid IOCTLreturn FALSE; }return TRUE; }DWORD ISRHandler( DWORD InstanceIndex ) {BYTE Value;Value = READ_PORT_UCHAR((PUCHAR)IntrAddress );// If interrupt bit set, return corresponding SYSINTR if ( Value & 0x01 ) {return SYSINTR_DEMO; } else {return SYSINTR_CHAIN; } }

ISR 處理程序代碼使用端口 I/O 調用來檢查設備的狀態(tài)。您的方案可能要求復雜得多的詢問。如果該設備不是中斷源，則返回值將是 SYSINTR_CHAIN。此返回值告訴 NKChainIntr 函數(shù)該設備不是中斷源，應該評估鏈中的其他 ISR。如果 ISR 返回有效的 SYSINTR，則 NKChainIntr 將立即返回并且不調用列表中的任何其他 ISR。這將提供優(yōu)先級排序。第一個加載的可安裝 ISR 被首先加載到該列表中（或具有最高優(yōu)先級），然后將后續(xù)可安裝 ISR 添加到該列表的底部。由于優(yōu)先級和執(zhí)行速度這兩方面的原因，應該首先安裝鏈中具有最高優(yōu)先級的可安裝 ISR。

返回頁首

IST 中斷處理

處理來自應用程序或驅動程序的中斷需要進行兩個步驟的處理。首先，必須使用關聯(lián)的事件初始化中斷。其次，IST 必須等待中斷事件以響應內核中的中斷。

中斷初始化

以下示例代碼將設置 IST 并將 IST 與特定的中斷相關聯(lián)。初始化中斷的關鍵步驟包括：

• 創(chuàng)建事件

• 獲取 IRO 的系統(tǒng)中斷號

• 創(chuàng)建掛起的中斷線程 (IST)

• 調用 InterruptInitialize 以創(chuàng)建 IRQ 與事件之間的關聯(lián)

  • 創(chuàng)建未掛起的 IST 可能會導致 InterruptInitialize 失敗，因為該事件已經處于被等待狀態(tài)

• 將線程優(yōu)先級設置為相應的優(yōu)先級

• 恢復 IST

Void SetupInterrupt( void ) { // Create an event // g_hevInterrupt = CreateEvent(NULL, FALSE, FALSE, NULL); if (g_hevInterrupt == NULL) {RETAILMSG(1, (TEXT("DEMO: Event creation failed!!!\r\n")));return; }// Have the OAL Translate the IRQ to a system irq // fRetVal = KernelIoControl( IOCTL_HAL_TRANSLATE_IRQ, &dwIrq,sizeof( dwIrq ),&g_dwSysInt,sizeof( g_dwSysInt ),NULL );// Create a thread that waits for signaling // g_fRun = TRUE; g_htIST = CreateThread(NULL, // Security0, // No Stack SizeThreadIST, // Interrupt Thread NULL, // NoParametersCREATE_SUSPENDED, // Create Suspended&dwThreadID // Thread Id);// Set the thread priority – arbitrarily 5 // m_nISTPriority = 5; if( !CeSetThreadPriority( g_htIST, m_nISTPriority )) {RETAILMSG(1,(TEXT("DEMO: Failed setting Thread Priority.\r\n")));return; }// Initialize the interrupt // if ( !InterruptInitialize(g_dwSysInt,g_hevInterrupt,NULL,0) ) {RETAILMSG (1, (TEXT("DEMO: InterruptInitialize failed!!!\r\n")));return; }// Get the thread started // ResumeThread( g_htIST );}

需要注意的是，對 InterruptInitialize 的調用僅采用 SYSINTR 值和事件作為參數(shù)。內核不知道或者不關心將要等待該事件的線程。這樣，就可以建立多種應用程序和驅動程序體系結構。應用程序的簡單主循環(huán)可以初始化中斷，然后立即等待該事件。中斷只能與一個事件關聯(lián)，并且該事件不能用于對 WaitForMultipleObjects 的調用中。我們將觀察一個簡單的為中斷提供服務的線程。這是大多數(shù)實現(xiàn)中的標準解決方案。

IST － 中斷服務例程

本節(jié)提供了一個 IST 的示例代碼。該 IST 中斷處理線程的關鍵組件包括：

• 等待中斷事件。

• 確認有一個來自 OS 的脈動性事件

• 執(zhí)行任何必要的板級中斷處理以完成中斷。在該示例中，我們將確認該中斷。

• 在盡可能短的時間內處理該中斷

• 創(chuàng)建 CELOGDATA 以供在 Kernel Tracker 中查看。

• 檢查并確認是否設置了 g_fPRRunning 標志，然后設置 g_hevPRStart 事件。

• 調用 InterruptDone()。

  • 在調用 InterruptDone 之前，OS 不會提供此 IRQ 上的其他中斷。

• 再次等待中斷事件。

DWORD WINAPI ThreadIST( LPVOID lpvParam ) {DWORD dwStatus;BOOL fState = TRUE;// Always chec the running flag//while( g_fRun ){dwStatus = WaitForSingleObject(g_hevInterrupt, INFINITE);// Check to see if we are finished//if(!g_fRun ) return 0;// Make sure we have the object//if( dwStatus == WAIT_OBJECT_0 ){// Do all interrupt processing to complete the interaction// with the board so we can receive another interrupt.//if (!( READ_REGISTER_ULONG(g_pBoard Register) & INTR_MASK)){RETAILMSG(1, (TEXT("DEMO: Interrupt...")));g_dwInterruptCount ++;}// Finish the interrupt//InterruptDone( g_dwSysInt );}}return 0; }

該示例讀取一個 ULONG 寄存器以確定中斷狀態(tài)。您只需用您的代碼替換該代碼段。非常關鍵的一點是，要使 IST 處理盡可能地簡單。如果將來需要處理來自該設備的數(shù)據：

• 在 IST 中盡可能快速地從該設備獲取數(shù)據。

• 創(chuàng)建一個事件，以通知某個優(yōu)先級較低的線程完成該工作。

• 通過 InterruptDone 從該 IST 中立即返回。

• 讓優(yōu)先級較低的線程進一步處理數(shù)據。

• 在 IST 與優(yōu)先級較低的線程之間放置 FIFO 以處理溢出。

返回頁首

導致延遲的因素

從 Windows CE .NET 中的中斷體系結構示意圖中，可以了解硬件、內核、OAL 與驅動程序/應用程序線程之間的交互。Microsoft 已經提供了多種工具（包括 ILTiming、CEBench 和 Kernel Tracker），以便幫助您評估平臺上的 Windows CE .NET 的性能。通過了解導致 ISR 和 IST 延遲的因素，有助于確定調查領域。

ISR 延遲

正如您在本文前面的中斷體系結構示意圖中可以看到的，ISR 延遲被定義為從發(fā)生中斷到 OAL ISR 首次執(zhí)行之間的時間。因為當中斷被關閉時，中斷不會在處理器中引發(fā)異常，所以第一個導致延遲的因素是系統(tǒng)中的中斷被關閉的總時間。在每個機器指令開始執(zhí)行時都將檢查是否有處理器中斷。如果調用了長字符串移動指令，則會鎖定中斷，從而造成第二個延遲源，即總線訪問鎖定處理器的時間量。第三個因素是內核導向 OAL ISR 處理程序所花費的時間量。這是一個進程上下文切換。總之，導致 ISR 延遲的因素包括：

• 中斷被關閉的時間。

• 總線指令鎖定處理器的時間。

• 內核 ISR 的執(zhí)行時間加上導向 OAL ISR 的時間。

IST 延遲

本文前面的體系結構示意圖中顯示，IST 延遲是從中斷發(fā)生到執(zhí)行 IST 中的第一行代碼之間的時間量。這與 Windows CE .NET 中的 Microsoft 度量工具的輸出不同。Microsoft 工具將 IST 延遲定義為從 OAL ISR 執(zhí)行結束到 IST 開始之間的時間。因為標準的 ISR 花費的時間很少，您需要將 ISR 延遲和 Microsoft 度量工具所得到的 IST 延遲加起來，才能獲得“中斷體系結構示意圖”中所定義的 IST 延遲。

導致 IST 延遲的第一個因素是本文前面定義的 ISR 延遲。第二個因素是 ISR 執(zhí)行時間。根據共享中斷調用鏈的長度的不同，此時間是可變的。對于延遲較小的情況，沒有必要對永遠不會被共享的中斷調用 NKCallIntChain。

Windows CE 中的內核函數(shù)（如計劃程序）被稱為 KCALL。在這些 KCALL 執(zhí)行期間，將設置一個軟件標志，以便讓計劃程序知道它此時不能被中斷。仍然將調用 ISR，但用于重新調度 OS 或調度 IST 的返回值將被延遲，直至 KCALL 完成為止。這一不可占先的時間是導致 IST 延遲的第三個因素。最后，內核必須調度 IST。這一上下文切換是導致延遲的最后一個因素。總之，導致 IST 延遲的因素包括：

• ISR 延遲時間

• OAL ISR 執(zhí)行時間

• OS 執(zhí)行 KCALL 的時間

• 調度 IST 的時間

返回頁首

小結

通過 Windows CE .NET，Microsoft 已經升級了 Windows CE 中斷體系結構。該 OS 所具有的處理共享中斷的能力極大地擴展了 Windows CE .NET 支持許多中斷體系結構的能力。這一中斷體系結構方面的知識可以大大加快調查驅動程序和延遲問題的速度。操作系統(tǒng)交互模型是了解該體系結構的關鍵。共享中斷已經大大提高了 Windows CE .NET 的開放性，能夠支持遍布于不同公司之間以及公司內部的平臺提供商和應用程序開發(fā)人員方案。了解延遲根源將有助于診斷驅動程序和實時問題。Windows CE .NET 中的中斷結構定義完善且易于理解。簡而言之，“它不是魔術！”

總結

以上是生活随笔為你收集整理的Microsoft Windows CE .NET 中的中断体系结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。