把开发板接到Ubuntu主机上插上USB线结果ls /dev/ttyUSB*一敲什么都没有——这个场景我太熟了。不管是全志T113、STM32F407、正点原子RK3588还是复旦微的板子几乎每个人都会在串口这一步卡一次。而且这个问题的迷惑性在于板子明明上电了、灯也亮了、电脑也叮咚响了一声但就是找不到设备文件。这篇就把这个问题的排查链路完整走一遍从驱动、设备节点、权限到硬件按顺序查大部分情况十分钟内能定位。1. 设备文件从哪里来先搞懂串口设备在Linux下的注册逻辑很多刚接触嵌入式Linux的朋友会有个误解以为开发板用USB线连上电脑之后/dev/ttyUSB0或者/dev/ttyACM0这个文件就应该自动出现。逻辑上没错但内核不会凭空给你造一个设备文件出来这里面有一条完整的链路。1.1 从USB识别到tty节点生成的完整过程你的开发板通过USB线连接到电脑电脑端看到的其实不是开发板而是开发板上那颗USB转串口芯片。常见的芯片有CH340、CH341、CP2102、CP210x系列、FTDI FT232、以及部分板载ST-Link/V3调试器自带的虚拟串口。这颗芯片的作用是把开发板UART引脚上的TTL电平信号转换成USB协议让电脑把它识别成一个串口设备。当芯片被USB控制器识别后内核会做这么几件事USB核心枚举设备读取芯片的idVendor厂商ID和idProduct产品ID。根据ID匹配对应的内核驱动模块比如ch341、cp210x、ftdi_sio。驱动成功绑定后在/dev下创建字符设备节点一般命名为ttyUSB0或ttyACM0。通过udev规则赋予这个节点默认的权限和属组。这四步任何一步出了问题你都看不到设备文件。所以排查的时候我们不能只盯着/dev目录看得顺着链路一层层往下查。1.2 为什么有的板子显示ttyUSB有的显示ttyACM这里得解释一个初学者最容易懵的点同样是开发板怎么有的出现在ttyUSB0有的在ttyACM0ttyUSB是USB转串口驱动usb-serial子系统创建的设备节点CH340、CP2102、FT232这些芯片走的是这条路。而ttyACM是USB通信设备类CDC ACM协议创建的节点通常出现在带有原生USB CDC功能的芯片上比如STM32F407的USB虚拟串口VCP、ESP32-S3的USB-Serial-JTAG、以及很多带板载调试器的开发板。如果你插上板子后ttyUSB和ttyACM都没有别急先确认另一个更底层的问题这颗芯片到底有没有被系统认到。lsusb这个命令列出当前USB总线上所有设备能找到类似1a86:7523CH340、10c4:ea60CP2102、0403:6001FT232这样的条目。如果lsusb都看不到说明问题在硬件或者线材层面详见后面章节。2. 分步排查当前系统里到底是没驱动还是没节点我见过太多人一上来就sudo apt install ch340驱动其实大部分人根本不需要装驱动现代Ubuntu内核4.15以上基本都自带主流USB转串口芯片的驱动。真正的问题是别的原因。2.1 第一步确认USB设备是否被识别先插上开发板然后执行lsusb如果能找到对应的芯片条目比如Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics CH340 serial converter说明USB物理链路是通的芯片被内核枚举到了问题出在后续的驱动绑定或节点创建环节。如果lsusb里压根没有这个设备或者显示device descriptor read/64, error -71、device not accepting address这类错误那基本可以断定是硬件层面的问题——线材、接口、芯片损坏或者开发板根本就没给串口芯片供电。这一块后面有专门章节。2.2 第二步用dmesg看内核日志lsusb能看到设备后接着用dmesg查看内核日志这是定位问题最关键的武器dmesg | tail -n 50正常情况你会看到类似这样的输出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, SerialNumber0 ch341 1-2:1.0: ch341-uart converter detected usb 1-2: ch341-uart converter now attached to ttyUSB0关键在最后一行now attached to ttyUSB0。如果看到了这行但/dev/ttyUSB0还是不存在那基本上是udev规则或者权限配置的问题。但很多时候dmesg输出是这样的ch341 1-2:1.0: device disconnected或者压根没有ch341-uart converter detected这行说明驱动没有成功绑定。这时候要看是芯片太老内核不认还是驱动模块被系统屏蔽了。2.3 第三步检查驱动模块是否加载用lsmod查看当前加载的模块lsmod | grep -E ch341|cp210x|ftdi_sio如果没有任何输出手动加载一下试试sudo modprobe ch341然后再次dmesg看有没有新的日志输出。如果modprobe报错Module ch341 not found说明你的内核里根本没有这个驱动模块——这种情况多发生在自己编译内核、内核版本过老、或者用了一些精简版发行版的时候。2.4 一个区分问题环节的速查方法根据我的经验可以用下面的对应关系快速缩小排查范围现象可能原因下一步动作lsusb看不到设备USB线材/接口/芯片供电问题换线、直接插主机USB口别用扩展坞lsusb有设备dmesg无驱动绑定信息内核缺对应驱动模块modprobe手动加载或安装驱动dmesg显示 attached to ttyUSB0但/dev下没有udev 规则异常重启udev或检查/etc/udev/rules.d/dev/ttyUSB0存在但打开报权限错误用户不在 dialout 组添加用户到dialout组ttyUSB0存在能打开但收发数据乱码波特率/电平不匹配核对波特率、检查TTL电平转换芯片这个表格我建议截图保存基本覆盖了90%以上的串口连接问题。3. 常见USB转串口芯片的驱动安装与验证虽然现代Ubuntu对主流芯片支持很好但总有一些情况需要手动装驱动。下面按芯片类型分别说覆盖目前开发板圈子最常用的几种。3.1 CH340 / CH341国产板子最常见的方案全志T113、正点原子很多型号、以及大量的国产评估板用的都是CH340或者CH341。Ubuntu 18.04及以上内核自带的ch341驱动支持良好一般是即插即用。但有一个坑部分内核版本下CH340的驱动是实验性的可能会被系统禁用。验证方法是cat /proc/modules | grep ch341如果模块存在但工作不正常可以尝试卸载重载sudo modprobe -r ch341 sudo modprobe ch341这里提一句有些国产的CH340兼容芯片比如一些山寨型号在Linux下枚举出来的idVendor:idProduct不是标准的1a86:7523而是其他值导致内核驱动匹配不上。这种情况需要手动绑定设备到ch341驱动echo 1a86 7523 | sudo tee /sys/bus/usb-serial/drivers/ch341-uart/new_id如果每次插入都要手动绑就把它写成一个udev规则或者开机脚本。不过说实话这种情况我还是建议先确认一下芯片是不是正品山寨CH340在Linux下出各种幺蛾子的概率确实高一些。3.2 CP2102 / CP210x工业级板子喜欢用的方案CP2102芯片在一些稳定性要求较高的板子上很常见STM32MP157开发板、很多工控核心板都用它。内核模块是cp210x支持非常成熟。如果系统确实缺少驱动老内核或自定义内核需要自己编译。去Silicon Labs官网下载或者直接拉取内核源码编译cd /lib/modules/$(uname -r)/build/drivers/usb/serial make -C /lib/modules/$(uname -r)/build M$(pwd) modules sudo cp cp210x.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ sudo depmod -a sudo modprobe cp210x这个操作思路适用于大多数内核模块编译不限于cp210x。核心就是拿到源码、在对应内核目录下编译、把.ko文件放到内核模块路径、depmod更新依赖、modprobe加载。3.3 FTDI FT232老牌芯片但要注意冒牌货内核锁定问题FTDI芯片在正点原子Alpha系列、以及一些进口开发板上很常见。Ubuntu内核自带ftdi_sio驱动。但FTDI有个著名的问题Linux内核里有一个针对山寨FTDI芯片的黑名单机制如果你买到的是冒牌FT232插上之后系统会自动把芯片的USB ID改写成0000并停止工作。判断是不是这个问题看dmesgusb 1-1: new full-speed USB device number 3 using xhci_hcd ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected ftdi_sio: Device is not a genuine FTDI device!如果是这个提示要么换一片正品的FTDI芯片要么考虑用下面的方式强制绑定echo 0403 6001 | sudo tee /sys/bus/usb-serial/drivers/ftdi_sio/new_id这个方法能解决一部分问题但不是所有场景都能奏效而且治标不治本。嵌入式开发最重要的是设备稳定用正品芯片比折腾驱动省心得多。3.4 STM32板载ST-Link虚拟串口的情况STM32F407、STM32F103这类板子如果板载了ST-Link仿真器它的虚拟串口走的是另一条路ST-Link的USB接口会枚举出两个设备——一个用于调试一个用于虚拟串口。这个虚拟串口走的是ttyACM节点内核模块是cdc_acm。这种情况如果ttyACM0不出现多半是cdc_acm模块没加载sudo modprobe cdc_acm加载后立刻看dmesg应该能看到cdc_acm 1-1:1.1: ttyACM0: USB ACM device3.5 一个关于串口调试助手的提醒很多新手喜欢用Windows上的串口调试助手到了Linux下也要找功能一样的工具。但如果你连设备节点都没有换什么软件都没用。等设备节点正常出现后Linux下有minicom、screen、picocom、cu这些工具可选我自己的习惯是用picocom比minicom轻量比screen直观sudo apt install picocom picocom -b 115200 /dev/ttyUSB0退出picocom的快捷键是CtrlA然后CtrlX这个每次都要跟新手强调因为很多人不知道怎么退出就直接关终端了。4. 权限问题设备文件在但打不开或者没权限很多时候设备文件静静躺在那里但你的普通用户就是没权限访问。典型的表现是ls -l /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 Mar 12 10:23 /dev/ttyUSB0注意看权限位crw-rw----root用户和dialout组的成员可以读写其他用户啥也干不了。然后你用minicom打开时就会看到Permission denied。4.1 正确解法把自己加入dialout组最规范的操作不是用sudo运行串口工具虽然也能用但每次都要sudo很麻烦而且有些工具用sudo跑会引入新的问题而是把当前用户加入dialout组sudo usermod -aG dialout $USER然后重新登录或者执行newgrp dialout让组权限生效。之后你再打开串口工具就会发现一切正常。4.2 为什么是dialout组而不是其他组Linux下串口设备的标准属组是dialout这个组的名字沿用了早期Unix拨号上网dial-out的历史作用是允许特定用户访问串口和调制解调器设备。Ubuntu的安装程序默认创建的普通用户通常不在这个组里所以我个人建议在装完Ubuntu、准备开始嵌入式开发之前先执行一次上面的加入命令省得每次插新板子都要重新处理。4.3 更灵活的方案自定义udev规则如果你想让设备文件在插入时自动拥有更宽松的权限或者自动创建一个带特定名字的软链接比如/dev/t113_board可以自己写udev规则。我个人比较推荐这种方式因为开发板上电后设备名固定写脚本自动化操作时不用担心ttyUSB编号漂移。创建文件/etc/udev/rules.d/99-usb-serial.rules内容示例SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, MODE0666, SYMLINKt113_board其中ATTRS{idVendor}和ATTRS{idProduct}在lsusb输出里能看到。写入后重新加载规则sudo udevadm control --reload-rules sudo udevadm trigger拔插一次USB线之后/dev/t113_board就会指向实际的串口节点。有了固定节点你写自动测试脚本、systemd服务、或者跑一些自动化烧录脚本时就会非常舒服不用担心今天ttyUSB0明天ttyUSB1的情况。5. 硬件侧原因排查芯片、线材与开发板本身软件层面全部排查完了还是不行那问题多半出在硬件。这条路上我踩过的坑比软件层面多得多而且更隐蔽。5.1 USB线只通电不传数据这是所有坑里最阴险的一个。很多USB线内部只有电源和地线没有数据线D/D-。这种线拿来给开发板供电刚好但数据通信完全瘫痪。怎么判断插上线后执行lsusb如果在新环境下换一台电脑也完全看不到任何新设备先不要怀疑开发板换一根你确定能传数据的USB线再试。这是一个成本最低、操作最简单的排查步骤但很多人一开始都不会往这个方向想。5.2 扩展坞和前置USB口造成的干扰笔记本用户插扩展坞的USB口或者机箱前置USB口有时候会遇到供电不稳或者信号质量差的问题导致USB设备反复掉线或者枚举失败。碰到dmesg里不停出现device descriptor read/64, error -110这类日志时优先把线直接插到主机后背板的USB口或者笔记本原生USB口测试。很多时候问题就这么解决了。5.3 开发板串口芯片供电异常有些开发板的USB转串口芯片和主控共用电源如果你的USB口供电能力不足芯片可能处于半工作状态。这种情况会出现lsusb偶尔能看到、偶尔看不到的现象。可以试试用独立电源给开发板供电同时只把USB线当作数据线使用。大多数开发板的USB转串口芯片设计是支持这种分离供电模式的具体看原理图。5.4 开发板的启动模式与串口复用的关系还有一类隐藏很深的问题部分开发板比如全志系列的调试串口引脚和启动模式有关。如果板子当前处于某种启动模式比如从SD卡启动还是从NAND启动串口引脚可能被复用成了其他功能导致即使硬件连接正常也收不到数据。这种情况设备文件是正常的但串口数据乱码或者完全没有输出。我之前调试一块全志T113板子卡了一个多小时设备节点有、权限也对、波特率没错但串口就是没数据。后来发现是板子没有正常启动SD卡里的系统坏了串口芯片工作正常但主控压根没在跑。所以排查到这一步时也要确认一下开发板是不是真的在运行、有没有正常输出启动日志。5.5 电平不一致导致的识别正常但通信失败这算半个硬件问题。你的开发板如果输出的是RS232电平负逻辑±12V而你的USB转串口芯片是TTL电平0~3.3V或0~5V那插上后设备节点正常但收发全是乱码或者无响应。这时候你需要的是RS232转TTL模块而不是换驱动。判断方法很简单看开发板原理图或者资料里标注的调试串口电平。大部分开发板的调试串口都是TTL电平直接连USB转TTL模块即可。个别工控板或者老式开发板会引出RS232接口那就得用RS232转USB线。6. 终极自查清单每个场景对应一套解法排查思路全部走完了最后整理一份完整清单。建议保存下来下次遇到类似问题按顺序过一遍。检查项命令/操作正常状态故障状态应对USB设备是否可见lsusb能看到厂商芯片条目换线、换USB口、检查开发板供电内核是否识别dmesg | tail -n 50有new USB device和attached to ttyUSB0手动加载驱动、检查内核模块设备节点是否存在ls /dev/ttyUSB* /dev/ttyACM*出现ttyUSB或ttyACM节点重启udev、检查驱动绑定当前用户是否有权限ls -l /dev/ttyUSB0当前用户属于dialout组usermod -aG dialout $USER串口设备能否打开picocom -b 115200 /dev/ttyUSB0正常进入交互界面检查端口占用、权限、内核日志数据收发是否正常开发板重启观察串口输出能看到启动日志检查波特率、电平、启动模式还有一个值得单独说的小技巧用cat /proc/tty/driver/usbserial查看USB串口驱动的端口分配情况cat /proc/tty/driver/usbserial输出中有类似0: module:ch341 name:ttyUSB0 vendor:1a86 product:7523的信息说明驱动确实给这个设备分配了端口号。如果这里能看到端口但/dev下没有对应文件那就非常明确地指向udev问题了。说实话开发板串口连不上这个问题绝大多数情况都不是什么深奥的技术原因就是一个按顺序排除的过程。我从最早接触嵌入式到现在遇到过设备文件不存在、设备文件名变了导致自动化脚本挂掉、山寨芯片被内核拒载、劣质USB线浪费一下午时间等等各种奇奇怪怪的状况。这些经验里最值钱的一条就是先确认每一层传递链路的上一环是通的再往下一环查。不要一上来就重装驱动、重装系统那样反而会引入更多变量。最后分享一个我自己的习惯每个开发板我都会在udev里固定一个设备名软链接比如/dev/board_t113、/dev/board_stm32这样不管是手动调试还是写自动化脚本都方便不用记ttyUSB后面的数字编号。同时也会在开发板到手的第一时间就插到电脑上看lsusb和dmesg输出确认板子的核心芯片、串口芯片的ID信息把这些信息记录在维护文档里后面出了问题查起来快得多。
开发板串口连不上？Linux下USB转串口设备识别与排查全攻略
把开发板接到Ubuntu主机上插上USB线结果ls /dev/ttyUSB*一敲什么都没有——这个场景我太熟了。不管是全志T113、STM32F407、正点原子RK3588还是复旦微的板子几乎每个人都会在串口这一步卡一次。而且这个问题的迷惑性在于板子明明上电了、灯也亮了、电脑也叮咚响了一声但就是找不到设备文件。这篇就把这个问题的排查链路完整走一遍从驱动、设备节点、权限到硬件按顺序查大部分情况十分钟内能定位。1. 设备文件从哪里来先搞懂串口设备在Linux下的注册逻辑很多刚接触嵌入式Linux的朋友会有个误解以为开发板用USB线连上电脑之后/dev/ttyUSB0或者/dev/ttyACM0这个文件就应该自动出现。逻辑上没错但内核不会凭空给你造一个设备文件出来这里面有一条完整的链路。1.1 从USB识别到tty节点生成的完整过程你的开发板通过USB线连接到电脑电脑端看到的其实不是开发板而是开发板上那颗USB转串口芯片。常见的芯片有CH340、CH341、CP2102、CP210x系列、FTDI FT232、以及部分板载ST-Link/V3调试器自带的虚拟串口。这颗芯片的作用是把开发板UART引脚上的TTL电平信号转换成USB协议让电脑把它识别成一个串口设备。当芯片被USB控制器识别后内核会做这么几件事USB核心枚举设备读取芯片的idVendor厂商ID和idProduct产品ID。根据ID匹配对应的内核驱动模块比如ch341、cp210x、ftdi_sio。驱动成功绑定后在/dev下创建字符设备节点一般命名为ttyUSB0或ttyACM0。通过udev规则赋予这个节点默认的权限和属组。这四步任何一步出了问题你都看不到设备文件。所以排查的时候我们不能只盯着/dev目录看得顺着链路一层层往下查。1.2 为什么有的板子显示ttyUSB有的显示ttyACM这里得解释一个初学者最容易懵的点同样是开发板怎么有的出现在ttyUSB0有的在ttyACM0ttyUSB是USB转串口驱动usb-serial子系统创建的设备节点CH340、CP2102、FT232这些芯片走的是这条路。而ttyACM是USB通信设备类CDC ACM协议创建的节点通常出现在带有原生USB CDC功能的芯片上比如STM32F407的USB虚拟串口VCP、ESP32-S3的USB-Serial-JTAG、以及很多带板载调试器的开发板。如果你插上板子后ttyUSB和ttyACM都没有别急先确认另一个更底层的问题这颗芯片到底有没有被系统认到。lsusb这个命令列出当前USB总线上所有设备能找到类似1a86:7523CH340、10c4:ea60CP2102、0403:6001FT232这样的条目。如果lsusb都看不到说明问题在硬件或者线材层面详见后面章节。2. 分步排查当前系统里到底是没驱动还是没节点我见过太多人一上来就sudo apt install ch340驱动其实大部分人根本不需要装驱动现代Ubuntu内核4.15以上基本都自带主流USB转串口芯片的驱动。真正的问题是别的原因。2.1 第一步确认USB设备是否被识别先插上开发板然后执行lsusb如果能找到对应的芯片条目比如Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics CH340 serial converter说明USB物理链路是通的芯片被内核枚举到了问题出在后续的驱动绑定或节点创建环节。如果lsusb里压根没有这个设备或者显示device descriptor read/64, error -71、device not accepting address这类错误那基本可以断定是硬件层面的问题——线材、接口、芯片损坏或者开发板根本就没给串口芯片供电。这一块后面有专门章节。2.2 第二步用dmesg看内核日志lsusb能看到设备后接着用dmesg查看内核日志这是定位问题最关键的武器dmesg | tail -n 50正常情况你会看到类似这样的输出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, SerialNumber0 ch341 1-2:1.0: ch341-uart converter detected usb 1-2: ch341-uart converter now attached to ttyUSB0关键在最后一行now attached to ttyUSB0。如果看到了这行但/dev/ttyUSB0还是不存在那基本上是udev规则或者权限配置的问题。但很多时候dmesg输出是这样的ch341 1-2:1.0: device disconnected或者压根没有ch341-uart converter detected这行说明驱动没有成功绑定。这时候要看是芯片太老内核不认还是驱动模块被系统屏蔽了。2.3 第三步检查驱动模块是否加载用lsmod查看当前加载的模块lsmod | grep -E ch341|cp210x|ftdi_sio如果没有任何输出手动加载一下试试sudo modprobe ch341然后再次dmesg看有没有新的日志输出。如果modprobe报错Module ch341 not found说明你的内核里根本没有这个驱动模块——这种情况多发生在自己编译内核、内核版本过老、或者用了一些精简版发行版的时候。2.4 一个区分问题环节的速查方法根据我的经验可以用下面的对应关系快速缩小排查范围现象可能原因下一步动作lsusb看不到设备USB线材/接口/芯片供电问题换线、直接插主机USB口别用扩展坞lsusb有设备dmesg无驱动绑定信息内核缺对应驱动模块modprobe手动加载或安装驱动dmesg显示 attached to ttyUSB0但/dev下没有udev 规则异常重启udev或检查/etc/udev/rules.d/dev/ttyUSB0存在但打开报权限错误用户不在 dialout 组添加用户到dialout组ttyUSB0存在能打开但收发数据乱码波特率/电平不匹配核对波特率、检查TTL电平转换芯片这个表格我建议截图保存基本覆盖了90%以上的串口连接问题。3. 常见USB转串口芯片的驱动安装与验证虽然现代Ubuntu对主流芯片支持很好但总有一些情况需要手动装驱动。下面按芯片类型分别说覆盖目前开发板圈子最常用的几种。3.1 CH340 / CH341国产板子最常见的方案全志T113、正点原子很多型号、以及大量的国产评估板用的都是CH340或者CH341。Ubuntu 18.04及以上内核自带的ch341驱动支持良好一般是即插即用。但有一个坑部分内核版本下CH340的驱动是实验性的可能会被系统禁用。验证方法是cat /proc/modules | grep ch341如果模块存在但工作不正常可以尝试卸载重载sudo modprobe -r ch341 sudo modprobe ch341这里提一句有些国产的CH340兼容芯片比如一些山寨型号在Linux下枚举出来的idVendor:idProduct不是标准的1a86:7523而是其他值导致内核驱动匹配不上。这种情况需要手动绑定设备到ch341驱动echo 1a86 7523 | sudo tee /sys/bus/usb-serial/drivers/ch341-uart/new_id如果每次插入都要手动绑就把它写成一个udev规则或者开机脚本。不过说实话这种情况我还是建议先确认一下芯片是不是正品山寨CH340在Linux下出各种幺蛾子的概率确实高一些。3.2 CP2102 / CP210x工业级板子喜欢用的方案CP2102芯片在一些稳定性要求较高的板子上很常见STM32MP157开发板、很多工控核心板都用它。内核模块是cp210x支持非常成熟。如果系统确实缺少驱动老内核或自定义内核需要自己编译。去Silicon Labs官网下载或者直接拉取内核源码编译cd /lib/modules/$(uname -r)/build/drivers/usb/serial make -C /lib/modules/$(uname -r)/build M$(pwd) modules sudo cp cp210x.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ sudo depmod -a sudo modprobe cp210x这个操作思路适用于大多数内核模块编译不限于cp210x。核心就是拿到源码、在对应内核目录下编译、把.ko文件放到内核模块路径、depmod更新依赖、modprobe加载。3.3 FTDI FT232老牌芯片但要注意冒牌货内核锁定问题FTDI芯片在正点原子Alpha系列、以及一些进口开发板上很常见。Ubuntu内核自带ftdi_sio驱动。但FTDI有个著名的问题Linux内核里有一个针对山寨FTDI芯片的黑名单机制如果你买到的是冒牌FT232插上之后系统会自动把芯片的USB ID改写成0000并停止工作。判断是不是这个问题看dmesgusb 1-1: new full-speed USB device number 3 using xhci_hcd ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected ftdi_sio: Device is not a genuine FTDI device!如果是这个提示要么换一片正品的FTDI芯片要么考虑用下面的方式强制绑定echo 0403 6001 | sudo tee /sys/bus/usb-serial/drivers/ftdi_sio/new_id这个方法能解决一部分问题但不是所有场景都能奏效而且治标不治本。嵌入式开发最重要的是设备稳定用正品芯片比折腾驱动省心得多。3.4 STM32板载ST-Link虚拟串口的情况STM32F407、STM32F103这类板子如果板载了ST-Link仿真器它的虚拟串口走的是另一条路ST-Link的USB接口会枚举出两个设备——一个用于调试一个用于虚拟串口。这个虚拟串口走的是ttyACM节点内核模块是cdc_acm。这种情况如果ttyACM0不出现多半是cdc_acm模块没加载sudo modprobe cdc_acm加载后立刻看dmesg应该能看到cdc_acm 1-1:1.1: ttyACM0: USB ACM device3.5 一个关于串口调试助手的提醒很多新手喜欢用Windows上的串口调试助手到了Linux下也要找功能一样的工具。但如果你连设备节点都没有换什么软件都没用。等设备节点正常出现后Linux下有minicom、screen、picocom、cu这些工具可选我自己的习惯是用picocom比minicom轻量比screen直观sudo apt install picocom picocom -b 115200 /dev/ttyUSB0退出picocom的快捷键是CtrlA然后CtrlX这个每次都要跟新手强调因为很多人不知道怎么退出就直接关终端了。4. 权限问题设备文件在但打不开或者没权限很多时候设备文件静静躺在那里但你的普通用户就是没权限访问。典型的表现是ls -l /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 Mar 12 10:23 /dev/ttyUSB0注意看权限位crw-rw----root用户和dialout组的成员可以读写其他用户啥也干不了。然后你用minicom打开时就会看到Permission denied。4.1 正确解法把自己加入dialout组最规范的操作不是用sudo运行串口工具虽然也能用但每次都要sudo很麻烦而且有些工具用sudo跑会引入新的问题而是把当前用户加入dialout组sudo usermod -aG dialout $USER然后重新登录或者执行newgrp dialout让组权限生效。之后你再打开串口工具就会发现一切正常。4.2 为什么是dialout组而不是其他组Linux下串口设备的标准属组是dialout这个组的名字沿用了早期Unix拨号上网dial-out的历史作用是允许特定用户访问串口和调制解调器设备。Ubuntu的安装程序默认创建的普通用户通常不在这个组里所以我个人建议在装完Ubuntu、准备开始嵌入式开发之前先执行一次上面的加入命令省得每次插新板子都要重新处理。4.3 更灵活的方案自定义udev规则如果你想让设备文件在插入时自动拥有更宽松的权限或者自动创建一个带特定名字的软链接比如/dev/t113_board可以自己写udev规则。我个人比较推荐这种方式因为开发板上电后设备名固定写脚本自动化操作时不用担心ttyUSB编号漂移。创建文件/etc/udev/rules.d/99-usb-serial.rules内容示例SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, MODE0666, SYMLINKt113_board其中ATTRS{idVendor}和ATTRS{idProduct}在lsusb输出里能看到。写入后重新加载规则sudo udevadm control --reload-rules sudo udevadm trigger拔插一次USB线之后/dev/t113_board就会指向实际的串口节点。有了固定节点你写自动测试脚本、systemd服务、或者跑一些自动化烧录脚本时就会非常舒服不用担心今天ttyUSB0明天ttyUSB1的情况。5. 硬件侧原因排查芯片、线材与开发板本身软件层面全部排查完了还是不行那问题多半出在硬件。这条路上我踩过的坑比软件层面多得多而且更隐蔽。5.1 USB线只通电不传数据这是所有坑里最阴险的一个。很多USB线内部只有电源和地线没有数据线D/D-。这种线拿来给开发板供电刚好但数据通信完全瘫痪。怎么判断插上线后执行lsusb如果在新环境下换一台电脑也完全看不到任何新设备先不要怀疑开发板换一根你确定能传数据的USB线再试。这是一个成本最低、操作最简单的排查步骤但很多人一开始都不会往这个方向想。5.2 扩展坞和前置USB口造成的干扰笔记本用户插扩展坞的USB口或者机箱前置USB口有时候会遇到供电不稳或者信号质量差的问题导致USB设备反复掉线或者枚举失败。碰到dmesg里不停出现device descriptor read/64, error -110这类日志时优先把线直接插到主机后背板的USB口或者笔记本原生USB口测试。很多时候问题就这么解决了。5.3 开发板串口芯片供电异常有些开发板的USB转串口芯片和主控共用电源如果你的USB口供电能力不足芯片可能处于半工作状态。这种情况会出现lsusb偶尔能看到、偶尔看不到的现象。可以试试用独立电源给开发板供电同时只把USB线当作数据线使用。大多数开发板的USB转串口芯片设计是支持这种分离供电模式的具体看原理图。5.4 开发板的启动模式与串口复用的关系还有一类隐藏很深的问题部分开发板比如全志系列的调试串口引脚和启动模式有关。如果板子当前处于某种启动模式比如从SD卡启动还是从NAND启动串口引脚可能被复用成了其他功能导致即使硬件连接正常也收不到数据。这种情况设备文件是正常的但串口数据乱码或者完全没有输出。我之前调试一块全志T113板子卡了一个多小时设备节点有、权限也对、波特率没错但串口就是没数据。后来发现是板子没有正常启动SD卡里的系统坏了串口芯片工作正常但主控压根没在跑。所以排查到这一步时也要确认一下开发板是不是真的在运行、有没有正常输出启动日志。5.5 电平不一致导致的识别正常但通信失败这算半个硬件问题。你的开发板如果输出的是RS232电平负逻辑±12V而你的USB转串口芯片是TTL电平0~3.3V或0~5V那插上后设备节点正常但收发全是乱码或者无响应。这时候你需要的是RS232转TTL模块而不是换驱动。判断方法很简单看开发板原理图或者资料里标注的调试串口电平。大部分开发板的调试串口都是TTL电平直接连USB转TTL模块即可。个别工控板或者老式开发板会引出RS232接口那就得用RS232转USB线。6. 终极自查清单每个场景对应一套解法排查思路全部走完了最后整理一份完整清单。建议保存下来下次遇到类似问题按顺序过一遍。检查项命令/操作正常状态故障状态应对USB设备是否可见lsusb能看到厂商芯片条目换线、换USB口、检查开发板供电内核是否识别dmesg | tail -n 50有new USB device和attached to ttyUSB0手动加载驱动、检查内核模块设备节点是否存在ls /dev/ttyUSB* /dev/ttyACM*出现ttyUSB或ttyACM节点重启udev、检查驱动绑定当前用户是否有权限ls -l /dev/ttyUSB0当前用户属于dialout组usermod -aG dialout $USER串口设备能否打开picocom -b 115200 /dev/ttyUSB0正常进入交互界面检查端口占用、权限、内核日志数据收发是否正常开发板重启观察串口输出能看到启动日志检查波特率、电平、启动模式还有一个值得单独说的小技巧用cat /proc/tty/driver/usbserial查看USB串口驱动的端口分配情况cat /proc/tty/driver/usbserial输出中有类似0: module:ch341 name:ttyUSB0 vendor:1a86 product:7523的信息说明驱动确实给这个设备分配了端口号。如果这里能看到端口但/dev下没有对应文件那就非常明确地指向udev问题了。说实话开发板串口连不上这个问题绝大多数情况都不是什么深奥的技术原因就是一个按顺序排除的过程。我从最早接触嵌入式到现在遇到过设备文件不存在、设备文件名变了导致自动化脚本挂掉、山寨芯片被内核拒载、劣质USB线浪费一下午时间等等各种奇奇怪怪的状况。这些经验里最值钱的一条就是先确认每一层传递链路的上一环是通的再往下一环查。不要一上来就重装驱动、重装系统那样反而会引入更多变量。最后分享一个我自己的习惯每个开发板我都会在udev里固定一个设备名软链接比如/dev/board_t113、/dev/board_stm32这样不管是手动调试还是写自动化脚本都方便不用记ttyUSB后面的数字编号。同时也会在开发板到手的第一时间就插到电脑上看lsusb和dmesg输出确认板子的核心芯片、串口芯片的ID信息把这些信息记录在维护文档里后面出了问题查起来快得多。
