GPIO 的驅動程式開發、sysfs 存取與 mmap

Question

我相信，當有其他方法可以完成相同工作時，我無法完全理解在嵌入式系統中為某些特定設備（例如 GPIO）編寫設備驅動程式的好處。

1. 您可以透過 sysfs 和設備樹存取 GPIO。

   • 編寫一個新的設備樹覆蓋並啟用它
   • 轉到/sys/class/gpio
   • 匯出所需的引腳並開始使用它（透過簡單的 shell 呼叫或在 c/c++ 應用程式內）

2. 編寫自己的驅動程式。

   • 編寫真正的功能程式碼。
   • 將驅動程式公開給使用者空間中的節點（如 /dev/tty）。
   • 編寫另一個 c/c++ 程式碼來存取驅動程式（也可以透過簡單的 shell 呼叫來存取）
   • 如果您需要任何新功能，請先變更驅動程序，然後變更程式碼。 （為什麼？）

3. 直接使用/dev/mem；

   • 包含 mman.h 並使用 /dev/mem 物件來設定或取得 GPIO 狀態。

所以，

• 1 -> 將被棄用並且速度緩慢。 （好吧，絕對有利於快速原型製作）
• 2 -> 這比 1 快多少？第一個也是另一個 GPIO 驅動程序，不是嗎？
• 3 -> 這不是最好最快的方法嗎？

我在上面問了幾個問題，但這是我最大的問題；為什麼我不應該直接使用第三個解決方案？

Answer 1

選項 2 的優點是您可以在單一位置驗證請求。就洗碗機而言，您可以在打開水之前確保門感應器顯示門已關閉。當然，您可以告訴人們在放水之前檢查門狀態，但他們都會這樣做嗎？

選項 1 和 3 的潛在缺點是權限。這取決於嵌入式裝置的複雜程度，但您可能希望讓不同的使用者ID 執行不同的操作，例如，家庭路由器可能有不同的uid 運行執行Web UI 的http 伺服器，以及操作前面板LED 的不同守護進程。雖然 GPIO 驅動程式可以具有細粒度的存取控制，但大多數驅動程式都採用全有或全無的方法。使用選項 2，您可以精細地決定哪些使用者可以存取哪些設施。

選項 2 的缺點是它更複雜，並且通常需要核心中的程式碼。