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

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

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

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

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

大部分滿足要求的工業(yè)自動化應用是由從一臺機器發(fā)出的外部信號驅動的。此信號以中斷形式發(fā)送給硬實時應用。微軟鼓勵Windows CE的開發(fā)人員，盡可能在中斷服務線程（IST）中置入更多的應用代碼。這使OMAC抖動定義變?yōu)獒槍Σ怀^100 μs的IST延遲的時間限制。其余被評估的應用使用計時器創(chuàng)建其周期。這就需要一臺延遲或抖動不超過100 μs的1毫秒計時器?？傊琌MAC定義提出以下設計和測試要求：

·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中安裝的工具。這些工具的用途是確定中斷定時、應用執(zhí)行動作、操作系統(tǒng)功能定時和時序安排定時。

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

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

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

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

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

ISR延遲

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

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

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

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

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

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

IST延遲

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

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

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

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

M = 調度線程的時間。

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

最高優(yōu)先級IST啟動時間 =

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

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

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

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

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

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

遠程調用評測程序

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

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

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

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

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

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

圖1. 遠程調用評測程序

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

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

內核跟蹤程序（Kernel Tracker）：

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

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

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

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

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

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

計劃程序計時分析

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

1.臨界段

2.事件設置－喚醒

3.信號發(fā)出－接收

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()函數(shù)調用上的時間進行比較。調用此函數(shù)的途徑有兩種。第一種方法較快捷，就是通過使用臨界段，實施向內核轉移，來解決資源爭用問題。第二種方法貫穿整個調用進程，其時因為不存在臨界段爭用問題，因而速度明顯提升。（此例可以解釋為什么臨界段是同步的首要考慮因素。）

中斷計時分析（ILTIMING）

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

我們來看一看基于AMD K6 500Mhz的CEPC系統(tǒng)的數(shù)字。

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

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

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

.NET Compact Framework的實時性能

Maarten Struys

Michel Verhagen

PTS軟件

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

專用系統(tǒng)，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

專用系統(tǒng)，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 嵌入式系