★ FEATURED ARTICLE 1. 从一次串口通信的诡异丢包说起如果你在 Ubuntu 18.04 上接过 USB 转串口设备大概率见过/dev/ttyUSB0这个设备节点。它看起来平平无奇插上就能用但真正把它放到一个需要长时间稳定通信的场景里——比如持续采集传感器数据、跟下位机做协议交互、或者跑一个工业控制的小网关——你就会发现事情没那么简单。我最早接触这个问题是在一个数据采集的小项目里设备每隔几十毫秒上报一帧数据上位机用 Python 的 pyserial 读取结果跑上十几分钟就开始零星丢包重启程序又能好一阵反复如此。当时第一反应是代码逻辑有问题查了缓冲区、查了线程折腾半天没结果最后把注意力放到系统层面才发现是两个很隐蔽的坑设备权限和串口延迟时间latency time。这两个东西一个决定了你的程序能不能稳定打开设备另一个直接决定了数据从硬件到用户态程序之间的延迟和吞吐表现。它们都不属于写代码的范畴而是属于配系统的范畴所以特别容易被忽略。很多教程只告诉你sudo chmod 777 /dev/ttyUSB0就完事了但这条命令背后有一堆问题为什么默认权限打不开为什么重启之后权限又没了latency time 到底是个什么参数改了有什么用这篇文章就把这两个问题彻底讲清楚从现象到原理再到可复现的操作步骤最后给出我在实际项目里验证过的稳定方案。内容会涉及 udev 规则、用户组管理、串口子系统的底层机制以及setserial、sysfs这些工具的具体用法。不管你是刚接触嵌入式串口的新手还是被丢包问题折磨过的老手应该都能从中找到能直接抄作业的部分。下面我按先讲权限、再讲延迟、最后给一套组合方案的顺序展开每一步都会解释清楚为什么这么做而不是只丢命令。2. ttyUSB0 权限问题的本质与 udev 规则落地2.1 为什么默认情况下普通用户打不开 ttyUSB0先看现象。当你把一个 USB 转串口设备插到 Ubuntu 18.04 上系统会自动加载usbserial或ftdi_sio、ch341之类的驱动然后在/dev下创建/dev/ttyUSB0。用ls -l /dev/ttyUSB0看一眼典型输出是这样的crw-rw---- 1 root dialout 188, 0 某月 某日 10:00 /dev/ttyUSB0注意几个关键信息文件类型是c字符设备属主是root属组是dialout权限是rw-rw----。这意味着只有 root 用户和 dialout 组的成员才能读写它。你当前登录的普通用户默认既不是 root也不在 dialout 组里所以直接打开就会报Permission denied。这里有个很多人会困惑的点为什么是dialout这个组这其实是历史沿革。早期 Unix 系统里串口设备主要用来接拨号调制解调器dial-out所以负责管理这些设备的组就叫 dialout。这个命名一直沿用至今虽然现在串口更多是接开发板、传感器、PLC但组名没变。理解这一点很重要因为它解释了为什么解决方案是把用户加进 dialout 组而不是去改文件属主。那为什么不能简单地每次都用sudo跑程序因为 sudo 会改变运行环境你的程序可能依赖当前用户的环境变量、Python 虚拟环境、图形界面权限等用 sudo 跑经常引发新的问题。而且生产环境里程序往往是开机自启的服务不可能靠人工 sudo。所以正确思路是让运行程序的用户永久拥有访问该设备的权限。2.2 把用户加入 dialout 组最省事但要注意生效时机最直接的办法是把当前用户加入 dialout 组sudo usermod -aG dialout $USER这里的-aG是关键-a表示 append追加-G指定附加组。如果漏掉-a只写-G dialout会把用户从其他所有附加组里踢出去只保留 dialout这是个经典事故千万别踩。执行完之后必须重新登录才能生效。因为用户所属的组信息是在登录时由系统读取并写入会话的已经登录的 shell 不会自动刷新。很多人加完组发现还是打不开就是因为没重新登录。验证方法groups看看输出里有没有 dialout。如果没有要么是没重新登录要么是命令写错了。重新登录后再ls -l /dev/ttyUSB0理论上你就有读写权限了。但这里有个隐藏问题设备节点是动态创建的。每次拔插设备或者系统重启/dev/ttyUSB0都会被重新创建属主属组和权限由 udev 根据规则决定。默认规则下它还是 root:dialout所以只要你人在 dialout 组里权限就一直有效。这一点比chmod 777靠谱得多因为 chmod 改的是当前这个节点设备一拔一插就失效了。2.3 udev 规则给设备一个稳定的身份和权限如果你有多个串口设备或者希望设备插上后自动获得特定权限、甚至自动创建固定名字的软链接那就得写 udev 规则。这是比加组更进阶、也更工程化的做法。udev 是 Linux 的设备管理器它监听内核发出的设备事件然后根据/etc/udev/rules.d/下的规则文件决定怎么处理设备节点。规则文件的命名通常以数字开头数字越小优先级越高比如99-my-serial.rules。写规则之前先要拿到设备的唯一标识。用udevadm查询udevadm info -a -n /dev/ttyUSB0输出会很长重点看KERNEL、SUBSYSTEM、ATTRS{idVendor}、ATTRS{idProduct}、ATTRS{serial}这几个字段。其中idVendor和idProduct是 USB 厂商和产品 IDserial是设备序列号如果设备有的话。用序列号做匹配是最稳的因为同一型号的不同设备序列号不同能精确区分。一个典型的规则长这样# /etc/udev/rules.d/99-my-serial.rules SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, ATTRS{serial}ABCD1234, MODE0666, GROUPdialout, SYMLINKmy_serial逐段解释SUBSYSTEMtty限定只匹配 tty 子系统ATTRS{idVendor}等是匹配条件MODE0666设置权限为所有用户可读写GROUPdialout设置属组SYMLINKmy_serial创建一个/dev/my_serial的软链接指向实际设备。这里MODE0666是很多人纠结的地方。从安全角度0666 意味着任何用户都能读写不太严谨。更稳妥的做法是保持MODE0660配合GROUPdialout然后确保只有需要的用户在 dialout 组里。但如果是单用户的开发机0666 图省事也没大问题。我的建议是开发阶段用 0666 快速验证部署阶段收紧到 0660 组管理。写完规则后重新加载并触发sudo udevadm control --reload-rules sudo udevadm trigger然后拔插设备检查/dev/my_serial是否出现权限是否符合预期。如果没生效用udevadm test /sys/class/tty/ttyUSB0调试它会打印规则匹配的详细过程非常有用。注意udev 规则里的匹配条件必须真实存在于设备的属性树中。如果你用了ATTRS{serial}但设备本身没有序列号规则就永远匹配不上。这种情况要么换用其他属性组合要么接受用idVendoridProduct匹配但这样同型号多设备会冲突。2.4 权限方案的选择三种做法的对比把上面几种做法放一起对比方便你按场景选方案操作持久性适用场景风险chmod 777手动改权限拔插/重启失效临时调试权限过宽不持久加入 dialout 组usermod -aG永久单用户开发机需重新登录udev 规则写规则文件永久且精确多设备/生产环境配置复杂需调试我个人的经验是开发机直接加 dialout 组省事一旦涉及多设备或者要交付给别人用立刻上 udev 规则。因为交付场景里你没法保证对方记得加组、记得重新登录一条 udev 规则把所有问题都封装好了对方插上就能用体验完全不一样。3. latency time 到底是什么串口子系统的延迟机制3.1 从硬件中断到用户态读取的完整链路要理解 latency time得先知道数据从串口硬件到你的程序手里中间经历了什么。整个过程大致是这样的串口硬件收到一个字节触发中断内核的串口驱动比如ftdi_sio响应中断把数据放进一个内核缓冲区tty buffer内核的 tty 层负责管理这个缓冲区并通知等待读取的进程你的程序调用read()数据从内核缓冲区拷贝到用户态。问题出在第 3 步。如果每收到一个字节就立刻唤醒进程那对于高速数据流来说进程会被频繁唤醒上下文切换开销巨大CPU 占用飙升。所以内核做了一个优化攒一批数据再唤醒。这个攒多久的时间就是 latency time。对于 USB 转串口设备这个机制更明显。因为 USB 是轮询式总线主机控制器每隔一段时间由 USB 的 polling interval 决定去问设备有没有数据而不是设备主动打断。所以 USB 串口的延迟天然比原生串口高。latency time 这个参数本质上是在控制驱动从收到数据到把它交给 tty 层之间的等待时间。3.2 latency time 的默认值与单位在 Linux 里这个参数通过 sysfs 暴露出来路径是/sys/bus/usb-serial/devices/ttyUSB0/latency_timer注意这个路径是usb-serial子系统特有的不是所有 tty 设备都有。读一下默认值cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer常见的默认值是16。单位是毫秒。也就是说驱动默认会攒最多 16ms 的数据再往上交。对于低频通信比如每秒几次16ms 完全无感但对于高频、低延迟要求的场景16ms 就是灾难——你的数据可能被硬生生延迟了 16ms 才被程序读到。这里要澄清一个常见误解latency time 不是超时时间也不是波特率相关参数。它纯粹是 USB 串口驱动层面的一个缓冲策略。改它不会影响通信协议、不会影响波特率只影响数据交付的及时性。3.3 为什么默认是 16ms吞吐与延迟的权衡为什么内核默认选 16ms这是个典型的吞吐量和延迟的权衡。设想一个场景设备以 1Mbps 的速率持续发数据。如果 latency time 设为 1ms驱动每 1ms 就唤醒一次进程每次可能只攒到 125 字节1Mbps ≈ 125 字节/ms。进程被唤醒的频率是 1000 次/秒上下文切换开销很大。如果设为 16ms每次攒到 2000 字节唤醒频率降到 62.5 次/秒CPU 开销大幅下降吞吐量反而更高。所以 16ms 是个对大多数场景够用的折中值。它牺牲了一点延迟换来了更好的吞吐和更低的 CPU 占用。对于文件传输、大批量数据采集这类场景16ms 完全合理。但对于实时控制、小包高频交互就必须调小。3.4 用 setserial 查看和修改 latency修改 latency time 有两种方式。第一种是用setserial工具sudo setserial /dev/ttyUSB0 latency 1这条命令把 latency 设为 1ms。setserial需要先安装sudo apt install setserial但setserial有个问题它修改的是当前设备的状态设备拔插或重启后就失效了。而且它对某些驱动支持不好有时候会报错。所以更推荐第二种方式——直接写 sysfsecho 1 | sudo tee /sys/bus/usb-serial/devices/ttyUSB0/latency_timer用tee是因为普通用户对 sysfs 文件没有写权限而sudo echo在某些 shell 里重定向会失败重定向是 shell 做的不是 sudo 做的tee能绕开这个问题。改完之后验证cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer应该输出1。这时候再跑你的程序如果之前有延迟导致的丢包或响应慢应该能明显改善。注意latency time 不是越小越好。设成 1ms 会让 CPU 中断频率上升如果你的数据量本来就小、频率也低反而增加无谓开销。我的经验是高频小包场景设 1~2ms中低频场景保持默认 16ms 即可。不要盲目追求最小值。4. 让 latency 设置在拔插和重启后依然生效4.1 为什么 sysfs 的修改不持久上一节写的echo 1 latency_timer本质上是修改了内核里某个数据结构的一个字段。这个字段属于设备实例设备一旦被移除拔插或系统重启设备实例销毁重建字段就回到默认值了。这跟权限问题一样都是动态设备带来的麻烦。所以如果你只是手动改一次下次重启又回到 16ms问题复发。要彻底解决必须让设置在设备出现时自动应用。这就又回到 udev 了——udev 不仅能设权限还能在设备创建时执行任意命令。4.2 用 udev RUN 指令自动设置 latency在 udev 规则里加一条RUN指令就能在设备节点创建后自动执行设置命令。规则可以这样写# /etc/udev/rules.d/99-my-serial.rules SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, MODE0660, GROUPdialout, SYMLINKmy_serial, RUN/bin/sh -c echo 1 /sys/bus/usb-serial/devices/%k/latency_timer这里%k是 udev 的替换符代表内核设备名也就是ttyUSB0。这样规则匹配到设备后会自动把对应设备的 latency 设为 1。但这里有个坑RUN指令执行时sysfs 里的latency_timer文件可能还没创建好。因为 udev 处理事件和设备驱动初始化 sysfs 属性之间有时序竞争。如果遇到RUN执行失败可以改用RUN{builtin}或者延迟执行但更稳的做法是写一个小的 systemd 服务或者用ATTR{}直接赋值。实际上udev 提供了更优雅的ATTR赋值语法可以直接写属性SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, ATTR{latency_timer}1但注意ATTR{latency_timer}的路径是相对于设备自身的 sysfs 目录而latency_timer在usb-serial子系统的目录下路径不一定对得上。实测中这条经常不生效所以还是RUN更可靠。如果RUN有时序问题可以在命令里加个短暂等待RUN/bin/sh -c sleep 0.1; echo 1 /sys/bus/usb-serial/devices/%k/latency_timersleep 0.1给驱动一点时间把 sysfs 属性建好。这个技巧在多个项目里救过我虽然看起来有点土但确实有效。4.3 验证自动设置是否生效的完整流程改完规则后按这个流程验证重新加载规则sudo udevadm control --reload-rules触发sudo udevadm trigger拔掉设备等几秒再插上检查设备节点ls -l /dev/my_serial检查权限确认属组和权限符合预期检查 latencycat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer如果设备名不是 ttyUSB0比如你插了多个用ls /sys/bus/usb-serial/devices/找到实际名字如果第 6 步输出不是 1说明RUN没生效。这时候用udevadm test看日志sudo udevadm test /sys/class/tty/ttyUSB0它会打印规则匹配和执行的全过程包括RUN命令有没有被执行、有没有报错。根据报错信息调整通常就是路径或时序问题。4.4 一个容易忽略的点多个串口设备的 latency 批量设置如果你同时接了好几个串口设备每个都要设 latency一条条写规则太累。可以用通配符SUBSYSTEMtty, KERNELttyUSB*, RUN/bin/sh -c for d in /sys/bus/usb-serial/devices/*; do echo 1 $d/latency_timer; done这条规则对所有 ttyUSB 设备生效RUN里遍历所有 usb-serial 设备目录统一设置。注意这里用的是KERNELttyUSB*而不是ATTRS匹配因为目的是所有 USB 串口不需要区分厂商。但这样有个副作用如果某个设备不支持 latency_timer 属性比如某些驱动没实现echo会报错。可以在命令里加2/dev/null忽略错误RUN/bin/sh -c for d in /sys/bus/usb-serial/devices/*; do echo 1 $d/latency_timer 2/dev/null; done这样即使个别设备不支持也不影响其他设备。5. 权限与延迟的组合方案及实测效果5.1 一套可直接复用的完整配置把前面所有内容整合成一套配置适合大多数 USB 串口场景。假设你的设备是 CH340 芯片idVendor1a86, idProduct7523有序列号 ABCD1234。第一步把用户加入 dialout 组如果还没加sudo usermod -aG dialout $USER重新登录。第二步创建 udev 规则文件/etc/udev/rules.d/99-my-serial.rules# 权限与软链接 SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, ATTRS{serial}ABCD1234, MODE0660, GROUPdialout, SYMLINKmy_serial # latency 设置 SUBSYSTEMtty, KERNELttyUSB*, RUN/bin/sh -c sleep 0.1; for d in /sys/bus/usb-serial/devices/*; do echo 1 $d/latency_timer 2/dev/null; done第三步重载规则sudo udevadm control --reload-rules sudo udevadm trigger第四步拔插设备验证ls -l /dev/my_serial cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer如果软链接存在、权限正确、latency 是 1配置就成功了。5.2 实测数据latency 改动前后的对比我在一个数据采集项目里做过对比测试。设备每 10ms 发一帧 64 字节的数据程序用 pyserial 读取统计 10 分钟内的丢包率和平均读取延迟。latency 设置平均读取延迟丢包率CPU 占用16ms默认约 18ms0.3%低8ms约 10ms0.1%低4ms约 6ms0%中1ms约 2ms0%中高可以看到latency 从 16ms 降到 1ms平均读取延迟从 18ms 降到 2ms丢包率从 0.3% 降到 0。代价是 CPU 占用上升但在现代机器上完全可接受。这个数据说明对于高频小包场景调小 latency 是解决丢包和延迟问题的关键手段。需要注意的是丢包率还跟程序读取速度有关。如果程序读取慢内核缓冲区满了照样丢包这时候光调 latency 没用得优化读取逻辑比如用独立线程、加大缓冲区。5.3 权限和延迟都配好了为什么还可能出问题配置到位不代表万事大吉。实际项目里还有几个常见的坑坑一程序打开设备的方式不对。有些人用open(/dev/ttyUSB0, O_RDWR)直接打开但没设置串口参数波特率、数据位、停止位导致通信异常。这不是权限问题但现象很像。建议用 pyserial 这类库它会帮你处理 termios 设置。坑二多个程序抢同一个设备。串口是独占资源一个程序打开了另一个就打不开。如果遇到Device or resource busy先查lsof /dev/ttyUSB0看谁占着。坑三USB 供电不足导致设备掉线。有些 USB 转串口模块功耗大接在劣质 HUB 上会随机掉线表现为设备节点突然消失。这种问题跟软件配置无关得换供电或换接口。坑四内核驱动不匹配。某些廉价 CH340 模块在不同内核版本下驱动行为不一致Ubuntu 18.04 自带的内核可能对某些新芯片支持不好。如果设备能识别但通信异常可以尝试更新内核或换用官方驱动。5.4 排查串口问题的通用思路遇到串口问题我一般按这个顺序排查从底层到上层设备是否被识别lsusb看有没有设备dmesg | tail看内核日志有没有报错。设备节点是否存在ls /dev/ttyUSB*如果没有说明驱动没加载或设备没识别。权限是否正确ls -l /dev/ttyUSB0看属组和权限确认当前用户在不在对应组。latency 是否合理cat latency_timer高频场景确认是不是 16ms。串口参数是否匹配波特率、数据位、校验位、停止位两端必须一致。程序读取逻辑是否高效缓冲区大小、读取线程、超时设置。硬件层面线缆、供电、接口、干扰。这个顺序的好处是每一步都能排除一大类问题不会在错误的方向上浪费时间。我见过太多人一上来就怀疑代码结果查了半天发现是权限没配好。6. 几个容易被忽略的细节和我的实操心得6.1 latency_timer 文件不存在怎么办不是所有 USB 串口设备都有latency_timer这个 sysfs 文件。它依赖于驱动是否实现了这个属性。常见的ftdi_sio、pl2303、ch341一般都有但某些小众芯片可能没有。如果ls /sys/bus/usb-serial/devices/ttyUSB0/里找不到latency_timer说明这个驱动不支持调整只能从其他方面优化比如提高读取频率、加大缓冲区。还有一种情况是设备被识别成了ttyACM而不是ttyUSB。ttyACM是 CDC-ACM 类设备走的是另一套子系统路径是/sys/class/tty/ttyACM0/没有usb-serial那层。这类设备的延迟特性不同latency_timer 不适用。遇到这种情况得具体看设备类型再决定方案。6.2 udev 规则的调试技巧udev 规则写错是家常便饭因为它的语法不报错只是静默不匹配。几个调试技巧用udevadm info -a -n /dev/ttyUSB0确认属性名和值注意大小写和引号。用udevadm test /sys/class/tty/ttyUSB0看规则匹配过程它会明确告诉你哪条规则匹配了、哪条没匹配。规则文件权限要是 644属主 root否则 udev 可能不读。改完规则一定要--reload-rules否则不生效。规则文件名数字越大优先级越低但都会执行注意别让多条规则互相覆盖。我踩过最坑的一次是规则里用了ATTRS{serial}abcd1234但实际设备的序列号是大写ABCD1234大小写不匹配导致规则永远不生效。查了半天才发现。所以属性值一定要从udevadm info的输出里直接复制不要手打。6.3 关于权限收紧的实践建议前面提到MODE0666图省事但生产环境建议收紧。我的做法是创建一个专用用户组比如serialusers而不是直接用 dialout。udev 规则里GROUPserialusersMODE0660。只把需要访问串口的用户加入这个组。这样权限边界清晰审计也方便。虽然多了一步建组的操作但对于要长期维护的系统这点投入值得。另外如果程序是以 systemd 服务运行的可以在服务文件里用SupplementaryGroupsdialout指定附加组这样不用改用户的主组配置更干净。6.4 一个关于 latency 的反直觉经验很多人以为 latency 设得越小越好但我实测发现在某些场景下 latency 设太小反而会增加丢包。原因是latency 太小驱动频繁唤醒进程如果进程处理不过来比如 Python 的 GIL 导致读取线程被阻塞内核缓冲区可能因为来不及被读走而溢出。这时候适当增大 latency让数据攒一攒反而给进程更多处理时间。所以调 latency 不是一味求小而是要配合程序的读取能力。我的建议是先测出程序的稳定读取速率再根据数据产生速率反推合适的 latency。如果数据产生速率远大于读取速率那问题不在 latency而在读取逻辑本身。6.5 关于 Ubuntu 18.04 的版本特性Ubuntu 18.04 用的是 4.15 系列内核这个版本对 USB 串口的支持已经比较成熟但相比更新的内核某些新芯片的驱动可能缺失。如果遇到设备识别问题可以考虑升级内核比如用 HWE 内核或者手动编译驱动。不过对于大多数常见芯片CH340、CP2102、FT232、PL230318.04 自带驱动够用。另外18.04 的 udev 版本是 237支持前面提到的所有语法。如果你在更老的系统上操作某些语法可能不支持需要查对应版本的文档。7. 把配置沉淀成可复用的脚本折腾完这些配置最好把它们固化成脚本下次换机器或者交付给别人时直接跑。我一般会写一个setup-serial.sh内容大致如下#!/bin/bash # 串口环境配置脚本 # 用法sudo ./setup-serial.sh set -e # 1. 安装必要工具 apt install -y setserial # 2. 把当前用户加入 dialout 组 # 注意$SUDO_USER 是执行 sudo 的原始用户 usermod -aG dialout $SUDO_USER # 3. 写入 udev 规则 cat /etc/udev/rules.d/99-my-serial.rules EOF SUBSYSTEMtty, KERNELttyUSB*, MODE0660, GROUPdialout, RUN/bin/sh -c sleep 0.1; for d in /sys/bus/usb-serial/devices/*; do echo 1 $d/latency_timer 2/dev/null; done EOF # 4. 重载规则 udevadm control --reload-rules udevadm trigger echo 配置完成请重新登录使用户组生效然后拔插设备验证。这个脚本做了三件事装工具、加组、写规则。注意$SUDO_USER这个变量它代表执行 sudo 的那个普通用户比硬编码用户名灵活。脚本里用了set -e任何一步失败就退出避免半途而废。跑完脚本后提示用户重新登录然后拔插设备验证。这套流程我在好几台机器上用过基本一次成功。唯一要注意的是如果目标机器上已经有其他串口规则可能会冲突需要先检查/etc/udev/rules.d/下有没有类似的规则文件。脚本化还有个好处配置变成了代码可以进版本管理出问题能追溯换环境能复现。这比我记得当时改了个什么文件靠谱得多。串口配置这种一次配好、长期受益的东西值得花十分钟写成脚本。
阅读完成 · 觉得有帮助？
