《2001年大学部专题.doc》由会员分享，可在线阅读，更多相关《2001年大学部专题.doc（14页珍藏版）》请在三一办公上搜索。
1、2001年大學部專題個人數位助理視窗作業環境設計與實作指導老師：鍾崇斌學生：宋宜叡 李孟道 洪于玉個人數位助理視窗作業環境設計與實作李孟道 洪于玉 宋宜叡指導老師: 鍾崇斌1. 研究目的移植與改寫現有嵌入式Linux系統上視窗系統及應用軟體，設計並實作出具有下列能力及特性之個人數位助理(PDA)作業環境(作業環境在此是指作業系統及視窗介面之統稱)：一、 具有基本HTML3.2之Web瀏覽能力。二、 以一小型嵌入式作業系統eCos為基礎，達到低於類似組態嵌入式Linux系統的記憶體資源耗用。2. 研究動機與研究問題一、 研究背景及動機現今由於消費性電子的大幅發展，以及Internet Appli
2、ance的日漸普及，資訊工業已經走向後PC時代。因應嵌入式硬體平台的多樣化以及功能多樣化，嵌入式系統軟體亦是百家爭鳴。現今常見的商業性Embedded OS有Windows CE以及PalmOS等，而免費的作業系統如Linux，FreeBSD等等也有許多人力投入小型化，嵌入化的產品研製，如CLinux1。然而此類免費系統源自多人多工的UNIX，其系統架構若要Down-size至Embedded System的規模，有許多不必要的系統功能如虛擬記憶體等皆會佔用嵌入式系統中有限的系統資源，而且以Linux這種monolithic kernel而言，要從中抽出多餘的子系統需要全面的修改。因此我們嘗試
3、從另一個角度出發，取材目前Open Source Community中的資源，以比嵌入式Linux更小型的嵌入式作業系統(而非Linux)與數個源自於Linux作業系統的Open Source視窗軟體整合來實現小型嵌入式手持裝置的網路軟體作業環境。二、 研究問題甲、 研究問題概觀：這次專題裡面，我們將Red Hat的一個Open Source 的小型RTOS，Embedded Configurable Operating SystemeCos9與Linux上一個Open Source的視窗系統MicroWindows3整合在一起，也就是將MicroWindows移植到eCos，並且在其上整合網
4、路瀏覽軟體，使這樣的作業環境能達到低記憶體耗用且具有HTML3.2網頁瀏覽功能的目的。乙、 目標硬體：我們選擇的架構是目前最廣泛使用於各種高階手持裝置的32位元ARM6架構，而選擇的實驗平台則是Intel StrongARM SA-11104 Development Board與Compaq iPAQ PDA。丙、 軟體部分：我們使用的作業系統是Red Hat eCos。由於eCos是一個針對嵌入式系統的要求與先天限制而發展的RTOS，自然在功能上相較一般桌上型系統或者是UNIX而言必須有所犧牲，甚至其並不支援一般多工作業系統的Process概念。因此對我們而言，一個重要的課題就是如何改寫軟體
5、使其能在功能與資源需求較少的作業系統上運行。由於視窗系統一般都與作業系統有相當程度的依賴關係，所以經過我們評估後選擇對底層作業系統依賴性相當小的MicroWindows來當作使用者介面的基礎。由於MicroWindows這套視窗系統的API(Application Programming Interface)接近但並不同於一般的X Window API，因此除了移植此視窗系統本身的問題之外，另一個需要我們在研究中解決的問題就是需要改寫能搭配此視窗系統上的API運作的視窗元件(Widget)與應用程式。網路瀏覽器的方面我們改寫一套原本建構在MicroWindows與Linux之上的HTML瀏覽器
6、:ViewML2，使其能夠在我們的MicroWindows加eCos的平台上執行。在網路連線的部分，eCos提供了一些必要的支援，譬如說TCP/IP Protocol Stack等等。3. 研究方法及步驟我們的專題包含設計與製作兩個階段。一、 設計階段：甲、 調查現有嵌入式Linux系統上能夠達到我們功能要求的視窗軟體以及應用程式。調查項目包括：I. 各軟體對於底層API(Application Programming Interface)以及Run-time系統的需求以及假設(Assumption)。II. 記憶體需求。其中最重要的是I.項。因為我們的實作部分是移植各項軟體到功能較少的嵌入式
7、系統，所以我們需要補足軟體的API需求與底層系統提供的功能之間的落差以及針對語意(Semantics)上的差異做對應的修改。乙、 軟體功能與軟體需求分析：根據各軟體提供的功能以及其需求，我們可以從前項所得資訊得出可行的軟體組合，也可以從中看出大致的實作規劃。重要的軟體組成部分之簡單分析如下：(從底層開始排列)。I. 作業系統：使用Red Hat eCos作業系統。這是我們的基本作業平台。特性是其API能夠設定成Linux系統呼叫的子集合方便我們移植軟體，並且具有TCP/IP協定之網路能力以及小於Linux Kernel的記憶體需求。在我們的設定中，其提供以下能力：A. 使用HAL (Hardw
8、are Abstraction Layer)用來支援數種不同的架構，包括一個以Linux下的User Mode Process當作硬體架構的HAL(後稱Linux模擬HAL)。因此可以設定成以Linux下的一個User Mode Process的方式執行，用以協助與實際硬體較無關聯的程式之除錯。B. 以Pthread為基礎之多緒執行(Multi-threading)。C. Linux單一Process系統呼叫與函式庫常式(Library routines)的子集合。即EL/IX規格11中的第一層支援。D. 基本的驅動程式架構，使用方法類似UNIX的驅動程式。E. 以OpenBSD TCP/IP
9、實作為基礎的網路協定堆疊。F. 系統架構Block Diagram如下:Adapted from The eCos Datasheet, II. 視窗系統：我們使用MicroWindows視窗系統。原因是它具有與作業系統相關性小以及低記憶體耗用。另外由於其API接近X Window API，故移植軟體的困難度降低。該系統改寫前需要有下列作業系統以及其他軟體的支援：A. 具Unix Domain Socket支援的Linux核心。B. C Library，使用範圍集中於Single process的部分，牽涉到多個Process間的互動部分主要為Client管理。C. 架構於Linux fram
10、e buffer device之上的顯示能力。D. 架構於Linux之上的基本檔案I/O。E. libjpeg，解碼JPEG格式圖片的程式庫。MicroWindows提供予上層軟體使用的功能如下A. 支援多個Client的Client-server軟體架構，類似X Wndow。Clientss為基礎的多重視窗client-server機制。B. 支援JPEG，GIF，BMP等圖檔解碼顯示能力。C. 一個獨立的視窗管理員，可讓使用者進行Client視窗在螢幕上的搬移以及關閉功能。D. 簡單繪圖功能。不支援較高階的元件(Widget)如按鈕，對話盒等。III. 視窗元件(Widget)：由於Mic
11、roWindows只有支援簡單的視窗管理，及在視窗內的簡單文字，線條與多邊形繪製能力，欠缺高階的視窗元件以及Application Framework的API。而且ViewML瀏覽器需要架構在較高階的視窗元件FLTK上，因此我們需要移植FLTK視窗元件。FLTK視窗元件改寫前有下列作業系統機能的假設以及對底層軟體API需求：A. 以Process為運作單位的作業系統，不支援Multi-thread。B. MicroWindows API。C. 基本C+ Runtime，不包含C+ Standard Library。提供的功能：A. 高階視窗元件，如按鈕，對話盒等等。B. 統一管理與分派所有視窗
12、事件的Application Framework。IV. WWW網路瀏覽器：我們使用可以搭配FLTK與MicroWindows的網路瀏覽器ViewML。其需求如下：A. FLTK視窗元件。B. C+ Standard Library內的Template。C. W3C libwww，用來處理HTTP協定相關網路傳輸。D. 系統架構之Block diagram如下 Adapted from 而其提供的功能就是一個具體而微的HTML3.2能力之網路瀏覽器。丙、 實作規劃：我們規劃出的實作步驟就是由底層開始逐步修正各項軟體使其能夠在目標平台上運作。主要的修改集中在以下幾個類別：I. 從Process的
13、概念轉移到Thread的概念我們規劃中的平台eCos是一個以Thread為基本運作單位的作業系統，不具有Process的概念。因此在我們設計中，所有在其上運行的程式實際上都只是個別的Thread。所有的程式均連結在同一個執行檔內，共享同一份資料節區。Thread之間不具有任何保護。這樣的運作方式最大的衝擊在於我們的視窗系統以及視窗元件等同時提供API與資源予多個Client Thread叫用的軟體。此時視窗系統以及視窗元件需要大量修改以做到：A. 視窗系統與視窗元件能識別與獨立儲存個別Client Thread的相關狀態而不致互相干擾。B. 視窗系統與視窗元件提供的API必須具有可重入性(re
14、entrancy)。也就是對於同一個函式(function)而言，能同時存在多個叫用的instance獨立進行，彼此間不相干擾。在這裡我們指的是一個Thread正在叫用某函式的當中被排程器切換到另一個Thread時，後來的Thread亦可叫用前者正在叫用的函式而不會彼此影響運行。細節請參見二.實作階段之中的丙.移植MicroWindows視窗系統問題B的解決方法。II. 補足平台間缺漏的API此部份較為單純，問題集中在補足eCos系統不足的API。一般都可從網路上現成的函式庫中找到原始碼加以修改後套用。對於更簡單的Routine也可以直接重寫一份。二、 實作階段：甲、 目標硬體的選擇：我們採用
15、目前廣泛使用於高階嵌入式系統以及PDA，最具代表性的StrongARM SA-1110處理器為基礎的硬體系統。專題前期我們著重軟體與韌體可修改性，因此使用使用較為方便開發底層部分的Intel StrongARM SA-1110 Development Board；專題開發後期我們改以使用者介面硬體相對完備，較易設計介面的Compaq iPAQ作為我們的硬體平台。乙、 開發環境的設立與熟悉：由於嵌入式系統的性質使然，我們必須要在一般的PC上面進行cross-compiling編譯在目標硬體(Target)上執行的軟體，並且使用遠端除錯(Remote debugging)的方式，使PC上的除錯器與
16、目標硬體上待除錯的軟體合作進行除錯。由於此類開發模式與一般應用程式開發不甚相同，因此我們投入相當時間建立整個Cross compiling環境以及熟悉相關系統程式的操作運用。丙、 移植MicroWindows視窗系統：I. 簡述與規劃：MicroWindows視窗系統是我們第一個進行移植的軟體。其為Client-Server架構。Server的主要架構分成三層：2D Graphics Primitive Drawing EngineNano-X Windowing APIClient Connection ManagementScreen (Frame buffer) Pointing Dev
17、iceKeyboard視窗系統繪圖引擎驅動程式其中與底層作業系統API較為相關的部分是視窗系統層的Cilent connection management部分。原本的Client connection management端使用Unix Domain Socket與Client端通訊。然而在eCos上並沒有可用的Unix Domain Socket支援，因此我們修改成使用POSIX Message Queue來進行對Client通訊。而Client端的部分為一個函式庫用以將呼叫轉為訊息送至Server端，並依情況等待來自Server端的回覆。II. 移植中遇到的困難：A. 為了移植到eCos與
18、目標硬體上，我們至少需要修改Server端兩個部分：Client connection management與驅動程式層。然而同時進行兩個部分的修改可能會造成除錯的困難B. 原本Client端的函式庫僅供單一Process叫用，因此其設計為將該單一Client資訊全部紀錄在該函式庫內的全域變數(Global Variable)中。這樣的設計在以Process為基礎的系統中能夠運作，然而在我們的環境中，所有的Client均會與同一份程式庫連結在一起，導致所有Client狀態的全域變數會產生混淆的情況。III. 解決方法：A. 針對前述問題A，我們先以GTK (Gimp Tool Kit)撰寫一個
19、簡單模擬器，在Linux上的X Window中虛擬出的一個理想螢幕與觸控面板(Touch Panel)，配合eCos的Linux模擬HAL，讓我們可以在Linux上先以假想硬體修改測試頂層的設計。確認可動作之後我們再實際撰寫真實硬體的驅動程式。B. 為了解決前述問題B，我們發現可以利用Pthread標準定義的一套用以紀錄每個Thread私有資料的機制(Pthread標準中稱之為Thread-Specific Data)。將該函式庫中所有記錄Client資訊的變數全部移到Thread-Specific Data中，再將每個需要用到此類變數的函式改寫成使用Thread-Specific Data來
20、記錄。IV. 實際硬體的驅動：完成模擬器上的移植後，我們需要做的就是改寫出適合實際硬體(即LCD螢幕與觸控面板的部分)。在這邊我們參考Linux系統上的驅動程式進行改寫。並且由於eCos無記憶體保護的設計，我們的程式能直接在ARM的Kernel mode中執行，省去Mode switching的部分，因此撰寫驅動程式相當直覺。V. JPEG解碼程式庫的移植：為了達成JPEG圖片顯示能力，MicroWindows需要配合一個JPEG解碼的函式庫libjpeg(www.ijg.org)。不過由於其主要為數學運算，移植此函式庫並沒有遇到任何特別的困難，主要是修改成支援Cross Compiling使
21、用的選項以及其他參數調整。丁、 移植FLTK視窗元件：I. 簡述FLTK是一套C+的視窗元件函式庫，目前已經支援MicroWindows 的API。也是ViewML瀏覽器必需的視窗元件函式庫。II. 移植中遭遇的困難FLTK是一個以Process為基本運作單位的函式庫，因此也遇到如同MicroWindows Client端函式庫的問題(見前述MicroWindows的移植困難B項)。然而更加麻煩的地方是FLTK裡面還有C+ Class的Static Member，所以修改時更不容易找到所有需要修改的數百個全域變數(FLTK有一百多個程式檔案，數十種Widget，並且大量使用全域變數記錄Clie
22、nt State)。III. 解決方法我們發現利用objdump程式，能直接從產生的object file中觀察該object file中定義的資料區段(data section)全域符號。如此便能快速產生需要修改的所有全域變數。戊、 移植ViewML瀏覽器：I. 簡述與規劃：ViewML瀏覽器大約可以分成兩個主要的部分：HTML解譯與顯示(layout)核心(後簡稱HTML引擎)與處理HTTP協定的部分。我們以先HTML引擎後HTTP協定的順序來進行移植，這樣每完成一個主要部分便可直接進行測試。II. 移植的困難：A. HTML引擎部分需要C+ Standard Library內的Templ
23、ate，此部份目前在我們使用的平台(eCos)上並無支援。B. HTTP協定部分使用W3C libwww，此函式庫非常巨大，不僅有HTTP協定，亦包含FTP，TELNET等協定，甚至有HTML與XML的Parser在內。整個函式庫中所有協定使用相同的底層架構，設計的十分複雜，也不容易單獨抽取出需要的部分。然而我們只需要使用HTTP傳輸協定，這樣的函式庫對我們來說顯然超出需求太多。III. 解決方法：A. 主HTML解譯與顯示核心移植：檢視過ViewML瀏覽器之 HTML引擎後，我們整理出所有程式碼使用C+標準Template的地方，發現程式中使用的地方相當集中，而且使用的Template集中在
24、List，Queue，Stack等等基本的資料結構。因此我們將所有使用到的Template及所需功能自行實作一份供ViewML使用。B. HTTP傳輸協定函式庫之移植：經過檢視libwww之後，我們認為其功能超出需求太多。實際上目前我們只需要使用HTTP GET與HTTP POST的功能。因此我們轉而尋找網路上類似功能，但規模較小的函式庫。經過尋找後我們發現一個HTTP函式庫名為libcurl (http:/curl.haxx.se/libcurl/) 符合我們的需求。因此我們先將此函式庫移植到eCos環境中，再修改ViewML瀏覽器的HTTP協定程式碼使其改用此函式庫。己、 以小程式驗證視窗
25、系統以及FLTK視窗元件的修改：完成以上的實作之後，我們撰寫了一些程式進行視窗系統以及FLTK視窗元件的驗證。所有的程式都建構在我們之前移植的FLTK視窗元件函式庫之上，因此這些程式便能直接驗證FLTK與間接驗證MicroWindows是否成功的被修改成以Thread為運作基礎。另外，這些程式的運作與否更間接驗證全套系統整合是否成功。最後，這些程式亦具有基本實用功能以及展示作用。表列如下：I. 觸控螢幕校正程式。II. 螢幕小鍵盤。III. 小計算機。IV. 基本程式選單(Start-up menu)。庚、 測量Embedded Linux與eCos的記憶體耗用我們實際測量ARM Linux在
26、iPAQ PDA上執行MicroWindows，視窗管理員，ViewML瀏覽器之後的記憶體耗用狀況如下：l Linux Kernel：1.6Mbytesl 其餘軟體(C函式庫靜態連結)：4Mbytesl ROM耗用接近16MBytes。而相同功能的軟體經過我們的移植與改寫(例如：更換ViewML的HTTP函式庫)後，在eCos上的RAM耗用狀況總量約為2Mbytes，ROM耗用量約為1.6Mbytes。4. 具體成果至目前為止，我們已經大致完成一開始設定的目標：一、 一套適合手持式裝置的小型開放式原始碼視窗作業環境。二、 具有網路瀏覽器，能夠瀏覽網路上的基本HTML3.2網頁。三、 在真正的手
27、持式裝置(Compaq iPAQ)上執行。在軟體的實際產出以外，我們獲得在嵌入式系統硬體上撰寫程式以及除錯的寶貴經驗，在開發過程中，我們亦回報多個Bug以及修正程式(Patch)予原本的軟體開發團隊，真正做到開放式原始碼軟體系統的實際參與。我們做到：一、 RAM耗用量約2Mbytes左右，ROM耗用量約1.6MBytes左右的網路功能手持式作業環境：RTOS+視窗系統+HTML瀏覽器。遠遠小於目前市面上嵌入式Linux系統執行類似軟體的記憶體耗用。二、 多個程式共用的Client-Server式視窗系統，並且有高階的Application Framework以及視窗元件。三、 在Linux的X
28、 Window上配有模擬器，方便應用程式測試與開發。四、 系統軟體部分基植於硬體抽象層之上，具有容易移植至其他32位元嵌入式平台的能力。五、 開放式原始碼軟體。本研究中使用的開放原始碼軟體裡，規範中(Licensing)最嚴苛的為Microwindows與ViewML使用的GPL(GNU Public License)。其他如eCos則是使用修改過的Netscape License(即Red Hat eCos Public License; RHEPL)。但是均保證原始碼的免費取得與使用。因此本研究產出物為Open Source Software是無庸置疑的。六、 HTML 瀏覽器能夠瀏覽HT
29、ML 3.2格式文件(但不包含Java與JavaScript能力)。5. 心得與討論一個純粹以Thread為基礎的作業系統，卻用以執行原本設計以Process為基礎的應用程式，這類設計與現有電腦軟體系統以及相關工具原先的假設十分不同。因此如何克服工具上的先天缺乏，以及如何快速的移植改寫現有軟體到這樣的系統，便構成這個專題的主要困難與挑戰。除此之外嵌入式軟體開發與除錯本身就十分不容易，尤其是當我們並不使用外加的硬體(ICE, In-Circuit Emulator)協助除錯，而純粹使用模擬器與遠端除錯(Remote Debugging)來進行開發的時候。我們以嵌入式Linux的軟體改寫應用在更低
30、階的RTOS上以達到低資源耗用的做法在設計上相較目前市面上以嵌入式Linux系統作為手持式作業環境的設計佔用的資源少了許多，然而功能上卻相差不多。因此，我們認為此專題已經具有相當商業價值。除此之外，從這個專題的經驗中，我們學習到開發嵌入式系統軟體的方法學(Methodology)，如利用或撰寫模擬器或者是遠端除錯器協助測試與除錯。以及Multi-Thread軟體先天的限制以及克服方法。並且也由此了解一個具體而微的完整視窗系統與作業系統及應用程式互動的機制。6. 未來展望我們的設計嘗試將嵌入式Linux上相對大型的軟體移植到功能更簡單的嵌入式系統之上改以Thread的方式運作。這樣的運作模式雖然
31、理論上能較節省系統資源，然而由於目前我們使用的開發工具(如編譯器與除錯器等)並不直接支援這樣的運作方式，因此會產生前面所敘述的全域變數問題。所以在這裡我們付出的代價就是以人工修改來達成較低的資源要求。未來如果能夠從系統軟體的角度出發，讓編譯器以及除錯器能夠自動產生以及支援此類的程式運作模式，那麼此類工作便能相對自動化的完成。這樣以Thread為基礎的運作模式最大的弱點就是不容易從外部載入新程式執行，因此未來的發展方向將是以動態連結(Dynamic Linking)來載入外部模組的能力。7. 參考文獻1 Dionne,D.J.,and Durrant,M.“uCLinux: Embedded L
32、inux/Microcontroller Project”. http:/www.uclinux.org2 Haerr, G. “The ViewML Project”. .3 Haerr, G. “The MicroWindows Project”. http:/www.microwindows.org.4 Intel Corporation. 1999. “Intel StrongARM SA-1110 Microprocessor: Advanced Developers Manual”.5 IEEE. 1996. “Information TechnologPortable Opera
33、ting System Interface (POSIX) Part 1: System Application Program Interface (API) C Language,” IEEE Std 1003.1, 1996 Edition, Institute of Electrical and Electronics Engineers.6 Jaggar, D. 1996. ”ARM Architecture Reference Manual”, Addison-Wesley.7 Lippman, S.B and Larjoie, J. 1998. “C+ Primer, Third
34、 Edition”, Addison Wesley.8 Lu, H.J. 1995. “ELF: From The Programmers Perspective”, ftp:/tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz9 Red Hat Inc. “Embedded Configurable Operating System Project”, 10 Stevens, W.R. 1998. “UNIX Network Programming Volume 2: Interprocess Communications, Second Edition.”, Perntice Hall.11 Tiemann. M. 1999. “EL/IX: Unifying APIs for Linux and Post-PC Computing”,
