linux - 从 RS232 串行端口接收时阻塞的线程唤醒的最长时间是多少？

Question

假设我将进程设置为最高优先级并且没有交换......

从 RS232 串行端口接收时阻塞的线程唤醒的最长时间是多少？

我想知道线程是否会在 UART 中断到达内核的微秒内被唤醒，或者它是否必须等待 CPU 上的下一个 100 毫秒时间片。

标签： linuxserial-portinterruptblockinglatency

Answer 1

从 RS232 串行端口接收时阻塞的线程唤醒的最长时间是多少？

根据模式（例如规范），进程可能会永远等待（例如，对于 EOL 字符）。

---

我想知道线程是否会在 UART 中断击中内核的微秒内被唤醒，或者

线路上的帧结束（即停止位）是一个更好（即一致）的参考点。

考虑到中断生成和处理可以推迟，“ UART 中断命中内核”是一个糟糕的参考点。
UART FIFO 可能不会为每个字符/字节生成中断。
中断控制器优先处理挂起的中断，UART 很少被分配高优先级。
软件可以禁用关键区域的中断。

---

是否必须等待 CPU 上的下一个 100 毫秒时间片。

系统调用完成后，最高优先级的可运行进程获得控制权。
参考：Linux内核开发：抢占和上下文切换：

Consequently, whenever the kernel is preparing to return to user-space, either 
on return from an interrupt or after a system call, the value of need_resched 
is checked. If it is set, the scheduler is invoked to select a new (more fit) 
process to execute.

---

我希望最大限度地减少接收到的停止位和来自高优先级用户空间线程的回复的开始位之间的 Linux 串行延迟。

我怀疑这就是你真正想要的。
串行终端的配置对于最小化这种延迟至关重要，例如研究ASYNC_LOW_LATENCY串行标志。
然而，Linux 内核的配置可以进一步改善/最小化这种延迟，例如，该开发人员报告了从毫秒到仅约 100 微秒的幅度减少。

---

我只熟悉 ATMEGA 和 STM32 微控制器上的串行接口......

然后一定要查看 Linux串行驱动程序。