2001年大学部专题.doc
《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視窗軟體整合來實現小型嵌入式手持裝置的網路軟體作業環境。二、 研究問題1、 研究問題概觀:這次專題裡面,我們將Red Hat的一個Open Source 的小型RTOS,Embedded Configurable Operating SystemeCos9與Linux上一個Open Source的視窗系統MicroWindows3整合在一起,也就是將MicroWindows移植到eCos,並且在其上整合網
4、路瀏覽軟體,使這樣的作業環境能達到低記憶體耗用且具有HTML3.2網頁瀏覽功能的目的。2、 目標硬體:我們選擇的架構是目前最廣泛使用於各種高階手持裝置的32位元ARM6架構,而選擇的實驗平台則是Intel StrongARM SA-11104 Development Board與Compaq iPAQ PDA。3、 軟體部分:我們使用的作業系統是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. 研究方法及步驟我們的專題包含設計與製作兩個階段。一、 設計階段:1、 調查現有嵌入式Linux系統上能夠達到我們功能要求的視窗軟體以及應用程式。調查項目包括:I. 各軟體對於底層API(Application Programming Interface)以及Run-time系統的需求以及假設(Assumption)。II. 記憶體需求。其中最重要的是I.項。因為我們的實作部分是移植各項軟體到功能較少的嵌入式
7、系統,所以我們需要補足軟體的API需求與底層系統提供的功能之間的落差以及針對語意(Semantics)上的差異做對應的修改。2、 軟體功能與軟體需求分析:根據各軟體提供的功能以及其需求,我們可以從前項所得資訊得出可行的軟體組合,也可以從中看出大致的實作規劃。重要的軟體組成部分之簡單分析如下:(從底層開始排列)。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, http:/ 視窗系統:我們使用MicroWindows視窗系統。原因是它具有與作業系統相關性小以及低記憶體耗用。另外由於其API接近X Window API,故移植軟體的困難度降低。該系統改寫前需要有下列作業系統以及其他軟體的支援:A. 具Unix Domain Socket支援的Linux核心。B. C Library,使用範圍集中於Single process的部分,牽涉到多個Process間的互動部分主要為Client管理。C. 架構於Linux f
10、rame 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):由於
11、MicroWindows只有支援簡單的視窗管理,及在視窗內的簡單文字,線條與多邊形繪製能力,欠缺高階的視窗元件以及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 http:/ 實作規劃:我們規劃出的實作步驟就是由底層開始逐步修正各項軟體使其能夠在目標平台上運作。主要的修改集中在以下幾個類別:I. 從Process的概念轉移到Thread的概念我們規劃中的平台eCo
13、s是一個以Thread為基本運作單位的作業系統,不具有Process的概念。因此在我們設計中,所有在其上運行的程式實際上都只是個別的Thread。所有的程式均連結在同一個執行檔內,共享同一份資料節區。Thread之間不具有任何保護。這樣的運作方式最大的衝擊在於我們的視窗系統以及視窗元件等同時提供API與資源予多個Client Thread叫用的軟體。此時視窗系統以及視窗元件需要大量修改以做到:A. 視窗系統與視窗元件能識別與獨立儲存個別Client Thread的相關狀態而不致互相干擾。B. 視窗系統與視窗元件提供的API必須具有可重入性(reentrancy)。也就是對於同一個函式(func
14、tion)而言,能同時存在多個叫用的instance獨立進行,彼此間不相干擾。在這裡我們指的是一個Thread正在叫用某函式的當中被排程器切換到另一個Thread時,後來的Thread亦可叫用前者正在叫用的函式而不會彼此影響運行。細節請參見二.實作階段之中的丙.移植MicroWindows視窗系統問題B的解決方法。II. 補足平台間缺漏的API此部份較為單純,問題集中在補足eCos系統不足的API。一般都可從網路上現成的函式庫中找到原始碼加以修改後套用。對於更簡單的Routine也可以直接重寫一份。二、 實作階段:1、 目標硬體的選擇:我們採用目前廣泛使用於高階嵌入式系統以及PDA,最具代表性
15、的StrongARM SA-1110處理器為基礎的硬體系統。專題前期我們著重軟體與韌體可修改性,因此使用使用較為方便開發底層部分的Intel StrongARM SA-1110 Development Board;專題開發後期我們改以使用者介面硬體相對完備,較易設計介面的Compaq iPAQ作為我們的硬體平台。2、 開發環境的設立與熟悉:由於嵌入式系統的性質使然,我們必須要在一般的PC上面進行cross-compiling編譯在目標硬體(Target)上執行的軟體,並且使用遠端除錯(Remote debugging)的方式,使PC上的除錯器與目標硬體上待除錯的軟體合作進行除錯。由於此類開發模
16、式與一般應用程式開發不甚相同,因此我們投入相當時間建立整個Cross compiling環境以及熟悉相關系統程式的操作運用。3、 移植MicroWindows視窗系統:I. 簡述與規劃:MicroWindows視窗系統是我們第一個進行移植的軟體。其為Client-Server架構。Server的主要架構分成三層:2D Graphics Primitive Drawing EngineNano-X Windowing APIClient Connection ManagementScreen (Frame buffer) Pointing DeviceKeyboard視窗系統繪圖引擎驅動程式其中
17、與底層作業系統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與目標硬體上,我們至少需要修改Server端兩個部分
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 2001 大学部 专题
链接地址:https://www.31doc.com/p-2500126.html