每個嵌入式軟件應用程序必須在某個時刻訪問最低級別的固件并控制硬件。驅動程序的設計和實現對于確保系統滿足其實時要求至關重要。以下是每個開發人員在設計驅動程序時應考慮的五個提示。

提示1 -使用設計模式

設計模式是一個解決方案在軟件中反復出現的問題。開發人員可以從頭開始重新構建解決方案，浪費寶貴的時間和預算，或者可以打開他的解決方案工具箱并選擇最適合問題的解決方案。自微處理器誕生以來，低級驅動程序已經出現并且是一個很好理解的問題。為什么不利用現有的解決方案？

驅動程序設計模式通常分為四類;位爆炸，輪詢，中斷驅動和直接存儲器訪問（DMA）。當微控制器沒有內部外圍設備來執行功能或者所有這些內部外圍設備都已用完并且還需要一個外部設備時，開發人員會選擇位爆炸模式。 Bit bang解決方案可以高效，但通常需要相當多的軟件開銷才能實現該功能。有點爆炸模式讓開發人員手動實現通信協議或外部行為。

輪詢模式只是以循環方式監視事件。輪詢模式對于簡單系統很有用，但許多現代應用程序需要中斷。中斷提供了在事件發生時處理事件的能力，而不是等待代碼手動檢查事件。 DMA模式允許另一個外設處理數據傳輸需求，讓驅動程序可以放手。

技巧2 -了解實時行為

實時系統滿足最后期限的能力始于其驅動程序。編寫得不好的驅動程序效率低下，并且為不知情的開發人員提供了破壞其系統性能的潛力。驅動程序有兩種，設計師應該考慮;阻止和非阻塞。阻止驅動程序會阻止任何其他軟件執行，直到驅動程序完成其工作。例如，USART驅動程序可能會將一個字符放入發送緩沖區，而不是繼續前進，在繼續之前等待發送結束標志。

另一方面，非阻塞驅動程序通常會利用中斷來執行其功能。中斷的使用可防止驅動程序在等待事件發生時阻止軟件執行。 USART驅動程序可能會在發送緩沖區中放入一個字符，然后主軟件會轉到下一條指令。傳輸結束標志的設置會導致中斷觸發，允許驅動程序進行下一步操作。

無論何種類型，都要保持實時性能并幫助防止系統故障開發人員必須了解其驅動程序的平均和最差情況執行時間。系統的完整性可能受到威脅，如果系統對安全至關重要，可能會更多。

提示3 -重新設計

時間和預算很短，為什么要重新發明輪子？重用，可移植性和可維護性是驅動程序設計的關鍵要求。通過設計和使用硬件抽象層可以解決許多這些功能。

硬件抽象層（HAL）為開發人員提供了一種創建標準接口來控制微控制器外設的方法。抽象隱藏了實現細節，而是提供了可見的功能，例如 Usart_Init 和 Usart_Transmit 。我們的想法是，任何USART，SPI，PWM或其他外設都具有所有微控制器都支持的通用功能。 HAL的使用隱藏了低級別，特定于設備的細節，允許應用程序開發人員專注于應用程序需求，而不是低級硬件如何工作。同時，HAL提供了一個可以重復使用的容器。

提示4 -參考數據表

微控制器在過去幾年中變得有點復雜。曾幾何時，人們可能想知道的關于微控制器的所有內容都包含在由500頁左右的單個數據表中。今天的32位微控制器通常包含數據表，包括部件數據表，系列數據表，以及每個外設的數百頁，以及所有勘誤表。如果開發人員真的想要完全理解該部分，那么他們需要完成幾千頁的文檔。

不幸的是，所有這些數據表都需要真正實現驅動程序。開發人員應該在每個數據表及其中包含的信息中收集和排序。通常需要咨詢其中的每一個以使外圍設備啟動并運行。每種類型的數據表都會散布（和隱藏）關鍵信息。

提示5 -小心外圍故障

我最近有機會移植一些從一個微控制器系列到另一個系列的驅動器。制造商和數據表均表明PWM外設在兩個系列之間是相同的。另一方面，運行PWM驅動器表明，盡管有這種斷言，但兩者之間存在很大差異。司機在原始部件上工作，而不是在新部件上工作。

在仔細閱讀了數據表之后，我在一個完全不相關的數據表中發現了一個腳注，即上電時的PWM外設處于故障狀態，并且需要清除隱藏在混淆寄存器中的單個位。

在驅動程序實現開始時，識別外圍故障和任何看似無關的故障寄存器。

更進一步

驅動程序設計和實現是嵌入式系統開發的關鍵組件。為了進一步探索驅動程序設計模式以及如何構建可以訪問互聯網的嵌入式系統，請考慮參加我在EDN姊妹刊物 Design News 上關于“設計模式和互聯網”的下一個CEC課程。 2015年10月19日這一周。我們將在STM32上介紹I2C設備的驅動程序設計，并使用Electric Imp創建一個連接互聯網的氣象站。