硬件和軟件的開發過程似乎有些相似：發布了需求規范；精心設計；結果使用一種特殊的語言進行編碼（用于硬件的HDL和用于軟件的編程語言）。但是相似之處到此為止。

啟動硬件生產時，硬件設計會在某些時候凍結。在此之后進行更改通常會很麻煩且昂貴。另一方面，軟件永遠不會完成。調整和完善將持續到最后一刻。調整代碼并進行重建非常容易。這既是優點也是缺點。

由于軟件可以延展性強，因此有機會進行廣泛的測試并修復仍然存在的錯誤。靈活性的不利之處在于，人們傾向于在最后時刻進行增強和完善。“蠕動的優雅”是真正的危險。這些挑戰都是與軟件相關的，但情況越來越糟……

如果在凍結設計后檢測到硬件錯誤怎么辦？

硬件問題通常昂貴且處理不便。一個非常常見的解決方案是“將其修復在軟件中”。這樣的修復可能是微不足道的，軟件工程師應該很高興能夠為他們的硬件同行提供幫助。但是，在其他情況下，對代碼的調整可能會完全損害軟件設計。

設計中的錯誤與“怪異”之間存在一定程度的模糊性，“怪異”對于硬件開發人員來說并不奇怪，但需要包含在軟件中。我們可以用一些示例來說明軟件需要在哪些地方容納硬件的怪異之處。

翻轉位

嵌入式系統中最簡單的輸入設備是開關或按鈕。憑直覺，可以預期處于“關閉”位置的開關（或未按下的按鈕）將顯示為0值，并在打開（或按下按鈕）時轉換為1。但是，在幾乎所有情況下，情況都是相反的：關閉開關顯示為1并轉換為0。這是因為它簡化了硬件設計，可以將輸入引腳“上拉”為邏輯1并將其接地（下拉為0）。 ）表示輸入。當然，一旦開發人員對此有所了解，在軟件中的容納就變得微不足道了。

彈跳

關于開關或按鈕的另一個自然期望是，它將僅在兩種邏輯狀態之間轉換。但是，機械開關的行為通常不是很理想-觸點閉合，然后彈跳開一次或多次，然后降落到閉合位置。此行為的結果是，預期的從1到0的過渡可能會快速連續地重復幾次，未經檢查，可能會被錯誤地解釋。想象一下按下一個按鈕會增加一個設置，但通常會將其增加2或3而不是1！

這可以固定在硬件中，但這要付出復雜性和材料清單的代價。多年來，“修復軟件”是最佳的選擇，并且已經設計了許多“反跳”算法。

一切都與時機有關

一些復雜的外圍硬件可能會響應軟件寫入寄存器的命令。硬件通過執行一系列動作來響應命令的情況并不少見，在此期間它不會響應其他命令。這不是故障，因為硬件設計人員希望設備以此方式運行。但是，從軟件開發人員的角度來看，這似乎是不合邏輯的。

這給軟件帶來了挑戰。需要包括安全措施，以便在發出命令時，必須經過一段適當的時間才能編寫另一條命令。在簡單的應用中，某種延遲循環可能就足夠了。在更復雜的軟件中，可能無法在空閑循環中占用CPU，因為還有其他處理要做。在這種情況下，需要更復雜的計時機制。

大端或小端

有多種方式可以表示一個單詞（甚至一個字節）內的數據。一個簡單的例子是單詞中字節的順序。他們可能是最不重要的第一或最重要的。兩種方法都不對，而且不同的CPU歷來都是小端或大端的。因此，幾乎不可避免的是，鏈接在一起的兩個子系統可能對數據表示有不同的想法。

這是在軟件中修復的另一種候選方法，僅字節交換或循環。挑戰在于將接口的使用本地化到執行轉換的軟件的一小部分。

增加功能

除了規避硬件中的錯誤和怪異之外，以節省成本為名，或者因為該功能在開發過程的后期就被夢想了，可以在硬件中有效實施的功能可以卸載到軟件中并不少見。

這是微處理器控制的替代品，用于伺服液壓系統上的大型硬接線控制面板。當時，在微處理器中擁有如此巨大的計算能力的想法令人鼓舞，當然，開發人員對此感到迷戀。硬件設計已經完成，并在非常好的時間內凍結，使生產能夠按計劃進行。在新功能的想法泛濫之前，軟件開發一直進展順利。該軟件被迫屈服（即，其實時行為受到損害），因此必須進行重大設計審查。

隱藏硬件問題：驅動程序

長期以來，人們已經認識到，訪問和控制硬件對于沒有經驗的或缺乏經驗的嵌入式軟件開發人員可能是一個特殊的挑戰。結果，出現了設備驅動程序的概念。驅動程序只是一個很小的軟件，它封裝了使用某些硬件的笨拙并提供了與應用程序代碼的合理接口。

它是在驅動程序中容納了硬件設計的怪癖，理想情況下，應該在其中進行調整以解決意外的功能或非功能。

責任編輯：Ct