Question

我目前正在使用运行Linux 3.10.0+的SAMA5D31-EK板来控制某些硬件设备。我正在使用该板上提供的GPIO，I2C，PWM和UARTS。有些器件仅通过GPIO线控制，而其他器件则需要UART，PWM和3个GPIO。到目前为止，我正在使用用户空间程序来控制这些硬件设备 - 基本上是步进电机，ADC和字母数字LCD显示器。

开发内核设备驱动程序来控制这些设备有什么好处？到目前为止（使用用户空间程序）我发现的唯一限制是速度：因为我不得不咬一些GPIO，结果有点慢。

Answer 1

我假设您的电路板上有I2C / GPIO / PWM / UART接口的平台专用驱动程序（它应该是BSP [Board-support-package]的一部分）。

只是您不想使用内核设备驱动程序框架并希望从用户空间执行操作。我知道，这种情况有多么诱人，特别是如果你不精通内核设备驱动程序的话。

一个。 SPEED ：你提到过了。但是，你可能没有完全理解这个原因。

速度效率来自避免内核和用户空间进程之间的上下文切换。这是一个例子：

/* A loop in kernel code which reads a register 100 time */
for (i = 0 ; i < 100 ; i++ )
{
  __kernel_read_reg(...);
}

/* A loop in User-space code which reads a register 100 time */
for ( i= 0 ; i < 100; i++)
{
   __user_read_reg(...);
}

功能明智* _read_reg（）是相同的。假设__user_read_reg（）将通过典型的系统调用过程，它必须为每个__user_read_reg（...）执行一个Context-switch，这太昂贵了。

您可能会争辩说，＆＃34;我们可以mmap（）硬件寄存器并避免系统调用此类操作＆＃34;。当然，你可以这样做，但我要说的是：什么是接近硬件（例如：寄存器读或写或处理中断）应该尽快完成。上下文切换中涉及的延迟会影响性能。

湾现有/已测试/精心构建的子系统：

如果你在Linux内核中看到一个I2C子系统，它提供了一个经过良好测试的健壮框架，可以很容易地重用。您不必在用户空间中编写完整的I2C子系统（处理所有设备类型，速度，各种配置等）。重新使用＆＃34;在使用内核设备驱动程序时，已经完成的工作可能是一大优势。

℃。 从基于轮询的方法转向基于中断的机制

如果您没有处理内核驱动程序中的中断，则必须在用户空间进程中使用某种轮询机制。根据系统的不同，它可能不是处理硬件变化的非常可靠的方式。对于快速设备而言，无限期不准确/可靠。

基于中断的机制，一般来说，您可以尽快处理关键更改（硬件中断上下文）并将非关键工作负载移动到用户空间或其他一些内核机制是更可靠的方式处理设备。

当然，除了上面三个之外，还有几个论点和反驳论点。

您可能感兴趣的另一个主题是： Userspace vs kernel space driver

内核设备驱动程序或用户空间程序

1 个答案: