可裁製之嵌入式作業系統設計

可裁製之 可裁製之 可裁製之

可裁製之嵌入式 嵌入式 嵌入式作業系統 嵌入式 作業系統 作業系統設計 作業系統 設計 設計 設計

蘇惠明 劉建宏 陳 敬 國立成功大學電機工程學系

{ken,luiken,jchen}@rtpc06.ee.ncku.edu.tw

摘要 摘要 摘要 摘要

嵌入式軟體並不一定要使用作業系 統，但隨著嵌入式軟體越來越複雜，為了 節省開發時間及成本，搭配使用作業系統 及中介軟體等標準軟體越來越重要。由於 各種嵌入式產品應用及硬體差異性甚高，

且要求整體系統精簡性，以達到降低成本 之目的，嵌入式作業系統必須能易於裁 製，才能發揮其最大價值。Linux 近年來 在嵌入式系統領域受到相當程度之矚目，

核心也可以作某一程度之配置，將系統資 源需求量降低，但仍屬有限。本文介紹一 個嵌入式作業系統，採用微核心架構來設 計，能因應嵌入式產品之需求而調整作業 系統服務，讓嵌入式產品達到最佳之精簡 性。。。 。

關鍵詞關鍵詞關鍵詞

關鍵詞：嵌入式作業系統、微核心

一 一 一

一、 、 、背景 、 背景 背景說明 背景 說明 說明 說明

對嵌入式軟體來說，依產品複雜度不 同，或許並不一定皆需要作業系統。但今 日嵌入性軟體日趨龐大複雜，使用作業系 統可以簡化應用軟體之設計，降低軟體開 發時間及成本，所以在嵌入式系統領域來 說，作業系統是一個相當重要之研究議 題。嵌入式作業系統之設計重點，有別於 一般目的(general-purpose)之作業系統，其 設計重點如省電性、即時性、精簡性、可 靠性及重用性等皆有異於一般目的之作業 系統之設計。另外一個重要之不同是嵌入 式作業系統必須滿足各種嵌入式產品需求

殊異，及整個產品之精簡性，要同時滿足 這些需求，在架構設計上必須能易於裁製 (tailorable)以提高其再用性[6]。

嵌入式作業系統之設計主要可以分成 兩 種 ， 一 種 是 單 體 式 核 心 (Monolithic-Kernel) ， 一 種 是 微 核 心 (Microkernel)。單體式核心為傳統核心的 架構如 Linux 等，核心將大部分的功能(例 如檔案系統、行程管理及網路管理等)整合 在核心內，如此一來所有的作業系統服務 (system service)只須呼叫相對應之函式，

其系統反應相對快速。微核心架構之作 法，是將大部分的功能移出到核心之外，

成為系統中執行的行程(process)，而核心 只須擁有必備之基本功能，因此稱為微核 心架構[3]，在此架構下，一般使用者行程 需要作業系統服務時，透過核心與擁有該 服務之行程溝通，核心並不負責系統服務 之實作。由於應用程式與作業系統服務之 溝通，必須透過核心來處理，導致系統反 應稍慢，但是這樣設計方式，應用程式不 直接與系統服務溝通，卻可以提高系統之 可靠性(reliability)。

uClinux [9]是以 Linux 核心所發展出 來之嵌入式系統專用開放源碼作業系統，

主 要 是 專 門 針 對 沒 有 記 憶 體 管 理 單 元 (MMU)之微處理器而設計。uClinux 則在 結構上繼承了標準 Linux 之多工實現方 式，並針對嵌入式處理器特點進行改良，

的確可以滿足某些嵌入式特性，但對即時 性之要求卻有力未逮。要實現即時性則需 要 使 系 統 在 即 時 核 心 之 控 制 下 執 行 ， RT-Linux 是可以實現此一個功能之即時核 心。可以不管是 uClinux 或 RT-Linux，當 面臨嵌入式系統對於系統精簡性要求時，

雖然可以對核心功能作某種程度之配置，

以求降低資源需求，但相對於微核心架構 可以因應產品不同而大幅裁製系統服務，

兩相對照之下，前者還是稍嫌龐大。大多 數 小 型 控 制 系 統 要 求 精 簡 性 、 即 時 性 (real-time)及可靠性，微核心架構是一個 相當好的起點[2]。

二 二 二

二、 、 、作業系統 、 作業系統 作業系統架構 作業系統 架構 架構 架構

本文之嵌入式作業系統之設計，以小 型嵌入式系統為適用對象，可以分成兩個 層面來考量，一是基本功能，二是裁製性 考量。就基本功能面來說，精簡性及可靠 性是嵌入式產品最基本之需求，採用微核 心架構是相當好之選擇。此架構下，核心 只滿足作業系統最基本之需求，所以只放 置 本 文 切 換 (Context Switch) 訊 息 傳 遞 (Message Passing) 及 中 斷 處 理 函 式 (Interrupt Service Routines)前置處理，其 餘作業系統之附屬功能則依產品之需求而 附加，可讓整個系統達到最精簡化。另外 就裁製性考量面來說，影響因素最重要的 兩個層面為應用軟體需求及硬體需求。就 應用軟體需求面來看，排程(scheduling) 方式、行程管理 (process management)、

資源管理(resource management)、即時性 及可擴充性等皆會影響到作業系統之架 構。就硬體需求面來看，處理器數量、指 令集種類、有無 MMU 之支援、記憶體大 小等以上皆會對嵌入式作業系統之架構設 計產生重大之影響。在設計整個作業系統 時並無法以單一架構涵蓋所有層面，甚至 有些特點可能會相互衝突，例如使用記憶 體管理單元(MMU)就可能增加即時性對 於時間確定性要求之困難，因此我們在設 計時儘量考量最大的交集。在本文中並不 詳述所有作業系統所需之所有功能，我們 將重點集中於闡述滿足易裁製性之嵌入式 作業系統所需之主要架構，考量要點如下：

1. 硬體平台考量。

2. 即時性考量。

3. 核心架構與排程器。

4. 行程管理 5. 行程通訊

在開發工具之選用也須視為考量，C 語言是高階語言中控制硬體能力相當強的 一種，各種硬體平台之函式庫(Library) 支援也相當完整，兼具效能與效益，我們 選用 GCC (GNU C Compiler)作為主要開發 工具，除非必要不得已採用組合語言，大 部分原始碼皆以 C 語言撰寫。

(一)硬體平台考量

嵌入式系統的硬體十分多樣化，無法 以單一種硬體來代表，但是作業系統與其 相 依 性 最 大 之 因 素 取 決 於 處 理 器 (processor)及記憶體(memory)架構。基於 以下之考量，我們選用 TMS320DM270(以 下簡稱 DM270)來作為本系統發展之硬體 平台：

1. 由於嵌入式系統十分講究效率，隨 著晶片製造製程之幾何尺寸不斷變 小，價格不斷降低，SoC(System on Chip)之應用正蓬勃發展。

2. 各種 SoC 中，尤以 ARM core 省電 及高效能之特性，在嵌入式系統領 域使用最廣。

3. 此一平台無 MMU，雖然 MMU 可 以增加記憶體管理之彈性，卻增加 系統之複雜性及時間之不確定性。

DM270 處理器由兩個微處理器核心，

ARM7TDMI 與 TMS320 C5409 組成，採 用主僕式架構：以 ARM 為主動端，C5409 為被動端，ARM 可以經由 DSP 控制器重 置、或喚醒 C5409，還可對 C5409 發出不 可 遮 罩 式 中 斷 (Non-Masked Interrupt)。

ARM7TDMI 為 32 位元 Non-MMU 通用 型處理器(General Processor)，主要執行 DM270 所 有 的 周 邊 控 制 及 作 業 系 統 運 作，例如：按鍵輸入、快閃記憶體、串列 埠 、 螢 幕 顯 示 等 周 邊 輸 入 輸 出 裝 置 。 TMS320C5409 為 16 位 元 訊 號 處 理 器 (DSP)，主要任務是多媒體與數位訊號資 料處理，例如編碼器及解碼器運算[8] 。

DM270 上 ARM 端之記憶體可以分

四 個 部 分 ， 分 別 是 內 部 記 憶 體 (Internal RAM)、記憶體映射 I/O(Memory Mapped I/O)、DSP 共享記憶體及 64MB 之外部 SDRAM。本文之作業系統架構除了核心 與排程器常駐在內部記憶體中外，所有行 程皆在 SDRAM 中執行，因此可以加快 ARM 執行系統核心程式碼的速度[8]。

為了能夠支援多處理器的硬體架構，

我們沿用[1]之系統架構設計(圖 2-1)，

ARM 端的微核心系統上執行了一個伺服 行程(Server)，DSP Manager，利用 DSP Manager 與 DSP 端的系統溝通。當 ARM 端的行程需要使用到 DSP 端系統之功能 時，就藉由 DSP Manager 之服務，呼叫 DSP 功能；而當 DSP 端的行程需要使用到 ARM 端 的 功 能 時 ， 仍 然 是 藉 由 DSP Manager 來取得所需要之資料。藉由 DSP Manager 作為 ARM 與 DSP 端的橋樑，可 擴充為多處理器系統。

圖 2-1 多處理器作業系統架構

(二)即時性考量

嵌入性產品有許多設計重點如省電 性、精簡性或即時性等，皆有可能對整個 作業系統架構造成相當程度之影響，若就 軟體層面來考量，即時性應是影響最大的 特性。即時性需求在嵌入式產品應用十分 常見，例如大多數多媒體應用多是軟即時 系統(Soft Real-time System)。嵌入式即時 作業之需求可以參考 Martin Timmerman 在[5] 中強調作業系統核心必須滿足下列 條件，才是一個即時作業系統核心。

1. 系 統 必 須 支 援 可 被 搶 先 (Preemptive)之多執行緒(Thread)。

2. 系統必須支援執行緒優先權之排程

方法。

3. 系統必須支援可預測之執行緒同步 機制。

4. 系統必須支援優先權繼承之機制。

5. 核心之行為必須是可預測的。

在設計作業系統架構時要將以上條件 納入考量，事實上已展現出作業系統雛 型：必須支援多執行緒或多行程、行程要 有同步機制及資源管理機制，而且核心服 務之執行時間必須是可預期的。

(三)核心架構與排程器

圖 2-2 為以 ARM 端為主之系統核 心架構圖，虛線下是屬於微核心部分，包 括中斷介面(Interrupt Interface)、訊息傳遞 (Message Passing)、系統呼叫介面(System Call Interface)及本文切換(Context Switch) 虛線之上是屬於執行中的行程。硬體中斷 發生時，會啟動中斷介面的執行，中斷介 面會再啟動由驅動程式行程或是行程所註 冊的中斷處理函式。

圖 2-2 微核心架構

所有行程透過系統呼叫介面與核心溝 通，系統呼叫介面會啟動系統呼叫處理函 式。這些系統呼叫分成三類，分別是訊息 傳遞、中斷處理、及其它功能。若要直接 使用系統呼叫的方式與核心溝通，勢必要 使用組合語言才行。這種方式太過於低 階，移植性不高，因此必須使用包裝函式 (Wrapper Functions)，包裝函式是以內嵌 組語(inline assembly code)實作而成，使用 AT&T 之組合語言語法，這是使用 GCC

為編譯器時最常被利用之內嵌組合語言，

當移植到不同硬體平台時，易於修改。

訊息傳遞是微核心系統上行程之間最 重要之溝通方式，使用約會型訊息傳遞 (Rendezvous Message-Passing)機制。當一 個行程要傳送訊息給另外一個行程時，若 另外一個行程並沒有準備好要接收此訊 息，則傳送訊息行程會停頓(block)，直到 對方接收了此訊息之後，原行程才會繼續 執行。當一個行程要接收由另一個行程傳 來之訊息時，若對方並沒有要傳送訊息給 此行程，則此行程也會停頓，直到對方傳 送訊息為止。

使用約會型訊息傳遞之優點是系統核 心不需要為每一個行程配置額外之記憶體 來存放訊息的佇列，因此可以更簡單且快 速地完成訊息傳送。更重要的是，如此一 來訊息傳送之時間可在有限時間之內完 成，符合即時性之需求。

使用約會型訊息傳遞最大缺點是為優 先 權 反 轉 問 題 (Priority Inversion Problem)，也就是在特定情況下，高優先 權行程，必須等待低優先權行程執行完成 才 能 繼 續 執 行 ， 違 反 了 一 般 即 時 系 統 (Real-time System)對於高優先權行程必 須優於低優先權行程執行之假設。要克服 此一問題必須修改訊息傳遞的機制，實作 優 先 權 繼 承 機 制 (Priority Inheritance Protocol)[4]。

為了加快系統反應速度，中斷處理機 制分為二段式：前段中斷處理(Top-half) 與後段中斷處理(Bottom-half)。前段中斷 處理是由核心啟動行程註冊之中斷處理函 式，反應速度較快，但每個中斷間並沒有 優先權之分別。後段中斷處理會經由排程 器選出相對應有優先權之行程並執行，其 反應速度較慢。在前段中斷處理函式內，

通常安排必須要快速完成，不能被打斷之 簡單工作。例如計時器中斷發生時，計時 器中斷處理函式需要去更新系統時間值，

然後中斷處理函式使用系統呼叫來通知相 對應之行程，此行程接收此訊息，並開始 執行後段中斷處理。在後段中斷處理函

式，則進行處理動作較複雜，並不要求在 很短時間之內完成，且可以被搶先之工 作。此中斷處理機制有兩個主要特點。第 一是讓行程可以動態地向微核心註冊中斷 處理函式，而在中斷發生時，微核心會啟 動行程所註冊之處理函式。第二是中斷處 理函式可以如行程一般傳送訊息給其它行 程。一個行程可以使用系統呼叫向系統註 冊，當中斷發生時，微核心會啟動行程註 冊之處理函式，作完前置處理後，發送訊 息給後段中斷處理行程。

到底到要將排程器放置於微核心之內 或獨立於核心之外的一個行程，取捨之間 頗為困難，因為排程器之使用相當頻繁，

所以將其放置於微核心之內可以提高整體 效能，但若置於核心外，卻可以增加排程 演算法修改彈性，而為了滿足易裁製之需 求，我們將之獨立於微核心之外另成一行 程。

由於排程是一個獨立行程，因此隨時 可依應用軟體需求自行修改適合之排程。

在此我們先沿用[1]使用的排程演算法作 為內定之演算法，該演算法是有限時間排 程(Bounded Time Scheduling)，排程器執 行所需時間與系統中行程之數量無關而是 相依於行程就緒個佇列(Ready Queue)數 量(預設值為 64)，每一行程會被系統核心 依據其優先權安置在相對應之佇列中，一 旦排程器被啟動時，它就會開始由高優先 權的佇列往低優先權的佇列中尋找，只要 某一個佇列中擁有就緒之行程(佇列不為 空的)，就會被選為下一個要執行的行程，

因此在最壞的情況下，最大搜尋次數為 64 次。

(四)行程管理

行程可以細分為伺服行程與使用者行 程，伺服行程排程以先進先出(FIFO)為原 則 ， 使 用 者 行 程 排 程 則 以 輪 流 (Round-Robin) 之方式來排程。伺服行程 一 般 優 先 權 高 於 使 用 者 行 程 ( 最 高 為 32)，以便負責系統中較重要之任務。

伺服行程包括一般作業系統所具備之 服務如行程管理者、檔案系統管理者、圖

形介面管理者等等，主要是用來提供服務 給其它行程。其中行程管理者是用來管理 系統中所有行程。本系統支援多行程及多 執行緒。所有關於行程產生、行程終止、

執行緒產生、執行緒終止、信號(Signal) 發送，皆由行程管理者來負責。

系統中要產生新的使用者行程，必須 傳送訊息給行程管理者。所產生之新行程 直接執行另外一個新的程式，與 Unix 先 使用 fork 系統呼叫，再執行 execute 系統 呼叫執行另外一個新程式之方式不相同。

這是由於沒有 MMU 之支援，無法實作出 完整 fork 系統呼叫。

一個行程若要產生新執行緒，可以傳 送訊息給行程管理者，訊息中帶著要產生 執行緒的函式位址，行程管理者會搜尋出 一個空的行程控制區塊，並將函式位址設 定在行程控制區塊中，最後行程管理者使 用系統呼叫將此行程控制區塊放入就緒佇 列中排程。同屬於一個行程之執行緒會加 到一個執行緒集合(Thread Set)中，並以該 行程代號作為執行緒集合代號，當一執行 緒執行結束時，執行緒控制區塊會由執行 緒集合中移除，行程管理者會馬上回收此 執行緒控制區塊，若是主行程執行結束，

則整個執行緒集合(包括了主行程控制區 塊、所有的執行緒控制區塊)皆會被行程管 理者回收。

(五)行程通訊

信號是 POSIX 標準行程間溝通機制 (Inter-Process Communication) [7] ，信號 發送是軟體用來模擬硬體中斷之一種方 式，當處理器正在執行時，硬體中斷產生 時，處理器會放下目前正在執行之程式片 段，跳到中斷處理函式執行，當處理器處 理完硬體中斷後，會再回到原來的程式片 段繼續執行，而信號(Signal)機制就是軟 體模仿此一方式。行程可以向行程管理者 註冊信號處理函式，註冊之後信號處理函 式會記錄在行程控制區塊(Process Control Block)中，當一個行程可以發出信號給另 外一個行程，這時不論另外一個行程正處 在什麼狀態，也會放下正在執行的主程式

碼，跳到信號處理函式，當信號處理函式 執行完時，會再回到原來被中斷之主程式 碼繼續執行。

三 三 三

三、 、 、系統 、 系統 系統 系統裁 裁 裁 裁製 製 製 製

本架構之優點，可以由二方面來呈現 一是硬體改變，在同一處理器架構前提下 所需修改之原始碼並不多；一是依產品需 求不同，可以由系統所提供之裁製介面來 選擇所需之系統服務，讓整個系統達到最 佳精簡性。

(一)硬體移植

由於硬體製造價格降低，運算速度更 快，系統移植(Porting)是嵌入式系統無可 避免的一個課題。使用作業系統之好處是 只須移植作業系統，毋須修改應用軟體，

可以節省開發時間。本架構在設計時考量 到系統可携性，大多數程式碼皆以高階 C 語言撰寫，移植時只需重新改寫底層的組 合語言中斷處理、週邊裝置相關與開機初 始化時的程式碼。由於採用微核心之架 構，因此核心部份與硬體無關，而僅需修 改與伺服行程相關之部份如檔案系統伺服 行程及各種 I/O 裝置之設置暫存器位址以 及裝置之中斷設定，茲以 DM270 移植到 DM320 為例來說明本系統之高移植性。

DM320 平台與 DM270 平台週邊設備 差異性不大，其差異點為：

1. DM270 之 ARM Core 屬 ARM7 系 列而 DM320 是 ARM9 系列，指令 集可以相容。

2.

3.

所以由 DM270 移植至 DM320 時特 別要注意，由於本架構之微核心程 式碼十分精簡，內部記憶體只用不 到 DM270 之內部記憶體的一半，

所以，並沒有因為內部記憶體變少 而產生問題，所以毋須修改，但是 當程式碼大小超過內部記憶體一半 時，就必須重新配置記憶體位置。

總計必須修改之處只有三個部份：第 一個是 TTY 伺服行程，是為系統透過 RS-232 介面與使用者溝通之介面。第二個 是 Compact Flash (CF)記憶卡驅動程式，

修改 CF 卡週邊裝置之基底暫存器位址與 其相關暫存器位址。第三個是網路，修改 第四塊外部記憶體區域(External Memory Region 4)之暫存器之基底暫存器位址與 中斷所用的 GIO6 及 CS8900 週邊裝置之基 底暫存器位址，整個移植工作相當精簡。

(二)作業系統服務裁製

軟體裁製可以分成三個層面來看，移 除不必要之硬體驅動程式是最基本層次，

大多數嵌入式作業系統皆會提供此一服 務；移除作業系統不必要之系統服務是更 進一步之層次；最高層次是簡化核心，只 提供系統運作之必要功能。從後面兩個層 次來看，由於單體式核心作業系統將系統 服務與核心合在一起設計，要重新裁製要 考慮各個系統服務之相依性所花費之代價 比之微核心架構作業系統必然高許多而且 成效也無法與後者相比。

圖 3-1 是本架構在進行作業系統裁製 時之人機介面，採用條件式編譯之方法，

依產品需求將最精簡之系統服務功能整合 成為一個嵌入式作業系統。

圖 3-1 裁製系統服務之人機介面

四 四 四

四、 、 、結論 、 結論 結論 結論

本文旨在研究藉由可裁製之嵌入式作 業系統設計，以因應嵌入式產品應用與硬 體之多樣性之需求。由於應用軟體及硬體

層面皆會影響作業系統之設計，所以採用 微核心架構來設計，微核心相較於單體式 核心能提供更優越之裁製性。

當然要設計一套可以適用到各種不同 嵌入式產品之作業系統，本質上是非常困 難，但在同一系列硬體基礎上，由 DM270 移植到 DM320 之實例來看，此一架構十 分具可携性。本文中雖只針對 ARM Based SoC 系列硬體平台為基礎來設計，但相同 作業系統架構應能擴展應用到其它相同系 列之處理器，目前我們正著手其它先進軟 硬體技術對作業系統架構之研究，我們期 盼將來能更設計出應用更廣之作業系統架 構，讓嵌入式產品開發成本能再降低。

誌謝

本論文承蒙國科會補助部分經費，研 究計畫編號：NSC 95-2221-E-006-091，特 此誌謝。

五 五 五

五、 、 、參考文獻 、 參考文獻 參考文獻 參考文獻

[1] 洪文彬、歐旭江、陳敬，“異質性多處

理 器 嵌 入 式 系 統 平 台 架 構 設 計 ” ， 2005 年數位生活與網路科技研討會，

成功大學，2005 年 5 月。

[2] Jochen Liedtke, “µ-Kernel Must And Can Be Small”, 5th IEEE Internal Workshop on Object-Orientation in Operating Systems, pp. 152-155, 1996.

[3] Michel Gien, “Micro-kernel

Architecture Key to Modern Operating Systems Design”, Technical Report CS/TR-90-42.1, Chorus syst`emes, Paris, 1990.

[4] L. Sha, R. Rajkumar, and J.P. Lehoczky,

“priority Inheritance Protocols, An Approach to Real-Time Synchronization”, IEEE Transactions on Computers, Vol. 39, NO. 9, pp.1175-1185, September, 1990.

[5] Martin Timmerman, “Windows NT as Real-Time OS? ”,

http://www.dedicated-systems.com/mag azine/97q2/winntasrtos.htm

[6] Peter Marweded, “Embedded System Design”, ISBN 1402076908.

[7] “POSIX threads programming”, http://www.llnl.gov/computing/tutorials

/pthreads/.

[8] Texas Instruments, “TMS320DM270 CPU and Peripherals Technical Reference Manual Version 1.1”.

[9] uCLinux,

http://www.uclinux.com/uclinux.shtml.