Windows CE 5.0實(shí)時(shí)系統

眾所周知，實(shí)時(shí)系統并不通過(guò)單一分析進(jìn)行測試，即使單一分析可以證明實(shí)時(shí)系統的正確性。實(shí)時(shí)系統的測試是詳盡討論此問(wèn)題的依據。您的工作就是建立起用戶(hù)對解決方案的信任感。下文介紹的工具可以完整、實(shí)時(shí)地解釋?xiě)贸绦蚝筒僮飨到y之間的交互作用，它們有助于您加深對實(shí)時(shí)系統的了解。

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

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

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

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

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

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

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

·1毫秒計時(shí)器的延遲最長(cháng)為100 μs。

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

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

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

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

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

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

ISR延遲

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

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

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

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

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

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

IST延遲

IST延遲是指從完成執行ISR即（通知線(xiàn)程）到IST開(kāi)始執行的時(shí)間。以下四個(gè)與時(shí)間相關(guān)的變量會(huì )影響IST的啟動(dòng)：

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

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

L = Kcall（內核調用）中的最長(cháng)時(shí)間。

M = 調度線(xiàn)程的時(shí)間。

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

最高優(yōu)先級IST啟動(dòng)時(shí)間 =

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

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

·計劃程序計時(shí)分析（OSBench）：該工具允許您收集計時(shí)樣本，通過(guò)執行調度性能定時(shí)測試，測量?jì)群说男阅堋?

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

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

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

遠程調用評測程序

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

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

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

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

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

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

圖1. 遠程調用評測程序

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

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

內核跟蹤程序（Kernel Tracker）：

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

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

圖2. 遠程內核跟蹤程序用戶(hù)界面

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

圖3. 遠程內核跟蹤程序 — 時(shí)間增量

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

計劃程序計時(shí)分析

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

1.臨界段

2.事件設置－喚醒

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

4.互斥鎖

5.自動(dòng)放棄率

6.PSL API調用開(kāi)銷(xiāo)

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

我們來(lái)看一下幾項測試結果：

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

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

中斷計時(shí)分析（ILTIMING）

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

我們來(lái)看一看基于A(yíng)MD K6 500Mhz的CEPC系統的數字。

表3. dwOEMTPoolSize = 16 （CEPC的出廠(chǎng)默認值）

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

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

.NET Compact Framework的實(shí)時(shí)性能

Maarten Struys

Michel Verhagen

PTS軟件

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

專(zhuān)用系統，Windows CE 5.0實(shí)時(shí)x86處理器

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

專(zhuān)用系統，Windows CE 5.0實(shí)時(shí)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采訪(fǎng)Windows CE架構師John Eldridge

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

Windows CE的實(shí)時(shí)決定論（Real-Time Determinism）