嵌入式軟件開發人員通常會避免硬件抽象層(HAL)，聲稱它們會降低性能并增加代碼復雜性。不幸的是，當嵌入式開發人員采用HAL時，供應商提供的HAL通常不會抽象硬件，并且仍然保證與硬件的緊密耦合。畢竟，一個真正的抽象HAL將使開發人員能夠輕而易舉地使用任何供應商。然而，使用或開發自己的HAL會通過多種方式影響你的軟件。在這篇文章中，我們將探索HAL可以改變你的軟件項目的五種令人驚訝的方式，并釋放你沒有意識到的速度和價值。

　　方式1：硬件獨立性

　　開發人員通常有一個最喜歡的微控制器供應商。通常是你第一次編寫嵌入式軟件的供應商或者你熟悉的供應商。

　　使用一個好的HAL將允許你編寫更易移植和可重用的獨立于硬件的應用程序代碼。對于許多嵌入式團隊來說，這是一個巨大的轉變。例如，你可以使用供應商A運行代碼，并通過更改版本中的標志，為供應商b編譯代碼。硬件獨立性使你可以靈活地使用任何你想要的硬件，并消除你對微控制器供應商的依賴。

　　如果你喜歡使用供應商提供的HAL，只要你回顧幾個基本特性，這是可以的。首先，HAL必須是一個真正的HAL。這意味著你必須有一個定義好的接口來打破對硬件的依賴。接下來，HAL應該與實現分開定義。最后，你應該能夠快速換出接口調用的函數。如果你沒有這三樣東西，那么你就沒有硬件獨立性;你有硬件依賴!

　　方式2：啟用自動化單元和集成測試

　　釋放價值和轉變軟件開發的關鍵從使用HAL開始。HAL進一步支持額外的轉換，比如支持自動化單元和集成測試。嵌入式開發人員經常糾結于單元測試，因為他們編寫的代碼會接觸到硬件。這意味著你必須在微控制器上運行你的測試。當你有了一個合適的HAL，你仍然需要在目標上測試你的驅動，但是你所有的應用程序代碼突然被釋放了!你的應用程序代碼現在可以在獨立于硬件的主機上進行單元和集成測試。

　　方式3：執行偏離目標模擬的能力

　　當你用一個好的HAL把硬件從等式中去掉時，它允許你把任何實現放在它后面。這意味著你可以為你的目標、你的測試工具和一個模擬環境擁有一個實現!在許多情況下，嵌入式軟件開發人員必須在硬件可用之前開始編寫軟件。因此，雖然我們可以使用開發板開始，但有了一個好的HAL，我們可以在我們的應用程序代碼上運行模擬!

　　模擬應用程序代碼對嵌入式開發人員來說有很多好處。首先，它允許他們更早而不是更晚地在客戶面前獲得應用程序代碼。我們都知道，客戶喜歡改變主意，在體驗之前，他們很難想象產品的工作方式。模擬可以幫助客戶理解產品，并更快地提供富有成效的反饋，減少開發周期后期昂貴而耗時的變更。

　　其次，通過允許在沒有硬件的情況下測試故障和其他異常行為，模擬實現了更健壯的測試。例如，讓一個傳感器行為不當或在目標處理器上強制硬件異常通常是具有挑戰性的。在模擬環境中，這不是問題。結果又是更健壯的軟件。

　　方式4：更快、更高效的調試

　　當你在目標上調試時，每次進行更改時，都會有一個交叉編譯、擦除閃存、編程閃存和運行應用程序的循環。整個過程可能需要相當長的時間，這取決于應用程序，即使使用專業工具。使用HAL來分離應用程序可以更快地調試代碼!在主機上，編譯和運行周期要短得多。這意味著開發人員可以更快地解決問題，然后在必要時在他們的硬件上測試最終的調試版本。

　　如果你允許HAL提供的其他方式實現，你將使用單元測試來驅動開發，這意味著你甚至可以減少調試時間。你只會編寫通過測試的代碼。你的軟件會以小的增量編寫，測試會一直驗證它。如果你破壞了什么東西，回歸測試會立即發現它。其結果將是更快、更高效的調試，并且幾乎完全從你的生活和項目中去除調試!聽起來是不是很棒?

　　方式5：上市時間和成本降低

　　使用HAL開發嵌入式軟件的最終轉變是降低成本和上市時間。HAL為嵌入式開發軟件創造了靈活性，這是大多數團隊做夢也想不到的。你可以很容易地看到，如果你能很快得到客戶的反饋，你在開發周期的后期會有更少的返工。此外，如果你能消除調試，那就太棒了!大多數團隊平均花費20–40%的開發周期進行調試!也就是每人每年2.4-4.5個月!這都是因為你使用了HAL，它能夠測試你的應用程序代碼并減少調試時間。

　　隨著上市時間的縮短，成本顯然會降低。當然，在HAL開發、測試工具和其他工具上也有投資，以確保開發周期順利進行。然而，這些成本通常比節省的成本少一個數量級。我甚至沒有提到與維護相關的費用，這些費用很容易超過最初的開發成本。

　　結論

　　我們討論的一些方式可能看起來有點陌生，因為嵌入式開發人員傳統上沒有使用過這些技術。然而，不需要花太多時間就能掌握它們，并允許它們極大地改進你開發嵌入式軟件的方式。你已經看到了好處;問題是你是否會接受它們，并開始在你的軟件中構建一個獨立于微控制器的HAL。如果你這樣做了，我認為你將徹底改變你開發嵌入式產品的方式。