嵌入式系統開發 3 - 如何設計更靈活的嵌入式系統架構

2024/08/19閱讀時間約 3 分鐘

系統設計的挑戰

嵌入式系統的設計猶如解開一個拼圖，即使是小型的系統也充滿了細節，讓人眼花繚亂。作為開發者，你需要具備全局視野，才能辨識哪些部分的問題能夠用簡單的方法解決，哪些部分則潛藏著複雜的相依性。這時，設計的關鍵在於：不要追求一開始就完美，而是從一個「還可以」的設計開始，然後逐步改進。

為此，系統架構圖就是一個不可或缺的工具，它能幫助你視覺化整個系統並為軟體設計鋪路，或者至少能幫助你理解手上的那堆代碼。

產品定義的迭代過程

在項目啟動初期，產品的定義通常是不穩定的。你可能會經歷多次的反覆討論，反覆修正需求和設計。

在這個階段，你會將功能草圖畫在白板上，這樣可以更好地進行軟體架構設計。與此同時，硬體工程師們也在進行類似的工作，儘管他們的焦點可能有所不同，但理想狀況下他們會和你密切合作。在經過一段時間的迭代後，你會手握一個初步的軟體架構以及硬體草圖。尤其是在你經驗尚淺的時候，很多設計項目都可能是基於現有的平台，只做少量的修改。

這樣的迭代是開發過程中不可避免的一部分，尤其是在嵌入式系統中，軟體和硬體的互動密切，任何一方的改動都可能帶來連鎖反應。因此，及早確定雙方的需求和功能，才能讓產品順利進行。

從系統視角設計更好的嵌入式軟體

設計嵌入式系統的其中一個目標是：透過不同的視角來更好地理解整個系統，進而設計出更靈活的軟體。此時，繪製一些系統圖表會大有幫助，這些圖表能讓你具象化系統的模樣，並幫助你識別軟體的架構需求。無論是封裝、資訊隱藏，還是模組之間的良好介面，這些都是在面對變更需求和硬體限制時，設計良好系統的關鍵。

硬體穩定性的關鍵性

嵌入式系統強烈依賴硬體。如果硬體不穩定，那麼軟體的表現也會像是充滿錯誤且不可靠。因此，最早的設計工作應該集中在確保硬體的穩定性。這不僅有助於提高系統的可靠性，還能幫助你分離硬體變更和軟體錯誤，確保系統能夠更好地應對未來的挑戰。

許多開發者傾向於從系統功能出發，確定支持這些功能所需的硬體規格。這種方法當然沒有錯，甚至在某些情況下是更好的選擇。不過，我這裡更傾向於從低階硬體開始設計，這樣可以加強你對於硬體穩定性的重要認識。

抽象硬體設計的必要性

當你選擇由下而上的設計方法時，需記住你所設計的硬體只是一種代表性的設計。儘管最終你需要深入了解硬體的具體細節，但在設計初期，你可以先假定總有某個硬體符合你的需求（比如，有某個處理器能夠完成所有任務）。這種抽象設計能讓你快速確立系統、軟體和硬體的架構，然後再深入探討細節。

針對嵌入式系統架構的硬體抽象設計，有以下一些常見的設計原則：

模組化設計：
- 硬體抽象應該以模組化方式設計，讓每個模組負責特定的硬體功能，如 I/O、計時器、通訊等。這樣可以讓系統在修改或更新硬體時只需要改動具體的模組，而不影響整體架構。
抽象硬體接口（Hardware Abstraction Layer, HAL）：
- HAL 提供與硬體無關的接口，屏蔽底層硬體的細節，使軟體層與硬體層解耦。這能促進代碼的可重用性與可維護性，並且方便不同硬體平台的切換。
平台獨立性：
- 抽象應該考慮平台的獨立性。當設計嵌入式系統時，不應過早依賴某一特定硬體。這意味著代碼可以運行在不同硬體平台上，這增加了系統的可移植性。
分層設計：
- 系統應分層設計，其中底層處理硬體細節，中層處理具體功能，上層負責應用邏輯。這使得硬體變更或升級時，只需修改低層而不影響應用層。
事件驅動設計：
- 使用事件驅動模型可以將硬體操作轉化為抽象事件。這樣可以在不同硬體上進行事件觸發和響應，而不需要考慮具體硬體操作。
可配置性：
- 設計時應考慮硬體抽象的可配置性，使系統能根據不同的硬體選項或外圍設備進行調整而無需修改主要邏輯。
一致的錯誤處理機制：
- 不同硬體的錯誤可能千變萬化，抽象層應提供一致的錯誤處理機制，讓上層系統能夠以相同方式處理錯誤。

抽象設計的優點在於，它能讓你專注於整體架構，而不會過早陷入細枝末節。這種方法的靈活性也能幫助你在日後的開發過程中更加游刃有餘，能應對硬體或需求的變更。

總結

嵌入式系統的設計是一個充滿挑戰的過程，它不僅需要你具備對整個系統的深刻理解，還要求你具備靈活應對變化的能力。透過系統視角的圖表，你能更好地組織設計想法，並識別潛在的問題區域。記住，設計從來不是一蹴而就的，而是逐步迭代的過程。在這個過程中，抽象硬體設計、專注硬體穩定性，以及靈活應對變化，都是設計嵌入式系統的關鍵。