在嵌入式系統中管理設備驅動程序的概念

Question

假設我們有嵌入式設備，例如Linux或沒有任何操作系統的操作系統。在這個器件中（或芯片上），我們有硬件UART，並且我們有用於UART的驅動器。我們希望附加一些能夠通過UART控制的外部設備，並且我們希望爲該設備提供很好的抽象層。我想知道什麼是最好的主意，或者處理這些問題的正確方法是什麼？我已經提出了4個不同的概念。

概念1.

這裏外部裝置驅動直接使用UART驅動程序，但仍存在主/內核使用UART驅動程序選項。

概念2.

這裏外部設備驅動程序直接使用UART驅動程序，但沒有辦法用於任何其他模塊使用UART驅動程序時，它正忙。如果我們有多個外部設備連接到UART，不同的外部設備驅動程序會在使用UART驅動程序之間切換，並保留主代碼的完整抽象。

概念3.

這裏外部裝置驅動會控制硬件UART，但仍有其他模塊使用的硬件UART時，它不是由外部裝置驅動器所佔用一般UART驅動。

概念4.

這裏外部設備驅動器是相當，在用戶空間或主運行的代碼。它使用通用的UART驅動程序，響應由主應用程序重定向到外部設備驅動程序。

我想問一下開發商提供更多的經驗用什麼辦法，你會選擇，也許你看到我的任何概念的一些重要缺陷，將它排除在外，或者你會做完全不同的方式？

Answer 1

想想層抽象。較低層實現細節併爲較高層提供更簡單（抽象）的接口。

最底層是UART驅動程序。它負責讀取和寫入字符到UART。它提取了與UART外設接口的細節，以便上面的圖層不會因這些細節而變得複雜。 UART驅動程序只涉及單個字符。它沒有消息，數據包或幀的概念。

UART驅動程序上方的層是外部設備驅動程序。設備驅動程序層本身可能會分成多個層。

• 設備驅動程序的最低層負責將 多個字節組幀成幀。它抽象解釋一幀的細節，以便上面的圖層不會因這些細節而複雜化。 成幀可能包括幀定界字符，幀頭， 和/或CRC。

• 設備驅動程序可能有另一個層來處理ACK，NAK和 重試。並且設備驅動程序可能有另一個層，將多個幀合併爲一個更大的消息。

• 設備驅動程序的最頂層用於格式化，並且 解釋與外部設備交換的消息。該層抽象了格式化/解釋消息的細節，以便上面的層不會被那些 細節複雜化。這可能是處理命令代碼，狀態代碼，多字節值的字節順序和ASCII轉換的地方。

所以，現在我們正在思考抽象層次，讓我們考慮一下你的問題中的四個概念。

由於外部設備驅動程序不是通過UART驅動程序進行分層，因此概念3跳出爲糟糕的設計。這意味着設備驅動程序必須包含並重復包含在UART驅動程序中的功能。這違反了DRY原則，Don't Repeat Yourself。

由於外部設備驅動程序沒有在應用程序和UART驅動程序之間分層，所以概念4看起來也很差。我不確定我是否理解概念4.我在想象應用程序與外部設備驅動程序接口來格式化/解釋消息，然後與UART驅動程序進行接口以發送/接收消息。這似乎是不必要的尷尬。

概念2和1對我來說似乎是合理的。司機們採用避免重複的方式進行分層，並且建立在抽象層次上。我不確定我看到他們之間的區別。如果應用程序只通過設備驅動程序與外部設備通信，那麼概念2似乎是適當的。但是，如果應用程序有另外一個需要發送/接收字節的方法，那麼外部設備通信的概念就是合適的。我不明白需要概念1的要求，但我想它可能存在。