内核模块通过周期性内核定时器（jiffies 或 hrtimer）从 UART 收集数据答案

【问题标题】：kernel module to collect data from UART with periodic kernel timer (jiffies or hrtimer)内核模块通过周期性内核定时器（jiffies 或 hrtimer）从 UART 收集数据
【发布时间】：2017-07-22 08:26:48
【问题描述】：

我正在使用 linux kernel-2.6.35.3 开发 imx283 平台，并使用所有 3 个 uart 端口进行通信。

我想从 UART-1 收集数据，但需要有准确的间隔。

数据是从传感器收集的。

我需要向传感器发送命令以获取数据。

时间间隔可以从 10 毫秒到 2 秒。

我需要一些关于内核模块的帮助，我可以使用内核计时器并从 uart 收集数据吗？

内核定时器有很好的准确性，所以我是否可以使用它们。

谢谢，

【问题讨论】：

不可能，你需要的是 RTOS，而不是 Linux，尤其是古董。
"我需要内核模块的帮助" -- 为什么是内核模块？可能已经有一个设备驱动程序处理 UART，因此您应该在用户空间中“从 UART-1 收集数据”。 "...但需要有一个准确的区间" -- 做什么？数据会异步到达，那你想轮询设备还是轮询接收缓冲区呢？仅供参考，现有的 UART 驱动程序肯定使用中断（而不是轮询）来服务 UART。为什么你想要比现有驱动程序更低的性能？ OTOH 有特殊情况时首选轮询，但您没有引用任何内容。
请解释一下您对 我想从 UART-1 收集数据但需要准确的间隔 的含义，因为这需要一些解释。 RS232 数据传输取决于选择的波特率，这意味着单个 8 位、无奇偶校验、一个停止位在 9600 波特率下使用 1ms。
顺便说一句，即使是最奇怪的规范，标准的 tty 驱动程序也足够了，请参阅 termios(4) 了解如何使用 VMIN 和 VTIME 参数来处理超时和分组数据。
@LuisColorado 感谢您的反馈。实际上，根据我的理解，如果我在用户空间中执行此任务，即在 while 循环中使用 usleep(interval) 发送命令和接收数据，它就有机会成为中断为....我还运行 3 个进程和 4 个线程以及这个任务作为 pthread。所以为了让它不间断......我在想是否有可能在内核中这样做并在环形缓冲区中收集数据，因为对于这个任务......我只关心我收集的数据和间隔。跨度>

标签： linux timer linux-kernel kernel uart

【解决方案1】：

使用 rs232 的标准驱动程序，从您发出 write(2) 系统调用到内核驱动程序开始向串行线路输出字节的时间没有延迟（请记住，驱动程序已经在内核模式下运行）。为此编写驱动程序或内核模块很容易出错，必须由您维护，并且您需要在内核编程方面很聪明才能做好并且不会崩溃（您必须应对标准驱动程序试图使用端口，因为它是由驱动程序自动完成的，您的驱动程序必须保留端口供自己使用，以免干扰它）。仅当您完全填满缓冲区时，您的进程将不得不等待缓冲区变空，但根据定义，这不会发生，因为您无法补偿（您正在填充输出行比字符输出快，这将使您的进程在缓冲区已满时阻塞），在这种情况下完全是真正的计时器。在输入时，您有类似的过程。您将有一个输入字符触发一些中断以将其从设备带到缓冲区，这通常（如果您在 termio 上将 VMIN 配置为 1）意味着您的进程将在读取每个字符时立即唤醒（如每个字符一进来）我建议你使用VMIN设置为1和VTIME设置为0（阅读标准termios(3)手册页以获得串行驱动程序的完整解释）来唤醒你的进程尽快每个字符都被接收。您的进程将被唤醒和调度，具体取决于系统负载和 cpu 速度，但这通常意味着及时使用正常的最新 cpu。您可以在来自read(2) 调用后立即为读取添加时间戳，或者尝试在单独的ioctl(2) 调用中从内核获取读取时间戳，以检查何时收到字符（我知道这在 linux 中是可能的，至少对于套接字，不需要为此编写模块）（但不是从远程端传输时，请考虑这一点）但我认为要获得毫秒时间，在用户模式下完成所有操作就足够了，而且不会复杂化事情进入内核模式。 RS232 线路不是为实时而设计的，因此您正在尝试的内容可以在毫秒级分辨率下使用，而无需在内核端进行编程。

此外，在用户模式下执行所有操作可以让您的程序从一个系统移动到另一个系统，而无需在尝试您的软件之前进行复杂的内核模块安装，甚至更多......知道如何使用 tty 驱动程序可以让您在非 Linux 系统（例如 BSD、Solaris 或 MAC）中运行您的代码

【讨论】：

你可能没有研究Linux内核中的UART驱动，除了内核本身的复杂性（中断处理、DMA等）之外，驱动（如果我们谈论8250）也有其自身的问题.您所描述的适用于您可以完全控制事物的uController，不幸的是，在Linux中，UART几乎是要完成的最繁重的任务之一（CPU速度不足以服务UART中断，主要是因为安排了其他任务并且缓冲区太小）。
@0andriy，当然，如果我们谈论 8250，那么 uart 并不是最好的技术。但你说的是很久以前就被取代的芯片。现在我觉得看到其中一个很奇怪。也许您想描述如何实现 pdp-11 或 pdp-7 的 tty 驱动程序？我当然已经研究了 linux 中 rs232 的内核驱动程序......也在 unix 和 BSD 系统中。我对 uart 编程的第一次体验可以追溯到除了 8250 之外别无选择的时候，我很清楚它的局限性。
@0andriy，现在，没有一台电脑的售价低于 16550A（或 B），甚至更好的设备。您发表评论的确切目的是什么？
好吧，我们的某个人没有仔细阅读。我写了关于驱动程序的，但这真的没关系，16550a 甚至 16750（64 字节的 FIFO）并没有让情况变得更好。除了您在没有一台计算机的销售低于 16550A（或 B），甚至更好的设备这一事实之外。
直言不讳，Linux 内核并未调整为实时服务于 UART。期间。