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

　　技巧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外設在上電時處于故障狀態，隱藏在模糊寄存器中的一個位需要清零。

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

　　總結

　　驅動程序的設計和實現是嵌入式系統開發的重要組成部分。進一步探索驅動程序設計模式以及如何構建可以訪問互聯網的嵌入式系統對嵌入式開發人員來說非常重要。