當嵌入式軟件開發人員要開始一個新項目時，他們做的第一件事就是要一個開發工具包。開發工具包允許開發團隊熟悉微控制器及其外設。然后，他們可以開始用分隔板之類的東西拼湊一個系統。

這種方法的問題在于，它迫使開發人員從頭開始思考。他們專注于他們正在使用的硬件。是的，這是難題的一個重要部分，但是低層次的思考往往會導致緊密耦合的代碼、硬件依賴性，并且客戶幾個月都看不到任何結果。

在今天的開發環境中，沒有理由為什么一個團隊不能從第一天開始模擬他們的系統。事實上，嵌入式團隊需要采用模擬來使他們的實踐現代化并取得成功有三個原因。

原因1–更快的上市時間和更低的開發成本

幾十年來，許多工具和服務公司都在吹噓更快上市和更低成本的能力。這些方法是否真的有效還有待討論。

任何產品公司的目標都是盡可能快地開發他們的產品。在許多情況下，產品開始是模糊的。他們認為自己知道顧客想要什么，需要什么，但這通常只是猜測。

如果你從主機上的模擬開始，你會立即放棄對硬件的關注。相反，你要關注客戶和他們的需求。這意味著在第一天，你正在編寫以客戶為中心的代碼。不是為使LED閃爍或傳感器被讀取而設計的代碼。雖然這些都很重要，但產品的最終目標是向客戶交付價值。

如果客戶提前拿到產品，他們可以告訴你產品是否符合他們的需求。他們可能認為他們需要一件東西，但是在他們試驗過之后，他們意識到他們需要別的東西。如果你已經設計了整個產品，這意味著你必須回去重做它的大部分。這既費時又費錢，還會推遲你的產品上市。

模擬可以幫助鞏固客戶和管理團隊眼中的產品。當改變不涉及硬件時，要容易得多。這意味著應用程序可以放在第一位，實時的、底層的、硬件的東西可以放在后面。不管怎樣，這很好，因為硬件公司不會有硬件供你使用幾個月。有了清晰的產品和分離的應用代碼，結果將是更快的上市時間和更低的開發成本！

原因2–模擬鼓勵硬件去耦

你是否嘗試過移植與硬件緊密耦合的應用程序代碼？雖然你可能在開始編寫代碼時認為可以將其耦合到硬件上，但你永遠不知道什么時候硬件可能變得不可用，或者什么時候功能蔓延會迫使你升級處理器。

模擬迫使開發人員立即開始開發不依賴于硬件的代碼。你從一臺主機開始，必須使用抽象和接口來獲得硬件通常會提供的預期結果。通過打破對硬件的依賴，你會發現你自然會寫出更可重用、可移植和可伸縮的代碼。

將硬件從軟件中分離出來有很多好處。例如，它在開發過程的早期為團隊提供了靈活性。他們可以在自己的開發機器上運行代碼，甚至可以在Raspberry Pi之類的設備上運行代碼。開發人員可以編寫和測試他們的代碼，而不必等待硬件的出現。事實上，它可以幫助他們編寫更好的單元測試，更容易集成到CI/CD框架中！

當團隊開始模擬時，軟件架構和實現通常更具可伸縮性、可重用性和可移植性。它讓他們思考應用程序級別，這是產品真正的“秘方”。

原因3——在主機上調試效率更高

在目標上調試代碼效率不是很高。你必須遵循一個有點神秘的過程：

l 交叉編譯代碼

l 抹去目標

l 對目標編程

l 啟動調試會話

l 逐句通過代碼

開發人員平均花費20-40%的時間在調試上！當你用幾個月的時間來思考這個問題時，你會發現一年大約有2.5到4個月的時間花在了做失敗的工作上！

當你有一個模擬器時，你可以跳過晦澀難懂的目標調試過程。運行應用程序和重新創建問題通常會更容易、更快。你可以生成日志信息，以便于識別問題。當你進行更改時，只需進行更改、編譯并運行即可。它很快。目標調試不是。這可能會更有趣，因為你可以玩電子產品，但這浪費了很多時間和資源。

結論

采用模擬技術可以極大地改進嵌入式軟件，它可以迫使你首先關注你的應用，這有助于客戶更快地鞏固產品。運行與底層硬件分離的應用程序代碼將鼓勵代碼的可伸縮性和重用性。你將能夠更好地為你的應用程序編寫自動化測試，并確保低級硬件不會礙事。

考慮使用模擬器編寫軟件可能有點令人畏懼，但這并沒有太大的不同。你可以像在嵌入式目標上一樣，在Linux、Windows或MacOS上輕松執行你的RTOS。調試問題會更快。將代碼部署到客戶面前會更容易。

雖然需要一點時間來適應，但模擬代碼將幫助你更新嵌入式軟件的開發方式，最終，你會發現你可以更快地完成這項工作。