☰

GPIO 的驱动程序开发、sysfs 访问与 mmap

tag-icon • tag-icon linux drivers sysfs gpio
GPIO 的驱动程序开发、sysfs 访问与 mmap

我相信，当有其他方法可以完成相同工作时，我无法完全理解在嵌入式系统中为某些特定设备（例如 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 -> 这不是最好最快的方法吗？

我在上面问了几个问题，但这是我最大的问题；为什么我不应该直接使用第三个解决方案？

答案1

选项 2 的优点是您可以在单个位置验证请求。就洗碗机而言，您可以在打开水之前确保门传感器显示门已关闭。当然，您可以告诉人们在放水之前检查门状态，但他们都会这样做吗？

选项 1 和 3 的潜在缺点是权限。这取决于嵌入式设备的复杂程度，但您可能希望让不同的用户 ID 执行不同的操作，例如，家庭路由器可能有不同的 uid 运行执行 Web UI 的 http 服务器，以及操作前面板 LED 的不同守护进程。虽然 GPIO 驱动程序可以具有细粒度的访问控制，但大多数驱动程序都采用全有或全无的方法。使用选项 2，您可以精细地决定哪些用户可以访问哪些设施。

选项 2 的缺点是它更复杂，并且通常需要内核中的代码。

相关内容