1.

为什么你的Jetson认不出USB串口设备？

最近在Jetson

AGX

Orin上折腾一个USB转串口的小玩意儿，明明在Windows电脑上插上就能用，设备管理器里“端口”那一栏立马就蹦出来一个COM口，可一到Jetson上，就像石沉大海，ls

/dev/ttyUSB*啥也找不到。

这种感觉，就像你拿着钥匙，却怎么也打不开自家的门，特别让人抓狂。

其实，这个问题在嵌入式开发、机器人调试，或者连接各种传感器、控制器的时候特别常见。

很多朋友第一次接触Jetson这类嵌入式平台，很容易忽略一个关键点：Linux系统不像Windows那样有庞大的、预装的通用驱动库。

简单来说，CH340是一个成本非常低、应用极其广泛的USB转串口芯片，很多国产的Arduino开发板、ESP8266/ESP32模块、3D打印机主板都爱用它。

在Windows下，你通常需要去官网下载一个驱动安装包，点几下“下一步”就搞定了。

但在Linux，尤其是像Nvidia

Jetson这样基于特定内核（比如Tegra内核）的嵌入式系统上，情况就复杂多了。

系统内核默认可能没有把这个芯片的驱动编译进去，所以即便你用lsusb命令能看到设备（通常会显示类似Bus

001

converter的信息），系统也不知道该怎么和它“对话”，自然也就不会在/dev有没有更新，确保你能买到最新版本的工具。

执行完这两条命令，你的“工具箱”就齐备了。

系统可能会提示你输入用户密码，因为sudo意味着以管理员权限运行。

2.2

第二步：获取“图纸”——下载驱动源码

工具有了，接下来需要驱动的“设计图纸”，也就是源代码。

这里我们使用一个在开源社区维护得比较好的版本。

在终端里继续输入：

git
clone
https://github.com/WCHSoftGroup/ch341ser_linux
ch341ser_linux/driver

• git

  clone

  ...：这条命令会从GitHub上把整个代码仓库复制到你当前所在的。

  因为编译驱动所需的“说明书”（Makefile）和源代码文件（.c文件）都在这个子下，直接输入一个简单的命令：

  make

  按下回车后，你会看到屏幕上飞速滚动很多行输出信息，这都是gcc编译器在工作。

  如果一切顺利，最后几行不会有“error”字样，并且会在当前，通常是/lib/modules/$(uname

  -r)/kernel/drivers/usb/serial/。

  你可以用ls

  /lib/modules/$(uname

  -r)/kernel/drivers/usb/serial/命令查看，现在应该能看到ch341.ko了。

• 运行depmod命令，更新模块的依赖关系信息。

安装完成后，我们还需要手动加载一次这个模块到运行中的内核：

sudo
modprobe
ch341

modprobe命令比insmod更智能，它会自动处理模块的依赖关系。

执行成功后不会有明显提示，但你可以用lsmod

grep

ch341来检查，如果看到ch341一行，就说明驱动已经成功加载到内存里了。

现在，激动人心的时刻到了！把你的CH340设备重新插拔一下，然后立刻执行：

ls
/dev/ttyUSB*

你应该能看到类似/dev/ttyUSB0的设备文件出现了！恭喜你，驱动安装成功了。

你可以用sudo

dmesg

-20查看内核最新的日志，通常会在末尾看到系统识别并创建该设备的信息。

3.

搞定那个烦人的“服务冲突”：brltty

按照上面的步骤，很多朋友的设备应该已经能正常工作了。

但有一部分人可能会遇到一个更诡异的情况：驱动明明装好了，lsmod也显示加载了，可/dev/ttyUSB0就是一闪而过，或者根本不出来，甚至变成了/dev/ttyACM0之类的名字。

用ls

/dev/ttyUSB*查看，发现设备文件其实存在，但属于一个叫brltty的用户或组，普通用户没权限读写。

这个问题我踩过坑，折腾了好久才发现“元凶”——brltty服务。

3.1

brltty是什么？它为什么“抢”我的串口？

brltty全称是

Braille

TTY，它是一个为视障人士提供盲文显示支持的守护进程（服务）。

这个服务的设计初衷是好的，但它有一个“霸道”的行为：在系统启动时，它会自动扫描并尝试占用所有它认为可能是盲文显示器的串口设备（包括USB转串口）。

对于绝大多数做开发的Jetson用户来说，这个服务是完全用不到的。

但它一占坑，你的应用程序就无法打开/dev/ttyUSB0，会提示“Permission

denied”或者“Device

busy”。

这就像你去停车场，发现自己的固定车位被一辆不认识的车占了，而且车主还不在。

3.2

如何一劳永逸地解决冲突？

解决思路很简单：让这个服务不要自动启动，更彻底一点，直接请它离开。

根据你的需求，可以选择下面两种方法之一。

方法一：禁用服务（推荐，可逆）如果你不确定以后会不会用到盲文设备，或者想保持系统纯净，可以先禁用服务。

#
sudo
brltty.service

执行disable命令后，系统会告诉你已经移除了相关的符号链接，下次重启就不会再启动了。

这个方法只是阻止了它的自动行为，软件包还留在系统里，万一哪天需要可以再enable回来。

方法二：彻底卸载软件包如果你非常确定你的Jetson设备永远不会连接盲文显示器（比如它被装在机器人肚子里或者智能摄像头里），那可以直接卸载，一了百了。

sudo
apt
brltty

purge命令比remove更彻底，不仅删除软件，还会清理相关的配置文件。

处理完brltty之后，务必重启你的Jetson设备，或者至少重新插拔你的CH340

USB设备。

重启是为了确保所有更改生效，内核能在一个“干净”的环境里重新识别和创建设备文件。

再次检查/dev/ttyUSB0，现在它应该乖乖地在那里，并且权限也恢复正常了。

4.

进阶排查与性能优化

驱动装好了，冲突解决了，是不是就万事大吉了？在实际长期使用中，你可能还会遇到一些“小毛刺”。

这里分享几个我积累下来的进阶经验和排查技巧。

4.1

驱动加载自动化：避免每次重启都手动modprobe

你有没有发现，每次重启Jetson后，虽然驱动文件在，但还是要手动执行一次sudo

modprobe

ch341才能用？这是因为我们只是临时加载了模块到内存，重启后就没了。

为了让系统每次启动都自动加载，我们需要将模块名加入“启动加载列表”。

#
编辑模块加载配置文件
/etc/modules-load.d/modules.conf

（如果你习惯用vim，把nano换成vim即可）

在打开的文件末尾，另起一行，添加：

ch341

然后按Ctrl+X，再按Y确认，回车保存退出。

这个操作的意思是告诉系统：“在启动的早期阶段，记得把ch341这个模块给我加载上。

”

这样，以后每次开机，你的CH340设备一插上就能被识别，无需额外操作。

4.2

串口权限问题：让普通用户也能轻松操作

默认情况下，/dev/ttyUSB0的设备文件属于root用户和dialout组。

如果你每次都要用sudo来运行你的Python或C++串口程序，会非常麻烦且不安全。

有两种方法解决：

方法一：将当前用户加入dialout组

sudo
usermod
$USER

执行这条命令后，你需要完全注销当前用户，然后重新登录，用户组变更才会生效。

之后，你就可以不用sudo直接读写串口了。

方法二：使用udev规则创建固定且带权限的设备这个方法更强大，可以实现：1）设备固定名称（比如你的设备永远是/dev/my_ch340）；2）自动设置权限。

首先，查看你设备的唯一属性：

lsusb
1a86:7523
"iSerial|iProduct|iManufacturer"

找到idVendor(1a86)

以及iSerial（如果有）。

然后创建udev规则文件：

sudo
nano
/etc/udev/rules.d/99-my-ch340.rules

添加如下内容（假设序列号是12345678）：

SUBSYSTEM=="tty",
ATTRS{idVendor}=="1a86",
ATTRS{idProduct}=="7523",
ATTRS{serial}=="12345678",
SYMLINK+="my_ch340",
MODE="0666"

保存后，重新加载udev规则并重新插拔设备：

sudo
udevadm
trigger

现在，除了/dev/ttyUSB0，还会出现一个/dev/my_ch340的符号链接，并且权限是所有人都可读写。

4.3

高速数据传输下的稳定性调优

当你用CH340进行高速数据传输（比如超过115200的波特率）时，可能会遇到数据丢失或错误。

这通常不是驱动问题，而是USB和串口缓冲区设置的问题。

这里有两个内核参数可以尝试调整。

首先，我们可以查看当前驱动使用的参数：

sudo
cat
/sys/bus/usb-serial/drivers/ch341-uart/parameters

常见的可调参数是latency_timer（单位是毫秒），它决定了USB批量传输的延迟。

默认值可能比较大（比如16ms），对于高速数据来说太慢了。

我们可以创建一个脚本来在加载模块时设置它：

sudo
nano
/etc/modprobe.d/ch341.conf

添加：

options
ch341
latency_timer=2

保存后，需要先卸载模块再重新加载才能生效：

sudo
rmmod
ch341

你可以尝试将latency_timer设置为

等较小的值，并在你的应用场景下测试稳定性。

数值越小，延迟越低，USB传输更频繁，对CPU占用可能稍有增加，但实时性更好。

另一个影响性能的是硬件流控。

CH340芯片是支持RTS/CTS硬件流控的，但很多便宜的USB转串口线只接出了RX、TX和GND三根线。

如果你的设备支持硬件流控，确保在代码（如Python的pyserial）或串口工具（如minicom）中正确启用它，这能极大避免因缓冲区满而导致的数据丢失。

在minicom中，可以在配置菜单（Ctrl+A,

port

setup”里将硬件流控设置为“Yes”。

最后，如果经过以上优化仍然遇到偶发问题，建议在代码中增加重试机制和校验（如CRC校验），这是保证通信可靠性的最后一道防线。

毕竟，硬件本身（尤其是那些几块钱的模块）的稳定性也是有差异的。

多买一两个不同批次的模块做备用和测试，也是嵌入式开发中的常态。