從 RS232 串行端口接收時阻塞的線程喚醒的最長時間是多少？

Question

假設我將進程設置為最高優先級並且沒有交換......

從 RS232 串行端口接收時阻塞的線程喚醒的最長時間是多少？

我想知道線程是否會在 UART 中斷到達 kernel 的微秒內被喚醒，或者它是否必須等待 CPU 上的下一個 100 毫秒時間片。

Answer 1

從 RS232 串行端口接收時阻塞的線程喚醒的最長時間是多少？

根據模式（例如規范），進程可能會永遠等待（例如，對於 EOL 字符）。

---

我想知道線程是否會在 UART 中斷到達 kernel 的微秒內被喚醒，或者

線路上的幀結束（即停止位）是一個更好（即一致）的參考點。

考慮到中斷生成和處理可以推遲，“ UART 中斷命中 kernel ”是一個糟糕的參考點。
UART FIFO 可能不會為每個字符/字節生成中斷。
中斷 controller 優先考慮掛起的中斷，UART 很少被分配高優先級。
軟件可以禁用關鍵區域的中斷。

---

是否必須等待 CPU 上的下一個 100 毫秒時間片。

系統調用完成后，最高優先級的可運行進程獲得控制權。
參考： Linux Kernel 開發：搶占和上下文切換：

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 kernel 的配置可以進一步改善/最小化這種延遲，例如， 該開發人員報告了從毫秒到僅約 100 微秒的幅度減少。

---

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

然后一定要查看 Linux串行驅動程序。