WindowsCE開發過程

一、概述

WindowsCE是Mirosoft公司推出的一款嵌入式系統，同時還推出了Platform Builder開發工具和CETK測試載入器，再加上MS其他的開發和管理工具，使得技術開發和專案管理WindowsCE項目變得非常簡便。目前WindowsCE以其良好的人機介面、豐富可靠的應用程式逐漸為廠家所接受，在無線通訊、工業控制、電子消費類產品中，佔有越來越多的市場份額。對於開發人員來講，MS為了開發方便，對於不同的CPU平台，提供了不同的參考模型，並在一定程度上開放了原始碼，使開發人員能夠更多地控制作業系統，並能迅速地做出個人化的產品。特別是MS的開發工具和測試載入器，大大降低了門檻，提高了工作效率，縮短了產品開發週期，減少了產品售後服務所帶來的支出。考慮到WindowsCE的授權費用，在小批量生產的產品中，綜合以上因素，使用WindowsCE的成本，並不得比使用其他動作系統高。

開發WindowsCE產品的最佳教材，就是MSDN。本文只是簡單的描述了WindowsCE的一個基本開發與測試的過程，讓大家對 WindowsCE的開發與測試，有一個大概的瞭解。

二、使用Platform Builder開發BSP

Platform Builder是Microsoft公司出品的，專門為開發WindowsCE嵌入式作業系統的整合式開發環境。在該環境中，開發人員可以使用豐富的工具，建立、裁減、偵錯目標作業系統。WindowsCE的開發過程大概可以分為：OAL、驅動、應用程式開發三個步驟。本文只是對OAL和驅動的開發過程做一個大概的介紹，對應用程式的開發不與討論。

A、 WindowsCE結構介紹

在開發一個作業系統前，必須要對作業系統的階層有所瞭解。下圖是WindowsCE的體繫結構圖。

在硬體之上，就是作業系統了。其中的kernel是MS提供的庫，用於記憶體管理、進程、線程的調度等，是沒有原始碼的。而OEM Layer則是有參考模型和原始碼的，Platform Builder也主要是用來開發OEM層。其中：

Bootloader：主要負責將編譯好的映像檔案放入記憶體中；

OEM Adaptation Layer（OAL）：負責對硬體進行初始化和串連Kernel部分；

Driver：負責對外圍裝置的驅動。

Platform Builder對一些標準硬體開發板提供了BSP（board support package），而這些標準板使用的是業界常用的CPU和外圍裝置。換句話說就是：對常用類型的CPU和外圍裝置，Platform Builder都提供了Bootloader、OAL、Driver的原始碼，只要使用Platform Builder對已有的BSP進行剪裁和稍做修改，再加上MS提供的核心，就能驅動大多數的硬體裝置。而且Platform Builder還提供了豐富的標準應用程式和服務程式，在開發好OEM層之後，再加上這些應用和服務，就能讓使用者的硬體平台工作起來。

當然，如果使用者使用了自己設計的CPU或者外圍硬體裝置，開發過程要複雜的多。但是MS對OAL、驅動、Bootloader的開發步驟和介面，都有嚴格的定義。因此在MSDN的協助下，再對照參考模型，這個過程往往比想象的簡單多。

 

B、BSP的開發

在這裡，假設有一塊開發板，使用MIPSII的CPU，那麼就可以利用Platform Builder提供的MIPSII開發板的BSP原型，迅速的產生自己的BSP。

在Platform Builder中，在菜單Platform中選BSP Wizard，彈出下圖對話方塊。

選中“Clone an existing BSP”，因為AMD DBAu1500的體繫結構是MIPSII的，因此在下拉式清單中選取AMD DBAu1500，然後點“Next”。出現下圖所示對話方塊。

每一個BSP都對應了一個cec檔案。在該檔案中記錄了有關該開發扳的資訊。比如CPU類型，開發板上有哪些外圍裝置，它們在系統使用的名稱、GUID、全域變數等。因此也必須給新的BSP產生的cec檔案起個名字。這裡命名為NewBSP。單擊“Next”。

這時出現Catalog Information對話方塊。在這個對話方塊中填入該BSP的顯示名稱，發行商名，和BSP描述即可。單擊“Next”。

在Directory and CPU對話方塊中，為新產生的BSP選擇路徑和指定CPU類型。單擊“Next”。此時彈出Customization對話方塊，如下圖所示。

在這裡，可以根據自己開發板上的外圍裝置進行，對BSP中的驅動進行調整，比如是否需要Bootloader等。該驅動列表是對應於某塊DBAu1500開發板的外圍裝置的。如果自己的開發板上沒有這些裝置，則可以刪除掉。如果自己的開發板上的裝置型號和類型與列表中的不相符，可以選擇添加（如果有第三方提供的驅動程式），也可以選擇編輯已有驅動的方法。由於現在同一類型的裝置大同小異，因此驅動結構也基本一樣，那麼為什麼不利用已經有的驅動，發揚拿來主義的精神呢。單擊“Next”，初步完成了一個新BSP。

下面的任務就是要對已經產生的BSP進行修改，以讓其更加符合實際開發板的需求。辦法很簡單，在Platform Builder的File菜單中選取“New Platform”，建立一個新的工程。注意在建立的第三步，選擇BSP的時候，要選擇剛剛產生的NewBSP。其他步驟根據提示進行就可以了。

在Platform Builder內，根據開發板的實際情況，參考硬體說明書，對相應的裝置驅動和OAL層進行修改。修改完畢後，編譯並產生映像檔案，就可以下載到硬體平台上進行調試和修改bug的工作了。

三、使用CETK進行測試

在提供了開發工具的同時，MS還提供了一整套測試載入器，對使用者建立的WindowsCE作業系統進行測試，這套工具就是Microsoft® Windows® CE Test Kit (CETK)。該工具將一系列基於命令列測試載入器圖形化，用來檢驗各個驅動程式是否正確。

CETK工具包括兩部分，一部分是在開發平台（PC）上的伺服器應用，一部分是在目標平台上的用戶端應用。因此在使用CETK時，必須首先把用戶端應用程式下載到目標機上。如何下載的辦法很多，比如使用PB中的Remote File Viewer，或者使用FTP服務從用戶端下載，或者使用CETK內建的Connection工具等。本文描述的情境是脫離BSP開發過程，直接面對一個已經開發完畢的目標平台，如何使用CETK進行測試。

A、 測試過程

對於一個已經開發好的目標平台進行CETK測試，首先要瞭解幾點：

該目標平台上啟動並執行Windows CE版本號碼是多少；

該目標平台的CPU結構是什麼；

該目標平台中是否安裝了CETK用戶端；

該目標平台上都有哪些硬體裝置，它們分別支援哪些特性；

因為不同的的Windows CE版本使用不同的CETK版本；另外不同的CPU類型使用不同的用戶端。特別是CETK是一個硬體特性的全集，其中的一些硬體特性也許現有的硬體平台並不具備，因此必須瞭解清楚現有目標平台的特性再進行測試，以免引起不必要的麻煩。在瞭解清楚以上幾點後，就可以進行CETK的測試了。

1、 準備測試環境：

既然CETK有伺服器端和用戶端，那麼它們之間至少應該通過某一種技術手段，使之串連起來。目前對於絕大多數嵌入式裝置來說，都具有至少一個網路裝置。因此這裡假設伺服器端和用戶端是通過區域網路進行串連的。在測試開始前，需要通過伺服器端和用戶端的網路設定程式，將它們設定在同一個網段之內，可以互相訪問。

2、 從開始菜單的Microsoft Windows CE組中啟動Windows CE .NET Test Kit。

3、 下載並運行用戶端軟體：

如果現有的硬體平台中，並沒有包含CETK用戶端軟體clientside.exe，那麼必須通過某種方式下載到硬體平台上。該用戶端軟體在Windows CE 安裝目錄中。在瞭解目標機的CPU類型後，下載/WINCEROOT/OTHERS/WCETK/CPU type/clientside.exe到目標平台上。由於假設伺服器和目標平台都在同一個區域網路內，因此可以通過檔案分享權限設定或者FTP等方式將其拷貝到目標機上。

下載完畢後，開啟目標機的一個控制台（SHELL），進入clientside.exe所在目錄，用命令列上輸入：clientside.exe /n=伺服器IP地址 /p=5555。

4、 設定測試專案：

在用戶端運行了clientside後，過幾秒鐘後，在伺服器的Windows CE .NET Test Kit中將顯示出目標裝置的名字及可檢測單元。如下圖所示。

CETK通過串連到用戶端程式，自動擷取目標裝置上的裝置資訊，並自動確定可以測試的項目。從上圖可以知道，該硬體裝置不包含音效卡、紅外、滑鼠裝置等。可以測試的項目包括顯卡、數據機等。因為硬體裝置種類繁多，因此該硬體掃描在具體細節上不見得準確。比如顯示卡如果不支援Direct3D功能，就不能進行該功能的測試。這也就是為什麼使用者必須事Crowdsourced Security Testing道目標裝置的具體硬體資訊的原因。

每個單獨的裝置都有一些可選的測試項，測試人員可以通過項目前的方框，選中或者取消一些項目的測試。

5、 設定測試命令列

如果要測試一個項目，先用滑鼠選取該項目，然後點右鍵，將彈出一個菜單。在該項測試完畢前，菜單中的“View Results”選項是灰色的。選中“Edit Command Line”，將出現下圖所示對話方塊。

CETK從本質上講，其實就是一套完整的測試案例的集合，而每個測試案例都是一個應用程式。在測試過程中，所要測試的硬體特性，其實是對應於驅動程式中的某些函數調用。因此測試案例就是調用相關的驅動程式中的函數，並通過檢測函數運行結果來判斷驅動程式是否正確的。MS提供了CETK工具的同時，也提供了這樣一套完備的測試案例。如果開發人員使用了自己設計、或者是已有BSP中沒有的裝置，在測試該裝置的時候，就需要測試人員根據裝置的特性及驅動程式，自行編寫測試案例。

下圖顯示的對話方塊是對網卡進行測試的命令列。

其中tux是一個32位的客戶/伺服器程式，負責測試動態連結程式庫中的功能模組。對於不同的動態連結程式庫及其中的模組，當然要使用不同的命令列。因此測試者在進行工作前，必須要Windows CE .NET Test Kit的協助文檔，瞭解不同模組和不同功能所對應的命令列。

6、 開始測試：

如果僅僅對選中的一個項目進行測試，則選中菜單中的“Quick Start”即可。如果要對所有選定的項目進行測試，則要在Windows CE .NET Test Kit的菜單中選Tests->Start/Stop tests。

有些測試不需要人工幹預，程式會自動完成。但是有些測試（比如滑鼠、鍵盤等），在測試過程中包含人機互動的部分。因此測試人員在測試過程中，需要根據目標裝置螢幕上的提示，進行相應的動作。

7、 查看測試報告：

在測試完畢後，菜單中的View Results將自動處於允許狀態，選中得以查看該模組的測試結果。

在CETKParser的顯示地區被分成三個視窗，最上面的視窗顯示了此模組檢測的綜合參數，中間視窗顯示的是用於此模組測試的所有用例和最終結果。當選中其中一個用例時，在最下面的視窗中就會顯示此用例的測試詳細資料。上面論述過，測試案例其實就是調用驅動程式中的某些函數，因此通過分析失敗的測試案例的代碼，就可以初步確定失敗在驅動的哪個函數中。將資訊提供給開發人員後，開發人員再使用PB提供的調試工具，就能迅速定位和解決程式中的問題。

B、壓力測試

使用CETK還可以進行壓力測試。所謂的壓力測試就是讓目標平台工作在極限狀態中的一種測試方法。通過壓力測試，能發現目標平台一些單一測試不能發現的、隱藏很深的問題。在Windows CE .NET Test Kit的菜單中選other Test->Modular Stress Test，就可以進行壓力測試。

壓力測試的項目也是可選的。所進行壓力測試的項目定義在 /Program Files/Windows CE Platform Builder/VERSION/cepb/wcetk/ddtk/armv4/oemstress.ini檔案中。該檔案的格式和內容一目瞭然，通過修改該檔案，就能夠確定進行壓力測試的模組和項目。

進行完壓力測試後，View Results顯示介面與其他結果不同，是一個表格，由於版面和篇幅的關係，這裡不把該圖完全顯示出來，只顯示其中的一部分。在表格中，對開發人員意義比較大的是“System Health”、“Modules Status”兩表，如下圖所示。從“System Health”中可以看到，在壓力測試前記憶體使用量了20%，在測試後，記憶體使用量情況為33%，這說明在壓力測試前後有記憶體的泄露。因此可以進一步判斷，記憶體的泄露在壓力測試中所使用的函數中。

而“Modules Status”中，是對各個模組進行壓力測試的用例統計。