嵌入式軟件與嵌入式系統是密不可分的，嵌入式系統一般由嵌入式微處理器、外圍硬件設備、嵌入式操作系統等部分組成。為增進大家對嵌入式軟件的認識，本文將對嵌入式軟件的發(fā)展以及分析嵌入式軟件問題的方法予以介紹。如果你對嵌入式軟件具有興趣，不妨繼續(xù)往下閱讀哦。

一、嵌入式軟件的發(fā)展

第一階段：早期的嵌入式系統設計方法，通常是采用“硬件優(yōu)先”原則。即在只粗略估計軟件任務需求的情況下，首先進行硬件設計與實現。然后，在此硬件平臺之上，再進行軟件設計。因而很難達到充分利用硬件軟件資源，取得最佳性能的效果。同時，一旦在測試時發(fā)現問題，需要對設計進行修改時，整個設計流程將重新進行，對成本和設計周期的影響很大。這種傳統的設計方法只能改善硬件/軟件各自的性能，在有限的設計空間不可能對系統做出較好的性能綜合優(yōu)化，在很大程度上依賴于設計者的經驗和反復實驗。

第二階段：90年代以來隨著電子系統功能的日益強大和微型化，系統設計所涉及的問題越來越多，難度也越來越大。同時硬件和軟件也不再是截然分開的兩個概念，而是緊密結合、相互影響的。因而出現了軟硬件協同（codesign）設計方法，即使用統一的方法和工具對軟硬件，協同設計軟硬件體系結構，以最大限度地挖掘系統軟硬件能力，避免由于獨立設計軟硬件體系結構而帶來的種種弊病，得到高性能低代價的優(yōu)化設計方案。

二、如何分析嵌入式軟件的問題

1、分析日志文件

從log中尋找異常提示，是應對不可重復性、偶發(fā)性故障最基本的手段。在系統某處發(fā)生異常時，一定會在log中留下蛛絲馬跡，可以請客戶協助提供串口日志，在log文件中查找問題?；蛘咴O備自己內部記錄log，但嵌入式設備由于存儲空間的限制，可能先前過于久遠的信息，就會被新的信息被覆蓋，針對這種情況，就需要定期清除無效日志。有些異常會導致系統重啟，而重啟之后，就會導致異常信息被正常重啟的信息覆蓋，這就需要系統能夠支持log的備份。不管怎么樣，log為定位現場問題提供了最基本的、最主要的信息來源。一個完善的log機制，對于定位現場問題非常有幫助。如果不滿足，可能首要任務是先完善日志功能。

2、回退軟件版本，緊急消除現場問題

有些現場問題，雖然偶發(fā)事件，但發(fā)生后影響嚴重，客戶無法接受。針對這種情況，在解決問題之前，可以先把軟件降級，降級到相對穩(wěn)定，沒有嚴重故障的版本。

3、比較相鄰版本之間的代碼改動

如果不容易復現的故障，確認在升級了某個軟件版本之后才出現的，而其他現場條件都沒有變化，且分析log也無法發(fā)現異常點。此時，一種高效的解決此問題的方法，就是比較兩個版本之間的代碼的改動。

代碼改動比較少，分析代碼比較容易；如果代碼改動比較多，就需要根據用戶描述的現象，結合前后代碼的改動模塊，初步分析最可能是哪個模塊引起的，這種往往需要對系統架構較深刻的理解。在眾多修改模塊中，分析最有可能關聯的代碼模塊的改動，然后逐一排查 。分析代碼的改動與出現的現象之間可能的關聯關系，對開發(fā)人員個人的技術素養(yǎng)和方法論有較高的要求 。比較相鄰版本之間的代碼改動，針對某些棘手的現場問題，有時候確實是一個非常有效的手段。

4、問題復現

雖然常規(guī)來說現場很難復現，但可以人為的修改軟件、構建或增加模擬數據，人為創(chuàng)造或觸發(fā)條件，增加故障復現的幾率。在設計觸發(fā)條件時，需要圍繞用戶描述的現場故障現象來設計觸發(fā)條件，觀察是否能否復現，且表現一致。

5、分析代碼

根據用戶描述的現象，硬分析代碼，是一種通用的方法，放之四海皆準的方法，熟悉自身代碼的邏輯關系是基本功，但解決問題的效率就比較難把握了。

6、增加 log 更新版本繼續(xù)測

如果常規(guī)的log無法展現故障的異常，就需要在猜測有可能的部分增加日志，在現場復測。但這種日志添加的位置是否合理，決定了問題再次出現時是否能定位問題的準確性。這種方法在工程實踐中，實施難度大，需要客戶多次配合。

以上便是此次帶來的嵌入式軟件相關內容，通過本文，希望大家對嵌入式軟件已經具備一定的了解。如果你喜歡本文，不妨持續(xù)關注我們網站哦，將于后期帶來更多精彩內容。最后，十分感謝大家的閱讀，have a nice day!