目前，Windows CE已從一款基本操作系統升級到體積小巧、組件化的硬實時嵌入式操作系統。盡管Windows CE具有與Win32相同的應用編程接口（API），而且微軟臺式機和服務器操作系統也配備了此類接口，但Windows CE的底層操作系統架構和臺式機的操作系統完全不同。Windows CE既支持包括Win32、MFC、ATL等在內的臺式機應用開發結構，也支持使用.NET Compact Framework的管理應用開發，還支持當前實時嵌入式系統設計，提供操作系統必要之需的實時內核。本文中，我們主要討論用于驗證Windows CE 5.0實時功效的操作系統工具。

眾所周知，實時系統并不通過單一分析進行測試，即使單一分析可以證明實時系統的正確性。實時系統的測試是詳盡討論此問題的依據。您的工作就是建立起用戶對解決方案的信任感。下文介紹的工具可以完整、實時地解釋應用程序和操作系統之間的交互作用，它們有助于您加深對實時系統的了解。

盡管關于實時的定義還存在諸多爭議，我們還是來了解一下對它的定義。這里，我引用comp.realtime FAQ的定義。實時系統的權威定義（Donald Gillies）如下：

“實時系統是這樣一種系統，即其計算正確與否，不僅取決于計算邏輯是否正確，還取決于計算結果所花費的時間。如果不能滿足系統的時間限制，就會出現系統失敗的情況?！?/STRONG>

因為集高速I/O、機器人技術和機械控制于一身的工業自動化應用對時間的要求最為苛刻。微軟開始了解實時嵌入式操作系統的特殊社會要求。自1986年以來，通用汽車動力公司（GMPTG）在制造應用中實施OMAC技術方面一直處于領先地位，并且在后來促成了OMAC用戶群的形成。他們一起對數百種應用進行評估后發現，大多數系統（95%）需要一毫秒或稍長的周期。一毫秒周期允許的變化幅度為10%，或是100微秒（μs）。這是基于200 MHz X86系統的Windows CE的設計目標，其在該平臺上的平均響應時間為50 μs。Windows CE達到或超過了95%的被評估的硬實時應用OMAC的要求。

大部分滿足要求的工業自動化應用是由從一臺機器發出的外部信號驅動的。此信號以中斷形式發送給硬實時應用。微軟鼓勵Windows CE的開發人員，盡可能在中斷服務線程（IST）中置入更多的應用代碼。這使OMAC抖動定義變為針對不超過100 μs的IST延遲的時間限制。其余被評估的應用使用計時器創建其周期。這就需要一臺延遲或抖動不超過100 μs的1毫秒計時器。總之，OMAC定義提出以下設計和測試要求：

·Interrupt Service Thread (IST) latencies of no more than 100 μs latency.

·1 millisecond timers with maximum of 100 μs latency.

·中斷服務線程（IST）延遲不超過100 μs。

·1毫秒計時器的延遲最長為100 μs。

在了解了OMAC的設計和測試要求后，接下來讓我們看看Windows CE中安裝的工具。這些工具的用途是確定中斷定時、應用執行動作、操作系統功能定時和時序安排定時。

區分實時系統和實時操作系統也很重要。實時系統包含硬件、操作系統和應用等所有元素。實時操作系統僅僅是構成實時系統的其中一個元素。如需了解更多信息，請參閱微軟Windows CE實時性能設計和優化。

我們將介紹諸多工具和用途：

·ILTiming。該工具用于確定平臺的中斷服務例程（ISR）和中斷服務線程（IST）延遲。ISR延遲是指從硬件中斷到第一次中斷服務例程指令之間的時間間隔。而IST延遲是指從現有ISR到中斷服務線程開始之間的時間間隔。

內核實時性能最重要的特性之一，就是可以在指定的時間內實施中斷。中斷延遲主要指軟件中斷處理延遲，即從外部中斷到達處理器直到中斷處理開始之間的時間間隔。

如果不發生分頁操作，Windows CE中斷延遲時間被限制于內存中鎖定的線程。這樣就可以計算最糟糕情況下的延遲時間 — 到ISR的啟動和到IST的啟動的總用時。通過計算ISR和IST所需時間，可以確定中斷處理以前的總用時。

ISR延遲

ISR延遲是指從IRQ在CUP中被設置到ISR開始運行時的時間。以下三個與時間相關的變量會影響ISR的啟動：

A = 中斷在內核中關閉的最長時間。內核很少關閉中斷，但如果將它們關閉，則關閉的時間長度會受到限制。

B = 在內核調度中斷和ISR被實際調用之間的時間。內核使用該時間確定要運行什么ISR，并保存在繼續之前必須保存的任何寄存器。

C = 在 ISR 返回到內核和內核實際停止處理中斷之間的時間。這是內核通過還原在ISR被調用之前被保存的任何狀態（例如寄存器）來完成ISR操作的時間。

正在測量的ISR的啟動時間可以基于系統中其他中斷的當前狀態進行計算。如果中斷正在進行，則計算要測量的新 ISR 的啟動時間必須考慮到兩個因素：所關注的中斷已經發生之后將發生的較高優先級中斷的數量，以及執行ISR所占用的時間。

Windows CE和原始設備制造商（OEM）都會影響執行ISR的時間。Windows CE的控制變量A、B和C都受到限制。

IST延遲

IST延遲是指從完成執行ISR即（通知線程）到IST開始執行的時間。以下四個與時間相關的變量會影響IST的啟動：

B = 內核調度中斷和真正調用ISR的時間間隔。內核利用這一時間決定將要運行什么ISR，并保存在繼續之前必須保存的任何寄存器。

C = 在ISR返回到內核和內核實際停止處理中斷之間的時間。這是內核通過還原在ISR被調用之前保存的任何狀態（例如寄存器）來完成ISR操作的時間。

L = Kcall（內核調用）中的最長時間。

M = 調度線程的時間。

在ISR返回到內核并且內核執行某些工作來開始執行IST之后最高優先級IST開始的啟動時間。在ISR返回并通知IST開始運行之后，IST啟動時間受所有ISR的總計時間的影響。下面的示例說明了所得到的啟動時間：

最高優先級IST啟動時間 =

Windows CE和OEM都會影響執行IST所需的時間。Windows CE控制變量B、C、L和M都是受限制的。OEM控制NISR和TISR(N)，它們可以影響IST延遲。

Windows CE還對IST添加了以下限制：鏈接ISR和IST的事件處理只能用在WaitForSingleObject函數中。Windows CE防止ISR-IST事件處理被用在WaitForMultipleObjects函數中，這意味著內核可以擔保觸發事件的時間和釋放IST的時間有一個上限。

·計劃程序計時分析（OSBench）：該工具允許您收集計時樣本，通過執行調度性能定時測試，測量內核的性能。

·內核跟蹤程序（Kernel Tracker）：此工具可以直觀顯示Windows CE .NET操作系統在目標設備上的執行狀況。該工具可用于在實時環境下查看線程交互、內部關聯以及系統狀態信息。本文目的是檢驗線程和進程間的交互作用。

·調用評測程序（Call Profiler）：此工具可用于確定代碼的算法瓶頸。

設備中存在許多影響實時性能的因素，如硬件、驅動程序和應用。在本例中，我們從應用級開始。運行于實時環境中的應用啟動時就應該分配所有資源。所有內核對象（進程、線程、互斥鎖、臨界段、信號和事件）都按照需要分配到虛擬內存中。按需分配內存是不確定的，因此，不能對操作系統完成操作的時間進行限制，所以它不能用于應用的實時執行中。

遠程調用評測程序

實時系統不僅包括硬件和操作系統，日益增多的應用邏輯也運行于相同的硬件之上。因此，嵌入式設計中的應用代碼可能存在失敗風險。Windows CE不會強行命令IST在設備驅動程序環境中運行，IST僅是一個特殊的線程，因此在應用環境中可以運行IST線程。既然如此，該如何檢驗應用代碼的瓶頸呢？當然，這可能會影響設備的整體性能。答案是：這正是Windows CE安裝的工具 － 遠程調用評測程序的功能。該工具可解答下列問題：何時執行何種代碼？何謂軟件組件的交互？應用程序運行時，CPU在做什么？

為了證明這一點，我采用構建、運行在Windows CE上的“哲學家就餐問題”應用。以下是解決過程：現在，五位哲學家（線程）圍坐在圓桌前。每人面前放著一碗食物。哲學家們用一支筷子開始吃飯。哲學家就餐的前提是他必須有兩支筷子（因此，五位哲學家中必須有一人奉獻出一支筷子）。這時，哲學家就必須找到一種能夠共享筷子的方法，以保證大家都能吃到碗中的食物。

同樣地，當多線程程序中有一個以上的線程（哲學家）競爭資源（食物）時，就有可能發生死鎖或爭執，當然這要取決于哲學家的饑餓程度！如果多個線程都在等待使用稀缺資源，就會造成等待時間的不確定性，進而凍結所有應用。對實時應用而言，這并不是個難題，您可以選擇遠程調用評測程序運行應用就可以解決該問題。

遠程調用評測程序可以在不同視圖中顯示調用信息，包括直觀的調用圖表。它會顯示應用運行每個函數時花費的時間。顯而易見，這是處理視頻/音頻流的實時壓縮/解壓縮問題的最為有效的工具。下表顯示的是遠程調用評測程序應用中的視圖。

表1. 遠程調用評測程序中的視圖

下圖顯示的是哲學家應用的調用圖表視圖。此圖顯示，35%的應用時間花費在函數Eat( ) 上。也許應該了解一下函數的內容！

圖1. 遠程調用評測程序

您也許會問，要運行遠程調用評測程序，需要向應用代碼中添加什么。實際上，您根本無需更改所有代碼，而僅需要用其它標志函數（WINCECALLCAP=1）進行編譯。

調用評測庫為應用開發人員提供了一幅獨特的應用邏輯執行過程細節圖。將該工具用于低速測試過程，以培養客戶對應用代碼的信任感。

內核跟蹤程序（Kernel Tracker）：

遠程內核跟蹤程序可用于檢測運行設備上的進程、線程和中斷之間的交互作用關系。下面是一些內核跟蹤程序中集成的樣本代碼。實例中的應用運行的是Windows CE設備的文件系統，其中一個文件夾在臺式機放置釋放文件，此應用為駐留在臺式機中的每個文件生成了一個KITL（內核獨立傳輸層）中斷。因此，我們可以在運行的操作系統鏡像中清晰地觀察應用與中斷間的交互作用，也可以確定應用線程運行與KITL中斷處理間的時間增量。

作為一個用戶界面，內核跟蹤程序被劃分為三個區域，左窗格顯示中斷和進程，中窗格顯示線程/進程間的交互作用，右窗格（未顯示字）中的內容是對中窗格使用的符號的解釋。我們可以在鏡像底部清楚地看到WalkTree應用正在運行，但看不到在應用和內核環境中花費的時間。

圖2. 遠程內核跟蹤程序用戶界面

內核跟蹤程序可以在事件間設置時間標記，并能在狀態欄上顯示不同的時間。內核跟蹤程序有一些預先定義的事件，如同步事件、混合事件和用戶定義事件等。此外，它還能顯示線程狀態（如運行、鎖定、休眠和移植等）。在下圖中，當從內核返回到線程執行時，我們設置了第一個時間標記，而當從線程環境切換到內核時，我們設置了第二個時間標記。

圖3. 遠程內核跟蹤程序 — 時間增量

內核跟蹤程序工具可用于定位和檢測死鎖情況，還可以檢測花費在應用和驅動程序線程上的時間。運行內核跟蹤程序也許將使系統用時增加2％－3％，但不會影響操作系統的整體定時。

計劃程序計時分析

該程序為操作系統環境的擴展集提供了測試標準。該擴展集來自超出Protected Server Library （PSL）的內部調用，而這種調用則來自集成到操作系統其中一個進程的應用（如FileSys.exe、Device.exe等）。該測試分為以下7個基本組：

1.臨界段

2.事件設置－喚醒

3.信號發出－接收

4.互斥鎖

5.自動放棄率

6.PSL API調用開銷

7.互鎖API（遞減、遞增、測試交換、交換）

我們來看一下幾項測試結果：

===================================================================

| 0.01 | IP = NO | CS = NO | 1 IPS

-------------------------------------------------------------------

EnterCriticalSection traditional (blocking) without priority inversion :

Time from a higher priority thread calling EnterCS (blocked) to a lower

priority runnable thread getting run

-------------------------------------------------------------------

| Max Time = 13.409 μs

| Min Time = 7.543 μs

| Avg Time = 8.389 μs

====================================================================

===================================================================

| 0.02 | IP = NO | CS = NO | 1000 IPS

-------------------------------------------------------------------

EnterCriticalSection fastpath (uncontested)

-------------------------------------------------------------------

| Subtracting out base result of 12 ticks

| Max Time = 0.064 μs

| Min Time = 0.061 μs

| Avg Time = 0.061 μs

===================================================================

將這些測試結果與花費在處理EnterCrticalSection()函數調用上的時間進行比較。調用此函數的途徑有兩種。第一種方法較快捷，就是通過使用臨界段，實施向內核轉移，來解決資源爭用問題。第二種方法貫穿整個調用進程，其時因為不存在臨界段爭用問題，因而速度明顯提升。（此例可以解釋為什么臨界段是同步的首要考慮因素。）

中斷計時分析（ILTIMING）

中斷計時分析可以測量系統中的中斷延遲。該工具使用諸多OAL（OEM適配層）支持功能測量ISR和IST的中斷響應時間。這些數字對于了解系統的限制至關重要。

我們來看一看基于AMD K6 500Mhz的CEPC系統的數字。

表3. dwOEMTPoolSize = 16 （CEPC的出廠默認值）

在此插入文件結束標識>Windows CE和硬實時操作系統的OMAC定義吻合，它安裝了構建、測試和部署實時設備所需的工具及資源。所有這些工具：內核跟蹤程序、遠程調用評測程序、計劃程序計時分析和中斷計時分析協同工作，可以幫助您在自己的平臺上對Windows CE的實時能力進行評估。

如需了解更多信息，請閱讀：

.NET Compact Framework的實時性能

Maarten Struys

Michel Verhagen

PTS軟件

http://msdn.microsoft.com/library/en-us/dncenet/html/Real-Time_NETCF.asp

專用系統，Windows CE 5.0實時x86處理器

http://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-TST-CE-x86-01-Iss1.00.pdf

專用系統，Windows CE 5.0實時ARM處理器

http://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-OS-CE-01-I01.pdf

就Windows CE 5.0 Real-Time Podcast采訪Windows CE架構師John Eldridge

http://blogs.msdn.com/mikehall/archive/2005/09/01/459443.aspx

Windows CE的實時決定論（Real-Time Determinism）

關鍵詞： 嵌入式新聞 嵌入式資料 嵌入式培訓 嵌入式linux 嵌入式系