我把这块经验完整写出来了从驱动到底层调试一条线捋清楚你照着排查基本都能解决。1. 问题现象插上开发板Ubuntu里就是找不到设备文件我一直觉得串口这玩意儿是嵌入式开发里最“基础但也最磨人”的一环。很多朋友拿到开发板第一步不是点灯而是先想办法把串口打通。因为只有串口通了你才能看到bootloader的打印、内核的日志才能跟板子“对话”。但麻烦也往往出在这一步把开发板的USB转串口线插到电脑上Windows那边设备管理器里还能看到“COM3”“COM4”换到Ubuntu虚拟机或者实体机里敲ls /dev/ttyUSB*或者ls /dev/ttyACM*结果一片空白什么都找不到。这种时候新手的第一反应是“驱动没装吧”。但实际上在Linux系统里串口设备找不到对应的设备文件原因往往比“驱动没装”复杂得多。可能是线的问题可能是内核模块没加载也可能是权限不够甚至是你压根看错了设备名。我最早在给一块全志T113开发板调试时也踩过这个坑。当时手头用的是一条CH340芯片的USB转串口线插上去之后lsusb能看到设备但/dev下就是没有ttyUSB0。折腾了一下午最后才发现是内核模块没自动加载手动modprobe ch340之后设备文件立刻出现了。这种经历我想很多人都有过。所以这篇就把“开发板串口连接Ubuntu后找不到设备文件”这个问题的完整排查思路整理出来从底层原理到实际操作从驱动安装到权限配置一次性讲透下次遇到直接照着排查就行。适合谁看刚接触嵌入式Linux的新手、在VMware里装Ubuntu做开发的朋友、以及那些被CH340、CP210x、FTDI这些USB转串口芯片折腾过的老哥。2. 先搞懂串口设备文件的本质再谈解决方案2.1 /dev目录下到底发生了什么很多人一上来就敲命令敲完发现没有就慌。但我建议先花两分钟理解一下Linux的设备和文件的关系。在Linux世界里一切皆文件。串口这种硬件设备在系统里也会被抽象成一个个文件放在/dev目录下。你操作串口本质上就是读写这个文件。常见的串口设备文件名有这么几类/dev/ttyS0、/dev/ttyS1——这是主板上原生串口对应PC主板的COM口嵌入式开发里很少用/dev/ttyUSB0、/dev/ttyUSB1——这是USB转串口芯片比如CH340、CP210x、FTDI枚举出来的设备绝大多数开发板调试串口走的是这个/dev/ttyACM0、/dev/ttyACM1——这是USB CDC ACM类设备比如STM32的USB虚拟串口、某些ESP32板载串口、Arduino等走的是这个。关键点在于这个设备文件不是天生的而是当USB转串口芯片被内核识别并绑定驱动之后由驱动动态创建出来的。所以你找不到设备文件本质上就是芯片没有被内核识别或者识别了但没绑定正确的驱动或者驱动创建了节点但你的用户权限不够压根看不到。理解了这一层后面所有排查步骤就都顺理成章了。2.2 为什么Windows下正常Ubuntu下不行这是一个特别经典的困惑。很多人在Windows设备管理器里能看到COM口说明硬件和线材本身是没问题的。但是一到Ubuntu就找不到原因通常是这么几个第一Windows的驱动是芯片厂商提供的安装包一般会自动装好。而Linux多数情况下用的是内核自带的驱动模块但模块可能没启用、没加载或者被你系统里某个操作给屏蔽了。第二虚拟机场景下USB设备的“直通”没有配置好。你用的是VMware或者VirtualBox宿主机的USB设备默认是不会自动“送”进虚拟机的需要在虚拟机设置里手动添加USB控制器和过滤器把USB设备挂载到虚拟机里。很多人忽略这一步自然在虚拟机里看不到设备。第三权限问题。设备节点创建出来了但默认属于dialout组而当前用户不在这个组里ls /dev的时候可能因为权限不够而无法访问甚至某些终端配置下直接不显示后者少见但确实有。搞清楚这三个方向排查就有了头绪。3. 三板斧快速定位lsusb、dmesg、ls /dev3.1 第一步确认USB设备是否被系统识别把USB转串口线插上开发板再连到电脑USB口之后第一步不是去/dev目录翻而是先确认USB总线层面是否认到了这个设备。打开终端输入lsusb这个命令会列出当前USB总线上所有设备。你需要找的是类似这样的行Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics CH340 serial converter或者是Bus 001 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port再或者Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC如果你能在lsusb里看到芯片厂商和型号恭喜硬件层面是通的。这一步同时也告诉了你芯片用的是哪家的方案后面查驱动就有方向了。如果lsusb里什么都看不到说明USB枚举都没成功那可能是USB线是纯充电线没有数据线芯开发板没有上电开发板的USB转串口电路有问题USB口供电不足。这种情况基本跟软件无关先换线、换USB口、检查板上供电。3.2 第二步查看内核日志驱动是否加载成功接下来看看内核有没有为这个设备加载对应的驱动。用dmesg直接翻内核环形缓冲区这里能看到设备从插入到枚举、到绑定驱动的全过程。dmesg | tail -n 30正常情况你会看到usb 1-2: new full-speed USB device number 4 using xhci_hcd usb 1-2: New USB device found, idVendor1a86, idProduct7523 usb 1-2: New USB device strings: Mfr1, Product2, SerialNumber3 usb 1-2: Product: USB2.0-Serial usb 1-2: Manufacturer: QinHeng Electronics usb 1-2: SerialNumber: 00A00000000 ch341 1-2:1.0: ch341-uart converter detected usb 1-2: ch341-uart converter now attached to ttyUSB0看到最后一行now attached to ttyUSB0说明驱动已经加载设备节点也创建好了。这时候ls /dev/ttyUSB0肯定是存在的。但如果你只看到枚举成功却没有“usb 1-2: ch341-uart converter now attached to ttyUSB0”这一行说明内核没能成功绑定驱动。常见情况是dmesg里出现类似usb 1-2: ch341-uart converter now attached to ttyUSB0根本没有或者usb 1-2: usbfs: interface 0 claimed by cdc_acm while ch341 sets config #1这说明驱动冲突了芯片被另一个驱动抢占。3.3 第三步查设备节点确认最终结果如果没有问题这时候再执行ls -l /dev/ttyUSB*或者ls -l /dev/ttyACM*看到类似这样的输出crw-rw---- 1 root dialout 188, 0 7月 19 10:30 /dev/ttyUSB0就说明设备节点已经创建好了。注意这里有一个细节这个文件的权限是crw-rw----所有者是root所属组是dialout。也就是说如果不是root用户且不在dialout组里你是无法读写这个设备的。那么下一步就来了把当前用户加入dialout组。sudo usermod -a -G dialout $USER执行完需要重新登录一次或者重启虚拟机组权限才会生效。这里多说一句这一步很多人都漏了导致minicom或串口助手能打开设备但发不出数据或者直接报permission denied。4. 驱动层面深挖CH340、CP210x、FTDI、CDC ACM4.1 CH340/CH341最常见也最容易出幺蛾子CH340几乎是国内开发板的标配正点原子、野火很多板载USB转串口都是这个方案。它对应的Linux内核驱动叫ch341对就是少了一个0从内核2.6.24开始就内置了。但问题在于某些精简版内核或者自行裁剪的内核里这个模块可能没有被编译进去或者被设为m模块但没自动加载。确认方法lsmod | grep ch341如果没有任何输出说明模块没加载。手动加载sudo modprobe ch341再查lsmod或者直接看/dev/ttyUSB0是否出现。如果modprobe报错找不到模块说明内核里压根没这个驱动。这时候要么换一个完整版内核要么手动编译驱动。好在对绝大多数桌面版Ubuntu22.04、24.04来说ch341驱动都是自带的不太会遇到编译驱动这种终极玩法。顺带提一嘴如果插上去之后dmesg里出现“usbfs: interface 0 claimed by cdc_acm while ch341 sets config #1”这种冲突说明内核把设备识别成了CDC ACM类。可以试着禁用cdc_acm模块再重新加载ch341sudo modprobe -r cdc_acm sudo modprobe ch341但这种情况不常见一般出现在某些特殊的USB转串口线芯片内置了CDC ACM固件。4.2 CP210xSilicon Labs的方案模块名容易被忽略CP2102、CP2104这类芯片在ESP32开发板、以及不少工业级调试工具里很常见。对应的内核模块叫cp210x。排查方法跟CH340一样lsmod | grep cp210x sudo modprobe cp210x加载成功之后设备文件同样是/dev/ttyUSB0。有一个细节如果你同时插了多片USB转串口芯片设备文件编号不一定是ttyUSB0可能是ttyUSB1、ttyUSB2。这时候用ls -l /dev/ttyUSB*看或者用udevadm info /dev/ttyUSB1查看具体是哪个设备。4.3 FTDI工业级的选择驱动一般没问题FT232、FT2232这些是FTDI家的经典芯片在高端开发板、仿真器、以及一些老设备上用得很多。对应的内核模块叫ftdi_siolsmod | grep ftdi_sio sudo modprobe ftdi_sioFTDI芯片在Linux下的兼容性通常是最好的基本插上就能用。但要注意市面上有不少“山寨FTDI”芯片某些内核版本会对这类芯片做识别拦截——插上去之后设备直接不被枚举因为内核装了“黑名单”。这个比较坑但如果你用的是原装芯片或者正规开发板基本不会遇到。4.4 CDC ACMSTM32虚拟串口、ESP32-C3等原生USB场景如果你用的不是USB转串口线而是开发板上的USB口直接引出虚拟串口功能比如STM32的USB_CDC例程、ESP32-S3的原生USB那么对应的设备节点不是ttyUSB0而是ttyACM0。对应的驱动模块是cdc_acmlsmod | grep cdc_acm这个模块绝大多数发行版默认是编译进内核的一般不需要手动处理。唯一需要注意的是ttyACM0和ttyUSB0的读写行为在某些串口工具下有差异比如minicom里需要手动配置硬件流控为None否则可能无法正常通信。5. 权限、虚拟机和udev规则三个隐藏大坑5.1 dialout组权限别等出了问题才想起来前面提到了dialout组这里再展开一下。Linux下串口设备默认属于dialout或者uucp组不同发行版不一样Ubuntu是dialout。用户在访问设备之前必须在组里。否则用minicom打开会直接报错Cannot open /dev/ttyUSB0: Permission denied解决方式sudo usermod -a -G dialout $USER但重点来了执行完这个命令之后必须注销重新登录或者重启系统组权限才会重新生效。很多人卡在这一步就是因为没重新登录一直以为自己没加成功。如果你实在不想重新登录有一个临时的替代方案测试用够了sudo chmod 666 /dev/ttyUSB0这样所有用户都有读写权限了。但注意设备节点重新插拔之后权限会恢复默认这只适合临时测试。5.2 VMware虚拟机别忘了把USB设备“送”进去很多人的Ubuntu是装在VMware里的这时候遇到找不到设备首先要排查的反而是虚拟机有没有把USB设备直通进去。VMware默认情况下宿主机插入的USB设备会优先被宿主机捕获只有当你手动把设备“连接”到虚拟机里虚拟机才能看得到。操作步骤打开VMware在虚拟机窗口右下角找到USB图标或者菜单栏“虚拟机”-“可移动设备”下拉菜单里找到你的USB转串口设备比如USB2.0-Serial点击“连接”此时设备会从宿主机“断开”转而被虚拟机接管。连接成功之后lsusb里就能看到设备了然后继续走3.1的步骤。还有一个前置条件虚拟机的USB控制器必须开启。在“虚拟机设置”里选择“USB控制器”确认勾选了“USB 2.0”或“USB 3.0”。如果用的是USB2.0的芯片2.0和3.0都能兼容但某些老芯片在USB3.0控制器下可能有兼容性问题遇到插了不识别可以试试改成USB2.0。5.3 udev规则让设备名固定写自动化脚本不再玄学等你调通了多个串口设备就会发现另一个痛点ttyUSB0这个编号是内核按枚举顺序分配的不固定。今天插A板是ttyUSB0明天插B板可能就变了写自动化脚本时特别头疼。解决办法是通过udev规则根据USB设备的序列号、供应商ID、产品ID绑定一个固定的软链接。先查看设备的属性udevadm info -a -n /dev/ttyUSB0找到类似ATTRS{serial}、ATTRS{idVendor}、ATTRS{idProduct}的值然后新建一个udev规则文件sudo vi /etc/udev/rules.d/99-usb-serial.rules内容格式KERNELttyUSB*, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, MODE0666, SYMLINKt113_debug保存后重新加载规则sudo udevadm control --reload-rules sudo udevadm trigger再插拔一次设备/dev下就会出现一个/dev/t113_debug软链接直接指向实际的ttyUSB节点。以后用这个固定路径操作串口脚本就稳定多了。6. 应用层验证串口通了没有用工具实测一把6.1 minicom最经典但要先配置找到了设备文件权限也搞定了接下来就是实测串口能不能正常通信。最常用的工具是minicom。安装sudo apt install minicom先启动配置界面sudo minicom -s进入“Serial port setup”按A修改串口设备路径为/dev/ttyUSB0按E修改波特率。开发板调试串口常用的波特率是115200但也有些老型号是57600具体看板卡手册。关键点是如果你用的是USB转串口芯片比如CH340硬件流控必须设为No。否则可能出现能打开设备但是没有任何输出或者输出乱码的情况。设置完成后选择“Save setup as dfl”保存为默认配置然后退出设置界面回到minicom主界面。此时给开发板上电复位正常就能看到bootloader的打印信息了。如果打开设备报错权限不够回到5.1节把权限搞定。如果打开设备后没有任何输出检查以下几点波特率是否和板子匹配开发板的串口TX/RX是否交叉连接如果用的是USB转串口线TX接板子的RXRX接板子的TX开发板是否已经上电启动GND是否共地不共地是新手最常见的翻车原因USB转串口线必须和开发板共地。6.2 串口调试助手图形界面不习惯命令行的人有福了虽然嵌入式开发者大多习惯了命令行但偶尔还是会觉得minicom操作不够直观。Ubuntu下有几个图形化的串口调试工具我常用的是cutecomsudo apt install cutecom cutecom界面比较简洁左边可以选设备、设波特率、数据位/停止位/校验位右边是收发区类似Windows下的串口助手。用起来顺手适合刚开始接触Linux串口的同学。除此之外还有一个叫serialplot的工具可以实时把串口收到的数据画成波形做传感器调试的时候特别好用。如果你在做姿态传感器、GPS模块之类的数据采集可以装一个试试。6.3 用Python直接练手绕过工具代码才是最底层的控制工具始终是别人封装好的真正要理解串口还得用代码直接操作。这里推荐用Python的pyserial库几行代码就能打开串口收发数据pip install pyserial然后写个最简单的测试脚本import serial ser serial.Serial( port/dev/ttyUSB0, baudrate115200, bytesizeserial.EIGHTBITS, parityserial.PARITY_NONE, stopbitsserial.STOPBITS_ONE, timeout1 ) # 发送数据 ser.write(bhello\r\n) # 读取响应 while True: data ser.readline() if data: print(data.decode(utf-8, errorsignore), end)这个脚本可以快速验证串口是否能收能发。如果发送后没有任何回包先确认开发板的串口是否配置为回显模式或者是否真的在等外部数据。这里我有一个使用习惯调串口时永远先做“回环测试”。把USB转串口线的TX和RX短接在一起然后在终端里发什么就能收到什么。如果自发自收成功说明串口链路没问题不成功说明设备/驱动/权限某个环节还有问题。用这种排除法能帮你快速划分责任边界。6.4 stty命令直接查看和修改串口参数有时候不想装额外工具纯命令行里也可以快速配置串口参数。用sttystty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb查看当前串口配置stty -F /dev/ttyUSB0 -a然后用cat直接接收cat /dev/ttyUSB0再用echo发送echo hello /dev/ttyUSB0这种方法特别适合快速确认串口是否通不依赖任何第三方工具。7. 常见问题速查表与终极排查清单说了这么多最后整理一个速查表你在实际调试中可以直接对照着排查。问题现象可能原因排查/解决方式lsusb看不到USB设备线材问题/USB口接触不良/未上电换线、换USB口确认开发板供电正常lsusb能看到/dev下无ttyUSB内核驱动未加载lsmod | grep ch341sudo modprobe ch341dmesg显示驱动被占用cdc_acm与ch341冲突sudo modprobe -r cdc_acm后重新插拔设备文件存在但权限拒绝用户不在dialout组sudo usermod -a -G dialout $USER后重新登录VMware里找不到设备USB设备未直通到虚拟机虚拟机右下角USB图标手动“连接”设备设备有但无任何串口输出TX/RX接反/GND不共地/波特率错误交叉接线、确认共地、核对波特率minicom打开设备失败硬件流控未关闭/权限不足关闭流控检查用户组权限设备文件编号不固定udev默认枚举顺序添加udev规则绑定固定软链接排查时我建议按这个顺序走lsusb确认USB枚举成功dmesg | tail确认驱动加载成功ls -l /dev/ttyUSB*确认设备节点存在groups确认当前用户权限回环测试确认串口链路。走完这五步99%的“找不到设备文件”问题都能定位出来。8. 从串口再往下走一步设备树、Qt交叉编译和板卡挂载串口通了之后开发工作才算真正开始。很多用T113、K230这类板卡的朋友下一步往往是配置网络、挂载文件系统、用Qt交叉编译开发界面程序。这里我补充一点和串口强相关的两个场景。第一个是设备树。如果你的板子上有多个串口你要在Linux里使用其中某一个往往需要查看设备树里对应的uart节点是否被启用。比如T113的设备树文件里sunxi-uart0默认用于调试串口其他的UART默认可能处于disabled状态。你需要把对应的status okay;加上然后重新编译设备树、更新到boot分区重启之后才会出现/dev/ttyS1、/dev/ttyS2这些节点。所以如果你已经摸清了USB转串口的设备节点问题但发现板子上板载的串口ttyS1之类的打不开那就要往设备树方向查了。第二个是Qt交叉编译。这个和串口不是直接相关但几乎是同一批人要做的事。很多朋友问“Qt如何交叉编译生成能在开发板运行的文件”其实核心就三件事交叉编译工具链选对、Qt库用同版本交叉编译、编译产物拷贝到板子上时库路径配置好。用命令行构建时-prefix参数指向sysroot-xplatform指定为linux-arm-gnueabi-g之类的平台这样生成的二进制才能在开发板架构上跑。还有一点在开发板上跑Qt程序时如果要用到串口记得链接Qt5SerialPort模块QT serialport交叉编译的坑更多但那是另一个话题了这里先提个醒只要你的主机Ubuntu串口真正调通了后面通过串口终端在板子上执行命令、挂载主机目录这些操作都会顺利很多。再补充一个和开发板挂载有关的技巧板子跑起来之后很多时候不用来回插拔SD卡或者U盘直接用网络挂载。开发板通过网线和主机连到同一网段后在板子上跑mount -t nfs 192.168.1.100:/home/user/share /mnt这样板子就能直接访问你Ubuntu主机上的目录交叉编译出来的可执行文件放到共享目录里板子上直接运行调试效率高一大截。当然NFS服务端需要先在Ubuntu上装好nfs-kernel-server并配置exports文件这个操作相对成熟网上也有很多教程不多展开了。
我把这块经验完整写出来了从驱动到底层调试一条线捋清楚你照着排查基本都能解决。1. 问题现象插上开发板Ubuntu里就是找不到设备文件我一直觉得串口这玩意儿是嵌入式开发里最“基础但也最磨人”的一环。很多朋友拿到开发板第一步不是点灯而是先想办法把串口打通。因为只有串口通了你才能看到bootloader的打印、内核的日志才能跟板子“对话”。但麻烦也往往出在这一步把开发板的USB转串口线插到电脑上Windows那边设备管理器里还能看到“COM3”“COM4”换到Ubuntu虚拟机或者实体机里敲ls /dev/ttyUSB*或者ls /dev/ttyACM*结果一片空白什么都找不到。这种时候新手的第一反应是“驱动没装吧”。但实际上在Linux系统里串口设备找不到对应的设备文件原因往往比“驱动没装”复杂得多。可能是线的问题可能是内核模块没加载也可能是权限不够甚至是你压根看错了设备名。我最早在给一块全志T113开发板调试时也踩过这个坑。当时手头用的是一条CH340芯片的USB转串口线插上去之后lsusb能看到设备但/dev下就是没有ttyUSB0。折腾了一下午最后才发现是内核模块没自动加载手动modprobe ch340之后设备文件立刻出现了。这种经历我想很多人都有过。所以这篇就把“开发板串口连接Ubuntu后找不到设备文件”这个问题的完整排查思路整理出来从底层原理到实际操作从驱动安装到权限配置一次性讲透下次遇到直接照着排查就行。适合谁看刚接触嵌入式Linux的新手、在VMware里装Ubuntu做开发的朋友、以及那些被CH340、CP210x、FTDI这些USB转串口芯片折腾过的老哥。2. 先搞懂串口设备文件的本质再谈解决方案2.1 /dev目录下到底发生了什么很多人一上来就敲命令敲完发现没有就慌。但我建议先花两分钟理解一下Linux的设备和文件的关系。在Linux世界里一切皆文件。串口这种硬件设备在系统里也会被抽象成一个个文件放在/dev目录下。你操作串口本质上就是读写这个文件。常见的串口设备文件名有这么几类/dev/ttyS0、/dev/ttyS1——这是主板上原生串口对应PC主板的COM口嵌入式开发里很少用/dev/ttyUSB0、/dev/ttyUSB1——这是USB转串口芯片比如CH340、CP210x、FTDI枚举出来的设备绝大多数开发板调试串口走的是这个/dev/ttyACM0、/dev/ttyACM1——这是USB CDC ACM类设备比如STM32的USB虚拟串口、某些ESP32板载串口、Arduino等走的是这个。关键点在于这个设备文件不是天生的而是当USB转串口芯片被内核识别并绑定驱动之后由驱动动态创建出来的。所以你找不到设备文件本质上就是芯片没有被内核识别或者识别了但没绑定正确的驱动或者驱动创建了节点但你的用户权限不够压根看不到。理解了这一层后面所有排查步骤就都顺理成章了。2.2 为什么Windows下正常Ubuntu下不行这是一个特别经典的困惑。很多人在Windows设备管理器里能看到COM口说明硬件和线材本身是没问题的。但是一到Ubuntu就找不到原因通常是这么几个第一Windows的驱动是芯片厂商提供的安装包一般会自动装好。而Linux多数情况下用的是内核自带的驱动模块但模块可能没启用、没加载或者被你系统里某个操作给屏蔽了。第二虚拟机场景下USB设备的“直通”没有配置好。你用的是VMware或者VirtualBox宿主机的USB设备默认是不会自动“送”进虚拟机的需要在虚拟机设置里手动添加USB控制器和过滤器把USB设备挂载到虚拟机里。很多人忽略这一步自然在虚拟机里看不到设备。第三权限问题。设备节点创建出来了但默认属于dialout组而当前用户不在这个组里ls /dev的时候可能因为权限不够而无法访问甚至某些终端配置下直接不显示后者少见但确实有。搞清楚这三个方向排查就有了头绪。3. 三板斧快速定位lsusb、dmesg、ls /dev3.1 第一步确认USB设备是否被系统识别把USB转串口线插上开发板再连到电脑USB口之后第一步不是去/dev目录翻而是先确认USB总线层面是否认到了这个设备。打开终端输入lsusb这个命令会列出当前USB总线上所有设备。你需要找的是类似这样的行Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics CH340 serial converter或者是Bus 001 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port再或者Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC如果你能在lsusb里看到芯片厂商和型号恭喜硬件层面是通的。这一步同时也告诉了你芯片用的是哪家的方案后面查驱动就有方向了。如果lsusb里什么都看不到说明USB枚举都没成功那可能是USB线是纯充电线没有数据线芯开发板没有上电开发板的USB转串口电路有问题USB口供电不足。这种情况基本跟软件无关先换线、换USB口、检查板上供电。3.2 第二步查看内核日志驱动是否加载成功接下来看看内核有没有为这个设备加载对应的驱动。用dmesg直接翻内核环形缓冲区这里能看到设备从插入到枚举、到绑定驱动的全过程。dmesg | tail -n 30正常情况你会看到usb 1-2: new full-speed USB device number 4 using xhci_hcd usb 1-2: New USB device found, idVendor1a86, idProduct7523 usb 1-2: New USB device strings: Mfr1, Product2, SerialNumber3 usb 1-2: Product: USB2.0-Serial usb 1-2: Manufacturer: QinHeng Electronics usb 1-2: SerialNumber: 00A00000000 ch341 1-2:1.0: ch341-uart converter detected usb 1-2: ch341-uart converter now attached to ttyUSB0看到最后一行now attached to ttyUSB0说明驱动已经加载设备节点也创建好了。这时候ls /dev/ttyUSB0肯定是存在的。但如果你只看到枚举成功却没有“usb 1-2: ch341-uart converter now attached to ttyUSB0”这一行说明内核没能成功绑定驱动。常见情况是dmesg里出现类似usb 1-2: ch341-uart converter now attached to ttyUSB0根本没有或者usb 1-2: usbfs: interface 0 claimed by cdc_acm while ch341 sets config #1这说明驱动冲突了芯片被另一个驱动抢占。3.3 第三步查设备节点确认最终结果如果没有问题这时候再执行ls -l /dev/ttyUSB*或者ls -l /dev/ttyACM*看到类似这样的输出crw-rw---- 1 root dialout 188, 0 7月 19 10:30 /dev/ttyUSB0就说明设备节点已经创建好了。注意这里有一个细节这个文件的权限是crw-rw----所有者是root所属组是dialout。也就是说如果不是root用户且不在dialout组里你是无法读写这个设备的。那么下一步就来了把当前用户加入dialout组。sudo usermod -a -G dialout $USER执行完需要重新登录一次或者重启虚拟机组权限才会生效。这里多说一句这一步很多人都漏了导致minicom或串口助手能打开设备但发不出数据或者直接报permission denied。4. 驱动层面深挖CH340、CP210x、FTDI、CDC ACM4.1 CH340/CH341最常见也最容易出幺蛾子CH340几乎是国内开发板的标配正点原子、野火很多板载USB转串口都是这个方案。它对应的Linux内核驱动叫ch341对就是少了一个0从内核2.6.24开始就内置了。但问题在于某些精简版内核或者自行裁剪的内核里这个模块可能没有被编译进去或者被设为m模块但没自动加载。确认方法lsmod | grep ch341如果没有任何输出说明模块没加载。手动加载sudo modprobe ch341再查lsmod或者直接看/dev/ttyUSB0是否出现。如果modprobe报错找不到模块说明内核里压根没这个驱动。这时候要么换一个完整版内核要么手动编译驱动。好在对绝大多数桌面版Ubuntu22.04、24.04来说ch341驱动都是自带的不太会遇到编译驱动这种终极玩法。顺带提一嘴如果插上去之后dmesg里出现“usbfs: interface 0 claimed by cdc_acm while ch341 sets config #1”这种冲突说明内核把设备识别成了CDC ACM类。可以试着禁用cdc_acm模块再重新加载ch341sudo modprobe -r cdc_acm sudo modprobe ch341但这种情况不常见一般出现在某些特殊的USB转串口线芯片内置了CDC ACM固件。4.2 CP210xSilicon Labs的方案模块名容易被忽略CP2102、CP2104这类芯片在ESP32开发板、以及不少工业级调试工具里很常见。对应的内核模块叫cp210x。排查方法跟CH340一样lsmod | grep cp210x sudo modprobe cp210x加载成功之后设备文件同样是/dev/ttyUSB0。有一个细节如果你同时插了多片USB转串口芯片设备文件编号不一定是ttyUSB0可能是ttyUSB1、ttyUSB2。这时候用ls -l /dev/ttyUSB*看或者用udevadm info /dev/ttyUSB1查看具体是哪个设备。4.3 FTDI工业级的选择驱动一般没问题FT232、FT2232这些是FTDI家的经典芯片在高端开发板、仿真器、以及一些老设备上用得很多。对应的内核模块叫ftdi_siolsmod | grep ftdi_sio sudo modprobe ftdi_sioFTDI芯片在Linux下的兼容性通常是最好的基本插上就能用。但要注意市面上有不少“山寨FTDI”芯片某些内核版本会对这类芯片做识别拦截——插上去之后设备直接不被枚举因为内核装了“黑名单”。这个比较坑但如果你用的是原装芯片或者正规开发板基本不会遇到。4.4 CDC ACMSTM32虚拟串口、ESP32-C3等原生USB场景如果你用的不是USB转串口线而是开发板上的USB口直接引出虚拟串口功能比如STM32的USB_CDC例程、ESP32-S3的原生USB那么对应的设备节点不是ttyUSB0而是ttyACM0。对应的驱动模块是cdc_acmlsmod | grep cdc_acm这个模块绝大多数发行版默认是编译进内核的一般不需要手动处理。唯一需要注意的是ttyACM0和ttyUSB0的读写行为在某些串口工具下有差异比如minicom里需要手动配置硬件流控为None否则可能无法正常通信。5. 权限、虚拟机和udev规则三个隐藏大坑5.1 dialout组权限别等出了问题才想起来前面提到了dialout组这里再展开一下。Linux下串口设备默认属于dialout或者uucp组不同发行版不一样Ubuntu是dialout。用户在访问设备之前必须在组里。否则用minicom打开会直接报错Cannot open /dev/ttyUSB0: Permission denied解决方式sudo usermod -a -G dialout $USER但重点来了执行完这个命令之后必须注销重新登录或者重启系统组权限才会重新生效。很多人卡在这一步就是因为没重新登录一直以为自己没加成功。如果你实在不想重新登录有一个临时的替代方案测试用够了sudo chmod 666 /dev/ttyUSB0这样所有用户都有读写权限了。但注意设备节点重新插拔之后权限会恢复默认这只适合临时测试。5.2 VMware虚拟机别忘了把USB设备“送”进去很多人的Ubuntu是装在VMware里的这时候遇到找不到设备首先要排查的反而是虚拟机有没有把USB设备直通进去。VMware默认情况下宿主机插入的USB设备会优先被宿主机捕获只有当你手动把设备“连接”到虚拟机里虚拟机才能看得到。操作步骤打开VMware在虚拟机窗口右下角找到USB图标或者菜单栏“虚拟机”-“可移动设备”下拉菜单里找到你的USB转串口设备比如USB2.0-Serial点击“连接”此时设备会从宿主机“断开”转而被虚拟机接管。连接成功之后lsusb里就能看到设备了然后继续走3.1的步骤。还有一个前置条件虚拟机的USB控制器必须开启。在“虚拟机设置”里选择“USB控制器”确认勾选了“USB 2.0”或“USB 3.0”。如果用的是USB2.0的芯片2.0和3.0都能兼容但某些老芯片在USB3.0控制器下可能有兼容性问题遇到插了不识别可以试试改成USB2.0。5.3 udev规则让设备名固定写自动化脚本不再玄学等你调通了多个串口设备就会发现另一个痛点ttyUSB0这个编号是内核按枚举顺序分配的不固定。今天插A板是ttyUSB0明天插B板可能就变了写自动化脚本时特别头疼。解决办法是通过udev规则根据USB设备的序列号、供应商ID、产品ID绑定一个固定的软链接。先查看设备的属性udevadm info -a -n /dev/ttyUSB0找到类似ATTRS{serial}、ATTRS{idVendor}、ATTRS{idProduct}的值然后新建一个udev规则文件sudo vi /etc/udev/rules.d/99-usb-serial.rules内容格式KERNELttyUSB*, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, MODE0666, SYMLINKt113_debug保存后重新加载规则sudo udevadm control --reload-rules sudo udevadm trigger再插拔一次设备/dev下就会出现一个/dev/t113_debug软链接直接指向实际的ttyUSB节点。以后用这个固定路径操作串口脚本就稳定多了。6. 应用层验证串口通了没有用工具实测一把6.1 minicom最经典但要先配置找到了设备文件权限也搞定了接下来就是实测串口能不能正常通信。最常用的工具是minicom。安装sudo apt install minicom先启动配置界面sudo minicom -s进入“Serial port setup”按A修改串口设备路径为/dev/ttyUSB0按E修改波特率。开发板调试串口常用的波特率是115200但也有些老型号是57600具体看板卡手册。关键点是如果你用的是USB转串口芯片比如CH340硬件流控必须设为No。否则可能出现能打开设备但是没有任何输出或者输出乱码的情况。设置完成后选择“Save setup as dfl”保存为默认配置然后退出设置界面回到minicom主界面。此时给开发板上电复位正常就能看到bootloader的打印信息了。如果打开设备报错权限不够回到5.1节把权限搞定。如果打开设备后没有任何输出检查以下几点波特率是否和板子匹配开发板的串口TX/RX是否交叉连接如果用的是USB转串口线TX接板子的RXRX接板子的TX开发板是否已经上电启动GND是否共地不共地是新手最常见的翻车原因USB转串口线必须和开发板共地。6.2 串口调试助手图形界面不习惯命令行的人有福了虽然嵌入式开发者大多习惯了命令行但偶尔还是会觉得minicom操作不够直观。Ubuntu下有几个图形化的串口调试工具我常用的是cutecomsudo apt install cutecom cutecom界面比较简洁左边可以选设备、设波特率、数据位/停止位/校验位右边是收发区类似Windows下的串口助手。用起来顺手适合刚开始接触Linux串口的同学。除此之外还有一个叫serialplot的工具可以实时把串口收到的数据画成波形做传感器调试的时候特别好用。如果你在做姿态传感器、GPS模块之类的数据采集可以装一个试试。6.3 用Python直接练手绕过工具代码才是最底层的控制工具始终是别人封装好的真正要理解串口还得用代码直接操作。这里推荐用Python的pyserial库几行代码就能打开串口收发数据pip install pyserial然后写个最简单的测试脚本import serial ser serial.Serial( port/dev/ttyUSB0, baudrate115200, bytesizeserial.EIGHTBITS, parityserial.PARITY_NONE, stopbitsserial.STOPBITS_ONE, timeout1 ) # 发送数据 ser.write(bhello\r\n) # 读取响应 while True: data ser.readline() if data: print(data.decode(utf-8, errorsignore), end)这个脚本可以快速验证串口是否能收能发。如果发送后没有任何回包先确认开发板的串口是否配置为回显模式或者是否真的在等外部数据。这里我有一个使用习惯调串口时永远先做“回环测试”。把USB转串口线的TX和RX短接在一起然后在终端里发什么就能收到什么。如果自发自收成功说明串口链路没问题不成功说明设备/驱动/权限某个环节还有问题。用这种排除法能帮你快速划分责任边界。6.4 stty命令直接查看和修改串口参数有时候不想装额外工具纯命令行里也可以快速配置串口参数。用sttystty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb查看当前串口配置stty -F /dev/ttyUSB0 -a然后用cat直接接收cat /dev/ttyUSB0再用echo发送echo hello /dev/ttyUSB0这种方法特别适合快速确认串口是否通不依赖任何第三方工具。7. 常见问题速查表与终极排查清单说了这么多最后整理一个速查表你在实际调试中可以直接对照着排查。问题现象可能原因排查/解决方式lsusb看不到USB设备线材问题/USB口接触不良/未上电换线、换USB口确认开发板供电正常lsusb能看到/dev下无ttyUSB内核驱动未加载lsmod | grep ch341sudo modprobe ch341dmesg显示驱动被占用cdc_acm与ch341冲突sudo modprobe -r cdc_acm后重新插拔设备文件存在但权限拒绝用户不在dialout组sudo usermod -a -G dialout $USER后重新登录VMware里找不到设备USB设备未直通到虚拟机虚拟机右下角USB图标手动“连接”设备设备有但无任何串口输出TX/RX接反/GND不共地/波特率错误交叉接线、确认共地、核对波特率minicom打开设备失败硬件流控未关闭/权限不足关闭流控检查用户组权限设备文件编号不固定udev默认枚举顺序添加udev规则绑定固定软链接排查时我建议按这个顺序走lsusb确认USB枚举成功dmesg | tail确认驱动加载成功ls -l /dev/ttyUSB*确认设备节点存在groups确认当前用户权限回环测试确认串口链路。走完这五步99%的“找不到设备文件”问题都能定位出来。8. 从串口再往下走一步设备树、Qt交叉编译和板卡挂载串口通了之后开发工作才算真正开始。很多用T113、K230这类板卡的朋友下一步往往是配置网络、挂载文件系统、用Qt交叉编译开发界面程序。这里我补充一点和串口强相关的两个场景。第一个是设备树。如果你的板子上有多个串口你要在Linux里使用其中某一个往往需要查看设备树里对应的uart节点是否被启用。比如T113的设备树文件里sunxi-uart0默认用于调试串口其他的UART默认可能处于disabled状态。你需要把对应的status okay;加上然后重新编译设备树、更新到boot分区重启之后才会出现/dev/ttyS1、/dev/ttyS2这些节点。所以如果你已经摸清了USB转串口的设备节点问题但发现板子上板载的串口ttyS1之类的打不开那就要往设备树方向查了。第二个是Qt交叉编译。这个和串口不是直接相关但几乎是同一批人要做的事。很多朋友问“Qt如何交叉编译生成能在开发板运行的文件”其实核心就三件事交叉编译工具链选对、Qt库用同版本交叉编译、编译产物拷贝到板子上时库路径配置好。用命令行构建时-prefix参数指向sysroot-xplatform指定为linux-arm-gnueabi-g之类的平台这样生成的二进制才能在开发板架构上跑。还有一点在开发板上跑Qt程序时如果要用到串口记得链接Qt5SerialPort模块QT serialport交叉编译的坑更多但那是另一个话题了这里先提个醒只要你的主机Ubuntu串口真正调通了后面通过串口终端在板子上执行命令、挂载主机目录这些操作都会顺利很多。再补充一个和开发板挂载有关的技巧板子跑起来之后很多时候不用来回插拔SD卡或者U盘直接用网络挂载。开发板通过网线和主机连到同一网段后在板子上跑mount -t nfs 192.168.1.100:/home/user/share /mnt这样板子就能直接访问你Ubuntu主机上的目录交叉编译出来的可执行文件放到共享目录里板子上直接运行调试效率高一大截。当然NFS服务端需要先在Ubuntu上装好nfs-kernel-server并配置exports文件这个操作相对成熟网上也有很多教程不多展开了。
