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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISR延遲

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

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

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

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

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

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

IST延遲

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

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

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

L = Kcall（內(nèi)核調(diào)用）中的最長時間。

M = 調(diào)度線程的時間。

在ISR返回到內(nèi)核并且內(nèi)核執(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ù)中，這意味著內(nèi)核可以擔(dān)保觸發(fā)事件的時間和釋放IST的時間有一個上限。

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

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

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

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

遠(yuǎn)程調(diào)用評測程序

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

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

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

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

表1. 遠(yuǎn)程調(diào)用評測程序中的視圖

下圖顯示的是哲學(xué)家應(yīng)用的調(diào)用圖表視圖。此圖顯示，35%的應(yīng)用時間花費在函數(shù)Eat( ) 上。也許應(yīng)該了解一下函數(shù)的內(nèi)容！

圖1. 遠(yuǎn)程調(diào)用評測程序

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

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

內(nèi)核跟蹤程序（Kernel Tracker）：

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

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

圖2. 遠(yuǎn)程內(nèi)核跟蹤程序用戶界面

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

圖3. 遠(yuǎn)程內(nèi)核跟蹤程序 — 時間增量

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

計劃程序計時分析

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

1.臨界段

2.事件設(shè)置－喚醒

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

4.互斥鎖

5.自動放棄率

6.PSL API調(diào)用開銷

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

我們來看一下幾項測試結(jié)果：

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

| 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

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

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

中斷計時分析（ILTIMING）

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

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

表3. dwOEMTPoolSize = 16 （CEPC的出廠默認(rèn)值）

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

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

.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架構(gòu)師John Eldridge

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

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

關(guān)鍵詞： 嵌入式新聞 嵌入式資料 嵌入式培訓(xùn) 嵌入式linux 嵌入式系