如果你曾經開發過嵌入式軟件，你就會知道典型的嵌入式構建系統只有兩種構建配置：調試和發布。事實上，你可能大部分時間都只使用調試構建。Rust構建系統在測試中走得更遠。但是，你知道有五種基本的構建配置應該使用嗎?讓我們探討一下你和你的嵌入式開發團隊可以使用的不同嵌入式構建系統配置，以確保你更快地開發軟件。
構建系統配置1—分析
我們要討論的第一個嵌入式構建系統配置是分析構建。開發高質量的嵌入式軟件需要你審查和分析你的軟件。你應該問這樣的問題：
l我的函數的圈復雜度是多少?
l我的代碼的耦合性是什么?
l我的任務是否以正確的速度執行?
l我最差的CPU負載是多少?
l我是否通過了正確性和編碼標準的靜態代碼分析測試?
許多構建時檢查可以在代碼上執行，通常委托給手工評審或者推給CI/CD。通常，在提交代碼之前，我會運行我的分析構建。構建將運行我所有的靜態、動態和度量檢查，以確保我的代碼處于提交到DevOps系統的正確狀態。
構建系統配置2—模擬
模擬應用程序代碼是開發嵌入式軟件最沒有得到充分利用的技術。你的構建系統應該具有允許你在你的主機環境上構建模擬軟件的配置。你不一定需要一個目標模擬器;你可以通過在主機上運行應用程序代碼來驗證它。模擬有很多優點，例如：
l提高了時間效率——你不必等待硬件的到來，無需franken-boards，并且消除了bug-flash-debug循環。
l靈活性和可擴展性–你必須使用硬件抽象層(HALs)分離代碼并提高可重用性。
l降低開發成本–在主機環境中調試和解決問題的速度比在嵌入式目標上更快。
嵌入式開發人員通常認為他們不能模擬他們的軟件，因為它接觸到了硬件。然而，精心制作的軟件架構可以實現模擬和目標執行。此外，像DevOps的CI/CD技術這樣的現代技術迫使許多團隊重新思考他們如何設計他們的軟件來更好地管理他們的硬件依賴。所以如果你追求DevOps，增加一個模擬構建是很自然的擴展。
構建系統配置3—測試
如果你一直致力于現代化你的嵌入式軟件過程，那么你可能已經遇到或創建了你的測試構建配置。測試配置是關于運行單元測試、集成測試，甚至可能是系統級測試(盡管我通常把它推到CI/CD過程中)。
當你創建一個測試構建配置時，你將集成一個運行該構建的測試工具。測試工具通常為你的主機編譯，而不是為你的目標編譯，但是這取決于你的需要。與模擬一樣，你需要一個良好的HAL和解耦來在主機上測試你的應用程序代碼。不過，要小心;單元測試不是模擬。模擬就是在主機上運行代碼，就像在目標上一樣。單元測試是關于運行單獨的受控測試，以確保單個模塊按預期工作。
構建系統配置5—調試
調試配置是你久經考驗的嵌入式構建系統配置。如果你在一個工程部門的地板上走來走去，你經常會發現嵌入式開發人員愉快地單步調試他們的軟件代碼。不幸的是，這可能是一個嵌入式開發人員在大多數時候所能做的最糟糕的事情(有時，這種調試時間是必要的)。
調試版本通常在映像中包含更多的信息，因此開發人員可以四處查看并進行調試。問題是大多數應用程序代碼可以在主機上調試得更好。調試構建通常會降低開發人員的速度，并鼓勵糟糕的調試實踐。它們對于驅動開發來說是不可避免的，但是大多數團隊都在使用他們芯片供應商的驅動代碼，所以使用一個好的HAL，你就可以模擬或者測試你的bug。
嵌入式構建系統結論
調試構建配置并不是嵌入式軟件團隊唯一可用的配置。事實上，希望你已經意識到，分析、測試和模擬構建配置的使用可能更有價值和效率。訣竅是將嵌入式軟件和固件僅僅視為軟件。與在嵌入式開發目標上相比，在MacOS、Linux或Windows上測試適當分層、分離和抽象的應用程序代碼更容易。希望你仔細考慮這些構建配置，并制定一個行動計劃，開始將它們集成到你的構建過程中。
京公網安備 11010802030320號