嵌入式系統開發設計---嵌入式系統開發設計

     嵌入式系統設計的主要任務是定義系統的功能、決定系統的架構，並將功能映射到系統實現架構上。這裏，系統架構既包括軟件系統架構也包括硬件系統架構。一種架構能夠映射到各類不一樣的物理實現，每種實現表示不一樣的取捨，同時還要知足某些設計指標，並使其餘的設計指標也同時達到最佳化。

    嵌入式系統的設計方法跟通常的硬件設計、軟件開發的方法不一樣，是採用硬件和軟件協同設計的方法，開發過程不只涉及軟件領域的知識，還涉及硬件領域的綜合知識，甚至還涉及機械等方面的知識。要求設計者必須熟悉並能自如地運用這些領域的各類技術，才能使所設計的系統達到最優。

    雖然嵌入式系統應用軟件的設計方案隨應用領域的不一樣而不一樣，可是嵌入式系統的分析與設計方法也遵循軟件工程的通常原則，許多成 熟的分析和設計方法均可以在嵌入式領域獲得應用。嵌入式系統的開發過程一樣也包括需求分析、系統設計、實現和測試幾個基本階段，而且每一個階段都有其獨有的特徵和重點。

    本節主要介紹嵌入式系統開發設計的技術與方法，並從嵌入式系統應用和計算模型的角度分析應用軟件設計的方法及設計過程當中面臨的主要問題。最後，討論嵌入式領域軟件移植的相關問題。

 

1 嵌入式系統設計概述

    進行嵌入式系統設計前，應明確嵌入式系統設計自己的特色及衡量嵌入式系統設計的一些主要的技術指標。

    1．嵌入式系統設計的特色

    與一般的系統設計相比，嵌入式系統設計具備如下特色：

• 軟、硬件協同並行開發；

• 微處理器的類型多種多樣；

• 實時嵌入式操做系統具備多樣性；

• 與通用系統開發相比，可利用系統資源不多；

• 應用支持少；

• 要求特殊的開發工具；

• 軟、硬件都要很健壯；

• 調試很困難。 

    2．嵌入式系統的技術指標

    嵌入式系統設計的經常使用指標有：

    （1）NRE 成本（非重複性工程成本）：設計系統所須要支付的一次性貨幣成本，即一旦設計完畢，不須要支付額外的設計費用，就能夠製造任意數目的產品。

    （2）單位成本：生產單個產品所須要支付的貨幣成本，不包含 NRE 成本。

    （3）大小：指系統所佔的空間，對軟件而言，通常用字節數來衡量；對硬件而言，則用邏輯門或晶體管的數目來衡量。

    （4）性能：系統完成規定任務所須要的時間，是設計時最經常使用的設計指標，主要有兩種衡量方式，一是響應時間，即開始執行到任務結束之間的時間。二是完成量，即單位時間內所完成的任務量。

    （5）功率：系統所消耗的功率，它決定了電池的壽命或電路的散熱需求。

    （6）靈活性：在不增長 NRE 成本的前提下，改變系統功能的能力。

    （7）樣機創建時間：創建系統可運行版本所需的時間，系統樣機可能比最終產品更大更昂貴，但能夠驗證系統的用途和正確性，改進系統的功能。

    （8）上市時間：從系統開發到能夠上市賣給消費者的時間，最主要的影響因素包括設計時間、製造時間和檢測時間。

    （9）可維護性：系統推出或上市後進行修改的難易程度，特別是針對非原始開發人員進行的修改。

    （10）正確性：正確實現了系統的功能，能夠在整個設計過程當中檢查系統的功能，也能夠插入測試電路檢驗是否正確。

    （11）安全性：系統不會形成傷害的機率。各個設計指標之間通常是互相競爭的，改良了某個指標經常會致使其餘指標的惡化，

    爲了最好地知足設計最佳化，設計者必須瞭解各類軟、硬件的實現技術，而且可以從一種技術轉移到另外一種技術，以便找到特定約束下的最佳方案。

    3．嵌入式系統的設計挑戰

    嵌入式系統設計所面臨的挑戰有如下幾個方面。

    （1）須要多少硬件：設計者對用於解決問題的計算能力有較強的控制能力，不只能夠選擇使用何種處理器，並且能夠選擇存儲器的數量、所使用的外設等，由於設計不只要知足性能的需求，還要受到製造費用的約束，硬件的選擇十分重要，硬件太少，將達不到功能和性能的要求，硬件過多又會使產品過於昂貴。

    （2）如何知足時限：使用提升處理器速度的方法使程序運行速度加快來解決時間約束的方法是不可取的，由於這樣會使系統的價格上升。同時，提升了處理器的時鐘頻率，有時並不能提升執行速度，由於程序的速度有可能受存儲系統的限制。

    （3）如何減小系統的功耗：對採用電池供電的系統，功耗是一個十分敏感的問題。對於非電池供電的系統，高功率意味着高散熱。下降系統功耗的一種方法是下降它的運算速度，可是單純地下降運算速度顯然會致使性能不能知足，所以，必須認真設計在下降功耗的同時知足性能的約束。

    （4）如何保證系統的可升級性：系統的硬件平臺可能使用幾代，或者使用同一代的不一樣級別的產品，這些僅須要一些簡單的改變，設計者必須經過改變軟件來改變系統的特性，設計一種機器使它可以提供如今仍未開發的軟件的性能。

    （5）如何保證系統的可靠性：可靠性是產品銷售時一項重要的指標，產品可以很好地工做是消費者的合理要求，可靠性在一些系統中尤其重要，如安全控制系統。

    （6）測試的複雜性：測試一個嵌入式系統比僅僅輸入一些數據困可貴多，因此不得不運行整臺機器以產生正確的數據，數據產生的時間是十分重要的，即不能離開嵌入式系統工做的整個環境來測試嵌入式系統。

    （7）可視性和可控制性有限：嵌入式系統一般沒有顯示設備和鍵盤，這將致使開發者很難了解系統內部發生了什麼，也不能響應系統的動做，有時候不得不經過觀察微處理器的信號來了解。在實時系統中，通常沒法爲了觀察而讓系統停機。

    （8）開發環境受限：嵌入式系統的開發環境，如開發軟件、硬件工具一般比通用計算機或工做站上的可用環境更爲有限，故只能採用交叉式開發，給開發進度帶來很大影響。

 

2   開發模型與設計流程

    與通用系統的開發相似，嵌入式系統的開發也能夠採用軟件工程中常見的開發模型，主要包括瀑布模型、螺旋模型、逐步求精模型及層次模型。

    1．經常使用開發模型

    設計流程是系統設計期間應遵循的一系列步驟，其中一些步驟能夠由自動化工具完成，而另一些只可用手工完成。在嵌入式系統領域，有以下幾種經常使用開發過程模型。

    （1）瀑布模型。瀑布模型由五個主要階段構成：需求分析階段肯定目標系統的基本特色；系統結構設計階段將系統的功能分解爲主要的構架；編碼階段主要進行程序的編寫和調試；測試階段檢測錯誤；最後一個是維護階段，主要負責修改代碼以適應環境的變化，並改正錯誤、升級。各個階段的工做和信息老是由高級的抽象到較詳細的設計步驟單向流動，是一個理想的自頂向下的設計模型。

    （2）螺旋模型。螺旋模型假定要創建系統的多個版本，早期的版本是一個簡單的試驗模型，用於幫助設計者創建對系統的直覺和積累開發此係統的經驗，隨着設計的進展，會建立更加複雜的系統。在每一層設計中，設計者都會通過需求分析、結構設計、測試三個階段。在後期，當構成更復雜的系統版本時，每個階段都會有更多的工做，並須要擴大設計的螺旋，這種逐步求精的方法使設計者能夠經過一系列的設計循環加深對所開發的系統的理解。螺旋的頂部第一個循環是很小很短的，而螺旋底部的最後的循環加入了對螺旋模型的早期循環的細節補充，螺旋模型比瀑布模型更加符合實際。

    （3）逐步求精模型。逐步求精模型是一個系統被創建屢次，第一個系統被做爲原型，其後逐個將系統進一步求精。當設計者對正在建造的系統的應用領域不是很熟悉時，這個方法頗有意義。經過建造幾個愈來愈複雜的系統，從而精煉系統，使設計者能檢驗架構和設計技術。此外，各類迭代技術也可僅被局部完成，直到系統最終完成。

    （4）層次模型。許多嵌入式系統自己是由更多的小設計組成的，完整的系統可能須要各類軟件構件、硬件構件。這些部件可能由尚需設計的更小部件組成，所以從最初的完整系統設計到爲個別部件的設計，設計的流程隨着系統的抽象層次的變化而變化，從最高抽象層次的總體設計到中間抽象層次的詳細設計，再到每一個具體模塊的設計，都是逐層展開的，其中每一個流程可能由單個設計人員或設計小組來承擔，每一個小組依靠其餘小組的結果，各個小組從上級小組得到要求，同時上級小組依賴於各個分組設計的質量和性能。並且，流程的每一個實現階段都是一個從規格說明到測試的完整流程。

    2．嵌入式系統的設計方法

    一個良好的嵌入式系統設計方法是十分重要的，這是由於：

    （1）良好的設計方法可使設計者清楚地瞭解他們所作工做的進度，這樣能夠確保不遺漏其中的任何一項工做。

    （2）容許使用計算機輔助工具幫助設計者進行工做，將整個過程分紅幾個可控的步驟進行。

    （3）良好的設計方法方便設計團隊的成員之間相互交流，經過定義全面的設計過程，使團隊裏的每一個成員能夠很好地理解他們所要作的工做及完成分配給他們的任務時所達到的目標。

    嵌入式系統軟件的開發過程能夠分爲項目計劃、可行性分析、需求分析、概要設計、詳細設計、程序創建、下載、調試、固化、測試及運行等幾個階段。

    項目計劃、可行性分析、需求分析、概要設計及詳細設計等幾個階段，與通用軟件的開發過程基本一致，均可按照軟件工程方法進行，如採用原型化方法、結構化方法等。

    因爲嵌入式軟件的運行和開發環境不一樣，開發工做是交叉進行的，因此每一步都要考慮到這一點。

程序創建階段的工做是根據詳細設計階段產生的文檔進行的。這一階段的工做主要是源代碼編寫、編譯、連接等幾個子過程，這些工做都是在宿主機進行的，不須要用到目標機。

    產生應用程序的可執行文件後，就要用到交叉開發環境進行調試，根據實際狀況能夠選用可用的幾種調試方法之一或它們的有效組合來進行。

    嵌入式系統設計不一樣於傳統的軟件設計，如圖 12-11 所示。常常包含硬件設計和軟件設計，其中前端活動，如規格說明和系統架構，須要同時考慮硬件和軟件兩個方面。

    相似的，後端設計，如系統集成和測試要考慮整個系統。在中間階段中，軟件和硬件構件的開發彼此相互獨立，而且大多數的硬件和軟件的工做可以相對獨立地進行。最後，要將經調試後正確無誤的可執行程序固化到目標機上。根據嵌入式系統硬件上配置的不一樣，固化有幾種方式，能夠固化在 EPROM 和 FLASH 等存儲器中，也可固化在 DOC 和 DOM 等電子盤中。一般還要藉助一些專用編程器進行。

    因爲嵌入式系統對安全性和可靠性的要求比通用計算機系統要高，因此在對嵌入式系統進行白盒測試時，要求有更高的代碼覆蓋率。

    在系統開發流程的各個階段，分別要進行系統的確認和性能評估、安全性評估及風險性評價，並對系統的實現進行測試驗證。

 

3 嵌入式系統設計的核心技術

    嵌入式系統的開發是軟、硬件綜合開發，與通用系統的開發存在巨大差別，一方面是由於每一個嵌入式系統都是一個軟硬件的結合體；另外一方面，嵌入式系統一旦研製完成，軟件便隨着硬件固化到產品中，具備很強的專用性。在這些特色的影響下，必然要有一種不一樣於通用軟件開發過程的工程方法學來支持嵌入式系統的開發過程，同時，這些特色也決定了嵌入式系統開發所採用的獨特的核心技術。

    整體來看，在嵌入式開發領域，主要有三種核心技術：處理器技術、IC 技術、設計/ 驗證技術。

    1.處理器技術

    處理器技術與實現系統功能的計算引擎結構有關，不少不可編程的數字系統也能夠視爲處理器，這些處理器的差異在於其面向特定功能的專用化程度，致使其設計指標與其餘處理器不一樣。

    （1）通用處理器。這類處理器可用於不一樣類型的應用，一個重要的特徵就是存儲程序，因爲設計者不知道處理器將會運行何種運算，因此沒法用數字電路創建程序。另外一個特徵就是通用的數據路徑，爲了處理各種不一樣的計算，數據路徑是通用的，其數據路徑通常有大量的寄存器及一個或多個通用的算術邏輯單元。設計者只須要對處理器的存儲器編程來執行所需的功能，即設計相關的軟件。

    在嵌入式系統中使用通用處理器具備設計指標上的一些優點。上市時間和 NRE 成本較低，由於設計者只需編寫程序，而不需作任何數字設計，靈活性高，功能的改變經過修改程序進行便可。與自行設計處理器相比，數量少時單位成本較低。

    固然，這種方式也有一些設計指標上的缺陷，數量大時單位成本相對較高，由於數量大時，自行設計的 NRE 成本分攤下來，可下降單位成本。同時，對於某些應用，性能可能不好。因爲包含了非必要的處理器硬件，系統的體積和功耗可能變大。

    （2）單用途處理器。單用途處理器是設計用於執行特定程序的數字電路，也指協處理器、加速器、外設等。如 JPEG 編碼解碼器執行單一程序，壓縮或解壓視頻信息。嵌入式系統設計者可經過設計特定的數字電路來創建單用途的處理器。設計者也能夠採用預先設計好的商品化的單用途處理器。

    在嵌入式系統中使用單用途處理器，在指標上有一些優缺點。這些優缺點與通用處理器基本相反，性能可能更好，體積與功率可能較小，數量大時單位成本可能較低，而設計時間與 NRE 成本可能較高，靈活性較差，數量小時單位成本較高，對於某些應用，性能不如通用處理器。

    （3）專用處理器。專用指令集處理器是一個可編程處理器，針對某一特定類型的應用進行最優化。這類特定應用具備相同的特徵，如嵌入式控制、數字信號處理等。在嵌入式系統中使用專用處理器能夠在保證良好的性能、功率和大小的狀況下，提供更大的靈活性，但這類處理器仍須要昂貴的成本創建處理器自己和編譯器。單片機和數字信號處理器是兩類應用普遍的專用處理器，數字信號處理器是一種針對數字信號進行常見運算的微處理器，而單片機是一種針對嵌入式控制應用進行最佳化的微處理器。

    2．IC 技術 

    從系統的集成電路設計描述獲得實際芯片的物理映射過程的實現技術即是 IC（Integrated Circuits，集成電路）技術，當前在半導體領域的三類實現技術，即全定製、半定製和可編程技術都可應用於嵌入式系統的硬件設計。

    （1）全定製/VLSI（Very Large Scale Integrated Circuites，超大規模集成電路）。在全定製 IC 技術中，須要根據特定的嵌入式系統的數字實現來優化各層設計人員從晶體管的版圖尺寸、位置、連線開始設計以達到芯片面積利用率高、速度快、功耗低的最優化性能。利用掩膜在製造廠生產實際芯片，全定製的 IC 設計也常稱爲 VLSI，具備很高的 NRE 成本、很長的製造時間，適用於大量或對性能要求嚴格的應用。

    （2）半定製/ASIC（Application Specific Integrated Circuit，專用集成電路）。半定製ASIC是一種約束型設計方法，包括門陣列設計法和標準單元設計法。它是在芯片製做好一些具備通用性的單元元件和元件組的半成品硬件，設計者僅須要考慮電路的邏輯功能和各功能模塊之間的合理鏈接便可。這種設計方法靈活方便、性價比高，縮短了設計週期，提升了

成品率。

    （3）可編程/ASIC。可編程器件中全部各層都已經存在，設計完成後，在實驗室裏便可燒製出設計的芯片，不須要 IC 廠家參與，開發週期顯著縮短。可編程 ASIC 具備較低的 NRE 成本，單位成本較高，功耗較大，速度較慢。

    3．設計/驗證技術

    嵌入式系統的設計技術主要包括硬件設計技術和軟件設計技術兩大類。其中，硬件設計領域的技術主要包括芯片級設計技術和電路板級設計技術兩個方面。

    芯片級設計技術的核心是編譯/綜合、庫/IP（Intellectual  Property，知識產權）、測試/ 驗證。編譯/綜合技術使設計者用抽象的方式描述所需的功能，並自動分析和插入實現細節。庫/IP 技術將預先設計好的低抽象級實現用於高級抽象。測試/驗證技術確保每級功能正確，減小各級之間反覆設計的成本。

    軟件設計技術的核心是軟件語言。軟件語言經歷了從低級語言（機器語言、彙編語言）到高級語言（例如，結構化設計語言、面向對象設計語言）的發展歷程，推進其發展的是彙編技術、分析技術、編譯/解釋技術等諸多相關技術。軟件語言的級別也從實現級、設計級、功能級逐漸向需求級語言發展過渡。

    早期，隨着通用處理器概念的逐漸造成，軟件技術迅速發展，軟件的複雜度也開始增長，軟件設計和硬件設計的技術和領域徹底分開。設計技術和工具在這兩個領域同步獲得發展，也使得行爲描述能夠在愈來愈抽象的級別上進行，以適應設計複雜度不斷增加的須要。這種同步發展現在又使得這兩個領域都使用一樣的時序模型來描述行爲，於是這兩個領域即將可能再度統一爲一個領域。

    鑑於大多數嵌入式系統都是實時的反應式系統，反應式系統具備多任務併發、時間約束嚴格與可靠性高的特色，針對反應式系統的設計和描述，人們相繼提出了多種描述語言和驗證方法學。例如，採用時序邏輯用來刻畫反應式系統的性質及推理反應式系統的行爲，採用模型檢驗技術驗證反應式系統設計的正確性等，這些技術已逐步在嵌入式開發過程當中發揮着重要的做用。

 

4 嵌入式開發設計環境

    嵌入式系統的開發環境種類不少，大致能夠把它們分爲以下幾類：

    （1）與嵌入式操做系統配套的開發環境，屬於這一類的開發環境較多，如 PalmOS、THOS、VxWorks、Windows CE 等商業嵌入式操做系統都有與其配套的功能齊全的開發環境。

    （2）與處理器芯片配套的開發環境。這類開發環境通常由處理器廠商提供，如EPSON公司推出的一個專門爲基於 S1C33 系列微控制器芯片的嵌入式系統開發的工具包即是這一類型的開發環境。

    （3）與具體應用平臺配套的開發環境。這類開發環境針對性較強，如高通公司的 Brew SDK 等。

    （4）其餘類的開發環境。這類開發環境主要指一些嵌入式系統供應商在 GNU 開源工具的基礎上開發或定製的較爲通用的開發環境。這類工具能夠免費得到，並且支持的處理器類型繁多，功能齊全，但在技術支持方面比專業化商業工具略遜一些。

 

5 嵌入式軟件設計模型

    隨着嵌入式系統的功能日益複雜，要描述這些功能複雜的系統的行爲也愈來愈困難，實踐證實經過採用計算模型的方法來對系統進行描述和分析是一種具備工程價值的方法。

    本節介紹幾種嵌入式領域經常使用的計算模型，並從計算模型的角度分析和闡述嵌入式應用設計和開發的相關問題。計算模型提供一組用簡單對象來組合複雜行爲的方法，能夠幫助設計者理解和描述系統行爲。嵌入式系統經常使用的計算模型有以下幾種：時序計算模型、通訊進程模型、狀態機模型、數據流模型、面向對象模型、併發進程模型。

    這些模型分別在不一樣的應用領域使用，如狀態機模型特別適合描述以控制爲主的系統，數據流模型能夠很好地描述數據處理和轉換問題。目前使用最普遍的是併發進程模型。

    1．狀態機模型

    有限狀態機（Finite-State Machine，FSM）是一個基本的狀態模型，能夠用一組可能的狀態來描述系統的行爲，系統在任什麼時候刻只能處於其中一個狀態，也能夠描述由輸入肯定的狀態轉移，最後能夠描述在某個狀態下或狀態轉移期間可能發生的操做。

   有限狀態機 FSM 是一個六元組 F<S，I，O，F，H，S0>，其中 S 是一個狀態集合{s0， s1，…，sl}，I 是輸入集合{I0，I1，…，Im}，O 是輸出集合{o0，o1，…，on}，F 是次態函數或轉移函數，將狀態和輸入映射到狀態(S×I→S)，H 是輸出函數，將狀態映射到輸出 (S→O)，S0 是初始狀態。

   圖 12-12 是電梯的控制單元的狀態機描述。在初始「空閒」態，將 up 和 down 設置爲 0，open 設置爲 1。在所請求的樓層不一樣於當前樓層以前，狀態機一直停留在「空閒」狀態。若是所請求的樓層大於當前樓層，則狀態機轉移到「上升」狀態，並將 up 設置爲 1。若是所請求的樓層小於當前樓層，則狀態機轉移到「降低」狀態，並將 down 設置爲 1。在當前樓層等於所請求的樓層以前，狀態機一直留在「降低」或「上升」狀態，而後狀態轉移到「開門」狀態，並將 open 設置爲1。一般，系統有一個計時器 timer，所以，當狀態機轉移到「開門」狀態時，還要將計時器啓動，狀態機停留在「開門」態，直到計時器超時，最後轉移到「空閒」態。

 

    當 FSM 被用於嵌入式系統設計時，其輸入和輸出的數據類型都是布爾類型，而函數表示含有布爾運算的布爾函數，這種模型對於沒有數據輸入或輸出的不少純控制系統而言已經足夠。若是要處理數據，則將 FSM 擴展爲帶有數據路徑的狀態機（FSM with Datapath， FSMD）。另外，對狀態機模型能夠進一步擴展以支持分級和併發，這種模型稱爲分級/併發FSM（Hierarchical/Concurrent FSM，HCFSM）模型。

    2．數據流模型

    數據流模型是併發多任務模型派生出的一種模型，該模型將系統的行爲描述爲一組結點和邊，其中結點表示變換，邊表示從一個結點到另外一個結點的數據流向。每一個結點使用來自其輸入邊的數據，執行變換並在其輸出邊上產生數據。

    每條邊可能有或沒有數據，出如今邊上的數據稱爲令牌，當某個結點的全部輸入邊都至少有一個令牌時，該結點可觸發。結點觸發後，將使用來自每條輸入邊的一個令牌，對全部使用的令牌進行數據變換，並在輸出邊上產生一個令牌，結點的觸發僅決定於令牌出現的狀況。

    圖 12-13 所示是計算 z=(a+b)×(c-d)的數據流模型。

    目前，已有若干商業化的工具支持用圖形化語言表達數據流模型，這些工具能夠自動將數據流模型轉換爲併發多任務模型，以便在微處理器上實現。其轉換方法爲將每一個結點轉換爲一個任務，每條邊轉換爲一個通道，其中併發多任務模型的實現方法是使用實時操做系統對併發任務進行映射。

    圖 12-14 是一個同步數據流模型，這個模型中，在結點的每條輸入邊和輸出邊上分別標註每次觸發所使用和產生的令牌數。該模型的優勢是，在實現時不須要將其轉換爲併發多任務模型，而是用靜態方式調度結點，產生時序程序模型。該模型可使用時序程序語言（如 C 語言）來表達，不須要實時操做系統就能夠執行，所以其執行效率更高。

 

    3.併發進程模型

   併發進程模型是由一組進程構成，每一個進程是一個順序執行的過程，各進程間能夠併發執行。併發進程模型提供建立、終止、暫停、恢復和鏈接進程的操做。進程在執行中能夠相互通訊，交換數據。進程間通訊能夠採用兩種方式：共享變量和消息傳遞。信號量、臨界區、管程和路徑表達式等用來對併發進程的操做進行同步。

    一般，實時系統能夠當作是由許多併發執行的進程構成的系統，其中每一個進程都有時間要求。這樣，不少嵌入式系統更容易用一組併發執行的任務來描述，由於這些系統自己就是多任務系統，併發進程模型便天然地能夠由實時操做系統的多任務來實現。

    4．面向對象模型

    傳統的併發進程模型是圍繞進程的概念進行設計的，進程是一個實現級的概念，它是對客觀世界活動的一種間接模擬，所以，採用進程模型來解決客觀世界中的併發問題就顯得極不天然，而且也使得併發程序難以設計和理解。

    面向對象模型以一種更加直接的方式刻畫客觀世界中的活動，模型中存在着潛在的併發執行能力。一個對象向另外一個對象發送消息後，若不須要或不當即須要消息的處理結果，前者沒必要等待後者處理消息，消息發送者和消息接受者能夠併發執行。對象不都是處於被動的提供服務狀態，它們中的一些除了能經過接收消息向外提供服務外，還能夠有本身的事務處理。一個對象每每能夠同時處理多個消息。

   對象是數據和操做的封裝體，數據存放在對象的局部變量中，對象的狀態由對象全部的局部變量在某一時刻的取值來表示。在併發環境中，還要考慮對象併發狀態的描述問題，由於對象的併發控制是根據對象的併發狀態來進行的。

   把併發與面向對象相結合，歸結起來可分爲兩條途徑：

    （1）在面向對象模型中引進併發機制，充分利用面向對象技術刻畫客觀世界的良好模型能力和麪向對象的各個重要特性，同時把其潛在的併發能力描述出來，使其適合於描述併發計算。

    （2）在傳統併發模型中引進面向對象思想。

    面向對象的併發模型能夠分爲兩種類型：隱式併發模型和顯式併發模型。

    （1）隱式併發模型。這種模型的特色是推遲併發設計，將對象建模做爲建模基礎。在進入運行階段以前，將對象當作自主單元，各類對象的活動當作理想併發方式完成的特定工做。就像每一個對象擁有一個本身的處理器，這個處理器能夠爲對象提供一個執行線程。進入系統的外部事件被當作一個處理請求，以廣播方式傳給一些對象，這些對象接着向其餘對象進一步提出處理請求。理論上，對應一個請求，能夠有任意多個對象執行相應的處理。在實現時，由調度程序最終決定其對象的操做順序，如圖 12-15 所示。

   （2）顯式併發模型。這種模型的特色是首先考慮併發，應先把併發概念和對象概念分開。在創建對象之後，用實時操做系統支持的進程概念來表示併發，造成對象和進程兩個抽象層次，即先將系統分解爲準併發進程做爲開始，而在每一個進程的內部採用面嚮對象的技術。對象間交互表示成嵌套的函數調用，經過加入鎖、監視器、信號量等顯式同步機制，來保證對象的完整。該模型將進程置於對象之上，對象中沒必要考慮併發、對象串行化，如圖 12-16 所示。

 

 

    早期，實時系統的設計方法主要是結構化設計方法，採用結構化方法的系統在複用性、可修改性等方面有很大的侷限性。面向對象的實時系統設計方法顯然在這些問題上具備明顯的優點。較實用的面向對象的設計方法是諾基亞公司的 OCTOPUS 方法，該方法以 OMT 和融合方法（Fusion Method）爲基礎，提出了對實時系統響應時間、時間域及併發的處理方法，並具體提出了對併發、同步、通訊、中斷處理、ASIC、硬件界面、端對端響應時間等方面的處理。OCTOPUS 方法將軟件開發的主要階段很好地合併起來，從規格說明到運行模型之間的過渡緊密天然，還支持漸進式開發。OCTOPUS 方法是當前面向對象技術和實時系統相結合的一個典型的設計方法。另外，形式化的面向對象的開發技術和建模語言也逐漸在實時系統建模的初始階段獲得應用。

6 需求分析 

    在設計以前，設計者必須知道要設計什麼。一般人們用需求和規格說明來描述設計過程的這兩個相關而不一樣的步驟。需求是用戶所想要的非形式化的描述，而規格說明是能夠用來建立系統架構的更詳盡、更精確、更一致的描述。固然，需求和規格說明都是指導系統的外部表示，而非內部表示。需求有兩種類型：功能性需求和非功能性需求，功能性需求說明這個系統必須作什麼，而非功能性需求說明系統的其餘屬性，如物理尺寸、價格、功耗、設計時間、可靠性等。

    對一個大系統進行需求分析是一項複雜而費時的工做，可是，獲取少許格式清晰、簡單明瞭的信息是理解系統需求的一個良好開端。表 12-5 是在某項工程開始時填寫的需求表 格，在考慮系統的基本特徵時可將該表格做爲檢查表。

    這份需求表格內容是以 GPS（Global Position System，移動地圖系統）爲例編寫的。移動地圖系統是一種手持設備，針對在高速公路開車的用戶或相似的用戶而設計，該設備可從 GPS 上獲得位置信息，爲用戶顯示當前所在的位置及周圍的地形圖，地圖的內容隨着用戶及設備所在位置的改變而改變。

    需求分析階段最重要的文檔輸出就是系統的規格說明。

    規格說明是精確反映客戶需求而且做爲設計時必須遵循的要求的一種技術文檔。在軟件開發的過程當中，規格說明很是重要。系統分析人員接受用戶需求產生目標軟件系統的規格說明，設計與編碼人員根據規格說明，進行模塊設計並最終產生程序代碼，測試和驗收人員驗證最終軟件是否符合規格說明。規格說明應該是清晰的、無歧義的，不然由該規格說明建造系統可能不符合實際要求。

   目前，業界較爲流行的方法是採用 UML 進行規格說明的描述。UML 是一個通用的標準建模語言，能夠對任何具備靜態結構和動態行爲的系統進行建模。UML 適用於系統開發過程當中從需求規格描述到系統完成後測試的不一樣階段。

    圖 12-17 是一個顯示操做的狀態機規格說明示例，開始和結束是特殊的狀態，狀態機中的狀態表明瞭不一樣的概念性操做。

    在需求分析階段，經過用例來捕獲用戶需求。經過用例建模，描述對系統感興趣的外部角色及其對系統（用例）的功能要求。分析階段主要關心問題域中的主要概念（如抽象、類和對象等）和機制，須要識別這些類及它們相互間的關係，並用 UML 類圖來描述。在分析階段，只對問題域的對象（現實世界的概念）建模，而不考慮定義軟件系統中技術細節的類（如處理用戶接口、數據庫、通訊和並行性等問題的類）。

7 系統設計

    目前，嵌入式系統的設計工具能夠分爲兩類：協同合成工具和協同模擬工具。

    （1）協同合成工具。當前，用於嵌入式開發的主要的協同合成工具備 POLIS、COSYMA和Chinook 等。

• POLIS：POLIS 是 UC-Berkeley 開發的交互式嵌入式系統的軟、硬件協同設計框架，它適用於小型控制系統的設計，系統描述支持基於 FSM（Finite State Machine）的語言。因爲軟、硬件都可透明地從同一 CFSM 描述中取得，設計空間的靈活性也相應增長，支持使用 PTOLEMY 的協同模擬，在描述及實現層均支持正式的驗證，架構的支持受限，即硬件 CFSMs 所包圍的只有一個處理器，並且不支持共享內存。

• COSYMA：COSYMA 是由德國 IDA 公司開發的一種探索硬件與軟件協同設計合成進程的平臺，它面向軟件系統的描述較簡單，支持自動分割和協同處理器合成，在合成時期能夠對設計空間進行探索，系統合成取決於硬件限制，不支持併發模塊，即一次只能有一個線程執行，架構一樣受限，不支持正式驗證，設計的成功與否取決於分割及開銷估計技術。

• Chinook：Chinook 是爲控制系統而設計的，整個系統的描述做爲一個輸入提供給 Chinook，它的內部模式基於相似等級狀態的模式，它不對代碼進行分割，它爲整個設計提供單一的模擬環境，Chinook 支持多種系統架構，尤爲是多處理器結構。一樣支持定時限制的描述，它能合成多種接口，包括系統之間的軟、硬件接口，能直接從定時圖表中合成設備驅動器，能夠控制處理器之間的通訊。

    （2）協同模擬工具。協同模擬是嵌入式系統設計中相當重要的一個方面，在整個系統設計完成後，在統一框架下模擬不一樣種類的成分是必要的，協同模擬不只提供檢驗，並且爲用戶提供各系統的性能信息，這有助於在系統的早期提出變動方案，不至於形成重大損失。目前，主要的協同模擬工具備以下兩種。

• PTOLEMY：PTOLEMY 的關鍵思想是混合使用面向對象內核的計算模型，可用於模擬多種的系統，在各類應用中被普遍地使用，但不適合於系統合成，硬件模擬也是它的一項功能。

• TSS：TSS（Tool for System Simulation）是模擬複雜硬件的工具，採用 C 語言編寫，單個模塊的提取可由用戶控制，能夠方便地進行添加與刪除模塊。但不支持分級模塊，沒有用於同步各處理器存取共享數據結構的機制，模塊間的通訊經過端口和總線進行。而且，TSS 支持多核系統的模擬。

    1．系統架構設計

    描述系統如何實現規格說明中定義的功能是系統架構設計的主要目的。可是在設計嵌入式系統的系統結構時，很難將軟件和硬件徹底分開。一般的處理是先考慮系統的軟件架構，而後再考慮其硬件實現。系統結構的描述必須符合功能上和非功能上的需求。不只所要求的功能要體現，並且成本、速度、功耗等非功能約束也要知足。從系統原始框圖中的功能元素開始逐個考慮和細化，把原始框圖轉化爲軟件和硬件系統結構的同時考慮非功能約束，是一個切實可行的方法。下面以 GPS 移動地圖系統的架構設計爲例進行說明。

    （1）原始框圖。如圖 12-18 所示，這個原始框圖是移動地圖系統的主要操做和數據流。

 

 

    （2）軟件系統架構。如圖 12-19 所示，軟件系統主要由用戶界面、數據庫搜索引擎和數據轉換器組成。

    （3）硬件系統架構。如圖 12-20 所示，硬件系統採用通用微處理器、存儲器和 I/O 設備組成。本系統選用兩種存儲器：通用數據、程序存儲器和針對像素顯示的幀緩衝存儲器。

    2．硬件子系統設計

    嵌入式系統的開發環境由 4 部分組成：目標硬件平臺、嵌入式操做系統、編程語言和開發工具，其中處理器和操做系統的選擇應當考慮更多的因素，避免錯誤的決策影響項目的進度。

    （1）選擇處理器技術。嵌入式系統設計的主要挑戰是如何使互相競爭的設計指標同時達到最佳化。設計者必須對各類處理器技術和 IC 技術的優缺點加以取捨。通常而言，處理器技術與 IC 技術無關，也就是說，任何處理器技術均可以使用任何 IC 技術來實現，可是最終器件的性能、NRE 成本、功耗、大小等指標會有很大的差別，如圖 12-21 所示。

    更通用的可編程技術提供了較大的靈活性，下降了 NRE 成本，創建產品樣機與上市的時間較快。定製的技術可以提供較低的功耗、較好的性能、更小的體積和大批量生產時的低成本。

    一般，一個公司要推出一種產品，如機頂盒、家庭路由器或通用處理器等，能夠先推出半定製產品，以儘快佔領市場，而後再推出全定製的產品。也可先用較可靠的老技術實現處理器，再用新制程的技術實現下一代。一樣，嵌入式系統的設計者可使用可編程的器件來創建樣機，以加速上市時間，批量時再採用定製器件。

    根據這些原則，設計者即可以對採用的處理器技術和處理器作出合理選擇。通常，全定製商品化的「通用處理器軟件」是大多數狀況下都適用的一個選擇。

    （2）通用嵌入式處理器的選擇。根據用戶的需求和項目的須要選擇合適的通用嵌入式處理器，選擇時須要考慮以下指標。

• 處理器的速度。一個處理器的性能取決於多個方面的因素：時鐘頻率，內部寄存器的大小，指令是否對等處理全部的寄存器等。對於許多需用處理器的嵌入式系統設計來講，目標不是在於挑選速度最快的處理器，而是在於選取可以完成做業的處理器和 I/O 子系統。處理器的性能知足系統的需求，並有必定的餘量，但也沒必要選得過高。

• 技術指標。當前，許多嵌入式處理器都集成了外圍設備的功能，從而減小了芯片的數量，進而下降了整個系統的開發費用。開發人員首先考慮的是，系統所要求的一些硬件可否無須過多的組合邏輯就能夠鏈接處處理器上。其次是考慮該處理器的一些支持芯片，如 DMA 控制器、內存管理器、中斷控制器、串行設備、時鐘等的配套。

• 開發人員對處理器的熟悉程度，即項目的開發人員須要在處理器自己的成本和開發成本之間作一個權衡。

• 處理器的 I/O 功能是否知足系統的需求，即許多處理器提供內置的外部設備，以減小芯片數量、下降成本，應儘可能考慮這種方案。

• 處理器的相關軟件支持工具，即該款處理器是否具備完善的嵌入式操做系統、編程語言和開發工具的支持等。

• 處理器的調試，即處理器是否集成了調試功能，如是否支持 JTAG、BDM 等調試方式。

• 處理器製造商的支持可信度。在產品的生命週期裏選擇某種處理器時，設計者必須確認它有足夠的供貨量、技術支持等處理器的低功耗。

    嵌入式微處理器最大而且增加最快的市場是手持設備、電子記事本、PDA、手機、GPS 導航器、智能家電等消費類電子產品，這些產品中選購的微處理器的典型特色是要求高性能、低功耗。許多 CPU 生產廠家已經進入了這個領域。

    （3）硬件設計的注意事項。首先，將硬件劃分爲部件或模塊，並繪製部件或模塊鏈接框圖。其次，對每一個模塊進行細化，把系統分紅更多個可管理的小塊，能夠被單獨實現。一般，系統的某些功能既可用軟件實現也可用硬件實現，沒有一個統一的方法指導設計者決定功能的軟硬件分配，可是能夠根據約束清單，在性能和成本之間進行權衡。

    設計軟、硬件之間的接口時，須要硬件設計者和軟件設計者協同工做才能完成，良好的接口設計能夠保證硬件簡潔、易於編程。

   設計時須要注意如下幾點。

• I/O 端口：列出硬件的全部端口、端口地址、端口屬性、使用的命令和序列的意義、端口的狀態及意義。

• 硬件寄存器：對每一個寄存器設計寄存器的地址、寄存器的位地址和每一個位表示的意義，以及對寄存器讀寫的說明、使用該寄存器的要求和時序說明。

• 內存映射：共享內存和內存映射 I/O 的地址，對每一個內存映射，說明每一個 I/O 操做的讀/寫序列、地址分配。

• 硬件中斷：如何使用硬件中斷，列出所使用的硬件中斷號和分配的硬件事件。

• 存儲器空間分配：列出系統中程序和數據佔用的空間大小、位置，以及存儲器類型和訪問方式等。

    總之，硬件設計者應該給軟件設計者更多、更詳細的信息，以便於進行軟件設計和開發。

    3．軟件子系統設計

    根據需求分析階段的規格說明文檔，肯定系統計算模型，對軟件部分進行合理的設計便可。

    （1）操做系統的選擇。在選擇嵌入式操做系統時，須要作多方面的考慮：

• 操做系統的功能。根據項目須要的操做系統功能來選擇操做系統產品，要考慮系統是否支持操做系統的所有功能或部分功能，是否支持文件系統、人機界面，是實時系統仍是分時系統及系統是否可裁減等因素。

• 配套開發工具的選擇。有些實時操做系統（rtos）只支持該系統供應商的開發工具。也就是說，還必須向操做系統供應商獲取編譯器、調試器等。有些操做系統使用普遍且有第三方工具可用，所以，選擇的餘地比較大。

• 操做系統的移植難易程度。操做系統到硬件的移植是一個重要的問題。它是關係到整個系統可否定期完工的一個關鍵因素，所以要選擇那些可移植性程度高的操做系統，從而避免操做系統難以向硬件移植而帶來的種種困難，加速系統的開發進度。

• 操做系統的內存需求如何。均衡考慮是否須要額外 ram 或 eeprom 來迎合操做系統對內存的較大要求。有些操做系統對內存的要求是與目標相關的。如 tornado/vxworks，開發人員能按照應用需求分配所需的資源，而不是爲操做系統分配資源。從須要幾 k 字節存儲區的嵌入設計到需求更多的操做系統功能的複雜的高端實時應用，開發人員可任意選擇多達 80 種不一樣的配置。

• 操做系統附加軟件包。是否包含所需的軟件部件，如網絡協議棧、文件系統、各類經常使用外設的驅動等。

• 操做系統的實時性如何。實時性分爲軟實時和硬實時。有些嵌入式操做系統只能提供軟實時性能，如 microsoft windows ce 2.0 是 32 位，windows 兼容，微內核，可伸縮實時操做系統，能夠知足大部分嵌入式和非嵌入式應用的須要。但實時性不夠強，屬於軟實時嵌入式操做系統。

• 操做系統的靈活性如何。操做系統是否具備可剪裁性，即可否根據實際須要進行系統功能的剪裁。有些操做系統具備較強的可剪裁性，如嵌入式 linux 、 tornado/vxworks 等。

    （2）編程語言的選擇。在選擇編程語言時，也須要作多方面的考慮：

• 通用性。隨着微處理器技術的不斷髮展，其功能愈來愈專用，種類愈來愈多，但不一樣種類的微處理器都有本身專用的彙編語言。這就爲系統開發者設置了一個巨大的障礙，使得系統編程更加困難，軟件重用沒法實現，而高級語言通常和具體機器的硬件結構聯繫較少，比較流行的高級語言對多數微處理器都有良好的支持，通用性較好。

• 可移植性。因爲彙編語言和具體的微處理器密切相關，爲某個微處理器設計的程序不能直接移植到另外一個不一樣種類的微處理器上使用，所以，移植性差。高級語言對全部微處理器都是通用的，所以，程序能夠在不一樣的微處理器上運行，可移植性較好。這是實現軟件重用的基礎。

• 執行效率。通常來講，越是高級的語言，其編譯器和開銷就越大，應用程序也就越大、越慢。但單純依靠低級語言，如彙編語言來進行應用程序的開發，帶來的問題是編程複雜、開發週期長。所以，存在一個開發時間和運行性能之間的權衡。

• 可維護性。低級語言如彙編語言，可維護性不高。高級語言程序每每是模塊化設計，各個模塊之間的接口是固定的。所以，當系統出現問題時，能夠很快地將問題定位到某個模塊內，並儘快獲得解決。另外，模塊化設計也便於系統功能的擴充和升級。

• 基本性能。在嵌入式系統開發過程當中使用的語言種類不少，比較普遍應用的高級語言有 Ada、C/C++、Modula-2 和 Java 等。Ada 語言定義嚴格，易讀易懂，有較豐富的庫程序支持，目前，在國防、航空、航天等相關領域應用比較普遍，將來仍將在這些領域佔有重要地位。C 語言具備普遍的庫程序支持，是嵌入式系統中應用最普遍的編程語言，在未來很長一段時間內仍將在嵌入式系統應用領域中佔重要地位。 C++是一種面向對象的編程語言，在嵌入式系統設計中也獲得了普遍的應用，如 GNU C++。Visual C++是一種集成開發環境，支持可視化編程，普遍應用於 GUI 程序開發。但 C 與 C++相比，C++的目標代碼每每比較龐大和複雜，在嵌入式系統應用中應充分考慮這一因素。

    （3）軟件開發過程。嵌入式軟件的開發過程不一樣於通常通用軟件的開發過程，主要有以下步驟：

• 選擇開發語言，創建交叉開發環境；

• 根據詳細設計說明編寫源代碼，進行交叉編譯、連接；

• 目標代碼的重定位和下載；

• 在宿主機或目標機調試、驗證軟件功能；

• 進行代碼的優化。

    （4）軟件開發文檔。在嵌入式產品的開發設計過程當中，開發階段完成系統產品的實現，這一階段同時須要完成一系列的文檔，這些文檔對完成產品設計、維護至關重要，這些文檔分別爲技術文件目錄、技術任務書、技術方案報告、產品規格、技術條件、設計說明書、試驗報告、總結報告等。

 

8 系統集成與測試

    一般嵌入式系統測試主要包括軟件測試、硬件測試、單元測試三個部分。

    通常系統的硬件測試包括可靠性測試和電磁兼容性測試，關於電磁兼容性目前已經有了強制性國內和國際標準。

    嵌入式系統軟件測試方法和原理跟通用軟件的測試基本一致，軟件測試時，通常須要測試實例或測試序列，序列有兩種來源：一種是須要用戶進行設計，另外一種是標準的測試序列。不管哪一種測試實例，都要求實例可以高几率發現更多的錯誤，但在測試的內容上有些差異：

    （1）嵌入式軟件必須長時間穩定運行。

    （2）嵌入式軟件通常不會頻繁地版本升級。

    （3）嵌入式軟件一般使用在關鍵性的應用中。

    （4）嵌入式軟件必須和嵌入式硬件一塊兒對產品的故障和可靠性負責。

    （5）現實世界的條件是異步和不可預測的，使得模擬測試很是困難。

    因爲這些差異，使得嵌入式系統軟件測試主要集中在如下 4 個不一樣的方面：

    （1）由於實時性和同時性很難同時知足，因此大多數測試集中於實時測試。

    （2）大多數實時系統都有資源約束，所以須要更多的性能和可用性測試。

    （3）可使用專用實時跟蹤工具對代碼覆蓋率進行測試。

    （4）對可靠性的測試級別比通用軟件要高得多。

    另外，性能測試也是設計嵌入式系統中須要完成的最主要的測試活動之一，對嵌入式系統有決定性的影響。

    因爲嵌入式系統的專用性特色，系統的硬件平臺和軟件平臺多種多樣，每種都針對不一樣的應用而專門設計，所以，應用軟件在各個平臺之間不多具備通用性，而且嵌入式系統的更新換代速度相對較快。爲了保護已有的投資、充分利用現有的軟件資源和加快產品研製速度，軟件的移植在嵌入式領域變得很是頻繁。