摘要：
嵌入式系統的發展需要軟硬體之間的配合，能而夠快速執?各種應用程式的嵌入式平台，是值得研究的重點之一。本?文提出整合Real-Time OS與Java Processor的即時嵌入系統架構，並藉由把OS轉成chip，加快執?的速?，進而提高效?。在此嵌入式平台架構上，只要加上application 即可為Time to Market的嵌入式系統。
關鍵詞：Java Processor，MicroC/OS-II，embedded system platform
1、前言
由於嵌入式系統的發展，人們的生活習慣大幅改變。隨著時代的變遷與科技的進步，?斷地以?同的外貌展示在我們的眼前，小至家庭資訊設備，像是手機、時鐘、微波?，大的像是汽?、飛機、火星探測器，到處?存在他的蹤跡。隨著二十一世紀的到?，各式各樣創新思維的加入，?讓嵌入系統披上一件美?的外衣，已經?是過去一般傳統的嵌入式技術所能夠掌握的市場，也?該是桌上型電腦能勝任的任務，而應該是由?宏觀的想法?詮釋這個嶄新的世界[1]。
基於Java [2]簡單、跨平台、物件導向、安全性等特性，?於軟體技術的開發，?是應用於嵌入式系統，可縮短開發時程及大幅地簡化系統發展的複雜?。廣泛應用Java 技術，將是嵌入式系統發展可預?的趨勢，為?整合Java執?環境和硬體設備，達到最佳的執?效能，將原本已存在各種規格的微處?器以Java Processor取代，能夠?直接地執?Java Application。
原始的Java Processor[4]只能程序性的執?程式，無法提供multi processes和time management的功能，在應用上受到許多的局限，尤其是?少以即時性為主的嵌入式系統，為?延伸?多元的功能，應搭配OS以彌補這方面的?足，以?發展?貼近使用者需求的系統。系統的執?效?，往往是開發者考?的重要原因之一，而相較於硬體，軟體執?的速?相對的比較緩慢。最?想的作法，是將所有的軟體轉成硬體電?以提升執?的效?，但卻會因此喪失擴充性等優點。因此，折衷地將其中較常使用的部份轉換成硬體，?如OS，?但可以大幅的提升執?效能，還能保?原本的優勢。
本?文提出Java-based 即時嵌入式系統其特點如下：
(1) Java Processor增加執?Java bytecode的速?。
(2) 新增OS?處?processes之間的調?與溝通,達到multiprocesses的功能。
(3) 將原本軟體執?的OS轉換成硬體電?，達到提高效能與節?電能。
本?文結構如下，第一章提出設計嵌入式系統平台架構的動機；第二章簡介?文中?用到的各種技術；第三章比較舊有格式與新格式的優缺點；第四章對系統進?分析並且敘述?模擬的方法；第五章則描述?實作的方法以及與改?並增?其效能；第?章總結整篇?文，並提出未?發展方向。
2、技術背景
2.1 MicroC/OS-II
MicroC/OS-II是一個?史悠久的作業系統微核心，1992?由Jean J. Labrosse首次發表的版本稱為μC/OS，之後?續?新功能，成為目前的版本。這個作業系統發表到現在，一直以出書的方式推廣，作者以開放的胸襟，將所有原始碼寫在書（MicroC/OS-II The Real-Time Kernel）[3]?面，一一介紹每一部份的工作原?和設計??。
MicroC/OS-II是針對嵌入式系統所設計的，特別強調其可攜帶性，換?話?，他的硬體相關程式碼部分，?得非常清楚簡潔。以MicroC/OS-II 2.0、ARM 7版本為?，只有少少的14個檔案，其中9個c語言檔、4個.h檔、加上一個組合語言檔案；原始碼?詳盡的註解加起??到200K Bytes，而實際與CPU相關的程式碼，只有三個檔案，其中的組合語言檔，為處?多工?換所需的工作細節和中斷底層相關工作等；而.c檔則處?目標平台的初始化工作，及中斷和多工任務建?介面等。
MicroC/OS-II 特性：
(1)Multi-processes：MicroC/OS II可以同時管?64個processes，每個process擁有自己的優先權。
(2)Preemptive：MicroC/OS II大多執??態為Ready最高優先權的process，當較高優先權的process甦醒，正在執?當中較低優先權的process會被interrupt中斷，讓系統?換至執?
1
較高優先權的process。
(3)Process Stacks：每個 process ?有他們自己專屬的 stack ?儲存本身資訊。
(4)Service：Semaphore、Mail box、Queue 、Time management。
2.1.1 Ready-List
Ready-list是OS中相當重要的資?結構之一，用?管?所有ready?態的task，以?找出最高優先權的task，如圖一。
圖一. Ready-list
Ready-list包含?個部分，8*8 bits的ready table及8 bits的readyGroup。Ready table中的每一個bit?表示一個優先權(0~63)，因為MicroC/OS-II中每一個task中?擁有一個唯一的優先權，所以當其中某一個bit被設為1時，即表示該優先權的task為ready?態；readyGroup中的每一個bit用?表示一組(8個) task，當其中任一個task被設為1時，readyGroup中相對應的bit也會被設為1，藉此增加尋找最高優先權task的速?，?必從ready table中一個一個bit搜尋，直接從readyGroup中最高權重的bit找起即可。
2.1.2 Event-Table
為?使用semaphore、mail box、queue等event所定義的資?結構，主要的功用是用?管?所有在等待event的task，如圖二。
圖二. Event-table
Event-table的實作方式和ready-list相同，而event-table中的table及eventGroup相對於ready-list中的ready table和readyGroup，功能也相同。當task在等待event時，event-table和eventGroup中相對應的bit會被設為1，即wait的?態；?是有task將resource還回系統，則?用event table從所有wait?態的task中找出優先權最高的，設為ready?態並將event table中的bit重設為0。
2.1.3 OS中scheduler的處??程
首先scheduler會在ready-list中找出最高優先權的process，並且以優先權為?引值，檢查最高優先權的process與現在正在執?的process是否為同一個。?是，則?做任何處?，繼續執?原本的process。但??者?同，則執?Context Switch的動作。
Context Switch是指在?同process之間做轉換的動作。本系統中的做法為將現在處?器中紀?的資訊(如：PC, register等)儲存到各個process所屬的資?結構中。再將現在找出的最高優先權的process的處?器資訊設定給Processor。如圖三
圖三. Context switch
2.2 Java Processor
Java Processor顧名思義就是支援Java 指?集的處?器，?需要經過額外的處?，就能夠直接的執?Java bytecode。大部分的Java Processor?是根據Java Virtual Machine的概?發展而成。Java Virtual Machine[5]主要可分為class loader、runtime data areas、execution engine三個部分，如圖四。
圖四. JVM架構圖
2
Java Processor 主要由runtime data areas、execution engine?部分所組成。以下根據各部分做?詳細的介紹：
? Execution engine：處?器的核心，用?執?存在於memory中的bytecode指?。
? Runtime data areas：
? Method area：method area包含?許多關於method的資訊，其中包括?區域變?的個?、method中stack的大小、建構子等等。
? Heap：由garbage collection所管?的儲存區域，用?儲存經由class建構而成的物件(instances)資?。
? PC register：在JVM中每個執?序?擁有個別的PC register，用?紀?目前執?序中的method執?到哪個指?。PC register的大小通常和特定平台的指標大小相同。
? Java stack：Java stack的作用?似於傳統語言的stack，當method呼叫或回傳時，用?存放區域變?及回傳結果。而在Java中，當method呼叫時，method會建構一個method frame用?存放run time的資訊，放入Java stack之中。
? Native method stack：native stack就是C stack，用?儲存native method所需的資訊。Native method是指由非Java語言所編寫且經過編譯的method。當JVM執?這?method時，也需要準備一個stack用?儲存相關的資訊，及native method stack。
2.3 SoCAD tool
SoCAD tool[6]為非同步系統及爪哇技術實驗室所開發的電腦輔助設計軟體(CAD tool)，其主要功能在於進?軟硬體共同設計(Hardware/Software co-design)與系統晶片設計(System-On-a-Chip design)。SoCAD Tool 首先將Java 程式語言轉成相對應的資?關係圖(Data Dependency Graph)，資?關係圖是軟硬體之間轉換的重要的資?結構。?如在Java to DDG translation中，我們分析完爪哇程式碼之後(?圖五)，會產生對應的資?關係關圖(?圖?)，而資?關係關圖會透過DDG to HCG translation(?圖七) 以及HCG to VHDL translation 轉換成VHDL 程式碼(?圖八)。由於SoCAD tool 使用的是非同步電?，因此可以保證我們經由SoCAD tool 得到的電?較一般的同步電??電、可靠，且能達到average-case performance。
圖五. Java程式範?
圖?. 資?關係圖
圖七. HCG範?
圖八. VHDL程式碼範?
3
3、系統架構
本?文整合Java Processor和OS，藉此延伸?多元的功能。整個系統的架構以OS及Java Processor為主要的物件，可分為軟硬體?種情況?討?。
3.1 OS為軟體的?況
圖九中表現?OS為軟體的情況下，OS和其他由使用者所編寫的task經過compiler後，以bytecode的型式存在於memory中。Java Processor透過PC從memory中抓取bytecode指?並執?，如果 task中有使用到OS的功能，task直接使用method call的方式呼叫OS中相對應的method。?是OS在執?的過程中需要context switch，OS會重設Java Processor的?態，?如，PC值及stacks內容等等。
圖九. 軟體架構圖
3.2 轉換OS為硬體
在OS為硬體的情況下，memory中僅存放tasks，而OS以硬體電?的形式和Java Processor溝通，如圖十。和軟體的情況一樣，CPU從memory抓取bytecode指??執?，如果遇到OS所提供的功能，會透過extended instruction以及一些所需的??，交給OS執?，並且等待回傳執?結果。為?讓Java Processor?方?和OS做溝通，我們提供一個標準化的使用介面，?需要在意OS的實作方式，只要透過介面所提供的方式使用OS功能，即使?換其他的處?器，依然?需要?動OS的實作內容。
圖十. 硬體架構圖
4、模擬與分析
4.1 OS分析
本?文實作由Micriμm所釋放出?的MicroC/OS-II The Real-Time Kernel原始碼，首先必須熟悉與?解MicroC/OS-II，?用書上提供的範?程式，實際的模擬OS整個作業?程。爲?提高執?的效?，希望能找出OS中使用頻繁的功能或者是使用時間較為長者，把這些部份?用實驗室所研發的SoCAD Tool，轉換成硬體語言，再加以轉換成硬體，但由於MicroC/OS-II已經是一個相當?簡的OS Kernel，?面包含的?是最基本OS所提供的功能，所以將整個OS 轉換為chip是可?的。
4.2 程式碼撰寫
爲?縮短開發?程，我們?用實驗室所研發的SoCAD Tool，SoCAD Tool可以把Java程式轉換成VHDL程式語言，所以我們必須把用C語言撰寫的原始碼以Java語言改寫，首先因為C語言是程序性語言而Java是物件導向語言，所以必須藉由OOAD[7]（Object-Oriented Analysis and Design）的方式重新規劃OS的架構，以物件的角?去分析和解決問題，讓OS?加容?增修與維護，接下??用分析出?的架構，重新改寫OS的原始碼。
4.3軟體模擬
圖十一. 軟體模擬?程圖
如圖十一，在這個工作階段，我們將軟體模擬分成下面?大部分：
（1）Generate code for Java Processor
根據OS提供的功能，用 Java 編寫測試的application ，再透過 compiler 轉換成bytecode (class file)，接下? Translator 會將 class file 中的內容整?並 load 到Java Processor。
（2）Execute instruction
當Java Processor 在處?bytecode時遇到 OS 所提供的功能，?會透過 Interface 去呼叫 OS 內部的 method，而Interface 會依照?同的訊號而呼叫?同的 method。當呼叫的functoin有傳回值時，也會透過Interface放到top of stack。
4
4.4 VHDL程式驗證
在程式碼轉換成硬體語言後，必須在Altera Quartus軟體上模擬硬體實際的?況，確保轉出?的VHDL是正確的。
5、系統實作
5.1 物件導向分析與設計
本?文使用OOAD的方法將原本以C語言撰寫而成的MicroC/OS-II以物件導向(Object-Oriented)的概?重新設計其內部架構。使用 UML可以清楚的定義出每個 class 之間的關?性、相依性、程式執??程等資訊。使OS的架構與運作?加清楚?懂。
5.1.1Use Case Diagram
首先定義出Use Case Diagram，用?表示系統提供哪些功能讓外部元件使用。此處的系統所指的是μC/OS-II，而Actor則是跟OS做互動的元件。如圖十二。表一與表二中?出主要?個use case description。MicroC/OS-IITaskmanage tasksSuspendResumeWake upSleepChange priorityPostPendAcceptuse task communicationservices<><><><><><><><>
圖十二. Use Case Diagram
5.1.2 package
有?Use Case Diagram後，對於OS要提供哪些功能就有個大?的?解，再?就是制訂區分各個class，但?將整個系統的程式碼?寫在一起，將會顯得雜?無章、缺乏架構，所以在本專題中將OS分為?個package，一為kernel，負責OS核心動作的處?；一為event，對於系統所提供的服務做處?。如圖十三
圖十三. OS中分為?大package
5.1.2.1 kernel package
Kernel package中的class負責OS 核心動作的處?，包括系統的初始化、process的create、process 的管?與排程等。在表三中，概?性的介紹?kernel package中各個class 的功能。
5.1.2.2 event package
5
表四中描述?event package中所包含的各個class的用途。Semaphore, Mail box, and Queue 用?做process之間的communication與synchronization。
5.2 OS架構的修改
在原本MicroC/OS-II的架構中，每一個event?會擁有一個屬於自己的event table，使用此方法在分派event時，可以快速找到等待該event的task中優先權最高的一個。但當產生系統中產生很多event時，眾多的event table將會耗費掉相當大的空間。如此一?，對於空間使用必須非常謹慎的嵌入式系統而言是非常??的，於是本?文提出一改善方案。
為?節?event table所佔用的空間，無?有多少個event產生，?將只會存在一個event table。而task在等待哪一種event則記?在task各自的資訊當中。當有event發出時，系統會到event table中去尋找最高優先權的task，並檢查其等待的event是否與剛發出的相同，??同，則繼續往後尋找。此方法與原方法比較起?會因為多一道步驟而慢一點點，但卻可以節?使用的空間，尤其是在task彼此互動頻繁的系統之中，此方法的優點會?加的明顯。
5.3 Timer的動作
本系統中模擬硬體情況實作一Timer。使系統可以在固定的時間間隔觸發ISR(Interrupt Service Routine)，以達到time management的功能。在這個ISR中，首先會去對每個process作?新的動作(如：delay time的修正)，並且適當的對各個process作處?(如：從waiting-list轉移到ready-list)。由於processes的?態有可能因為Timer而改變，所以最後必須要在執?scheduler讓最高優先權的process可以執?。
5.4 Interface
為??加??的使用OS，我們根據OS所提供的功能，實作一個interface定義他們的使用方式。在interface中，每個OS的method?用一個method ID?表示，interface從Java Processor傳入的extended instruction中取得method ID，然後將從Java Processor取得的??傳入OS中，呼叫相對應的method。
5.5 Java Processor的修改
定義Extended Instruction
為?讓Java Processor能夠認得OS所提供的功能，並且區分一般的Java指?，圖十四中定義??種格式的extended instruction。圖十四. Extended instruction
圖十四(左)，除?newTask外的method皆為這種格式。一般method呼叫的指?，透過Java compiler處?後，會變成一個invoke的指?加上method index，之後執?時，再根據method index從constant pool 中取得method實際的位址。而OS所提供的method，則是被compile成extended 指?加上method ID及傳入值的個?，然後透過interface執?OS的功能。
圖十四(右)，特別為?newTask所設計的格式。newTask是用?要求OS建構新的task，newTask有?個傳入??：prio和taskname，prio用?表示task的優先權；taskname是task的名稱，我們將根據這個名稱找出task程式碼在記憶體中實際存在的位址。?是一般的Java指?，將會被compile成?個?續的method呼叫，而我們所定義的extended格式，除?上種格式的資訊外，還加上task程式碼開頭的PC值。
5.6 針對SoCAD Tool的限制修改
爲?縮短開發?程，我們?用非同步系統及爪哇技術實驗室實驗室所研發的SoCAD Tool，SoCAD Tool可以把Java程式轉換成VHDL程式語言，由於還在開發階段SoCAD Tool並?是相當完善，在使用當時只能一次轉換一個class檔，所以必須把當初撰寫好的多個class改寫成一個class，也因此無法使用object，當初?用reference?找到各個task的date及變?，必須改成使用priority當作index儲存在array當中。同時SoCAD Tool並?支援所有API，在用到沒有支援的API時，必須實作出?，針對以上的限制修改並做整?，以?轉成VHDL程式語言。
6、結?與未?發展
6
本?文提出一個Java-based 即時嵌入系統架構設計，只要將欲執?的應用程式加入此架構中，即可構成一完整的嵌入式系統。此架構具有以下特色：
(1)?用Java Processor改善執?Java bytecode時效能?彰的問題。
(2)整合OS與CPU，處?processes之間的調?與溝通，達到multi-processes的功能。
(3)將原本軟體執?的OS轉換成硬體電?，達到提高效能與節?電能的目的。
(4)可輕?的增減系統提供的功能。
(5)只需將應用程式放於此架構上即可執?。
本?文中目前已將kernel與一些基本功能(如：semaphore、mailbox、queue)建構完成，預計未?在系統中再加入memory management、file system、network等功能，擴大系統的使用範圍與能?。
?考文獻
[1] 探矽實驗室, 嵌入式系統導?, 2004
[2] Sun Microsystems Inc. The Java Language: An Overview, 1995
[3] Jean J. Labrosse, ”MicroC/OS-II The Real-Time Kernel”, 1999
[4] 王平雲, 非同步爪哇處?器之設計與實作, 2004
[5] Bill Venners, inside the Java2 Virtual Machine, 1999
[6] 非同步系統及爪哇技術實驗室
[7] Simon Bennett, Steve McRobb and Ray Farmer, Object-Oriented