做嵌入式、单片机开发或者偶尔折腾路由器、交换机的人一定绕不开串口调试这关。不管是看启动日志、调AT指令还是和传感器模块对接都得跟串口打交道。Ubuntu 22.04下很多人第一反应是minicom或者screen但命令行工具参数多、界面不直观尤其是要频繁切换波特率、发送hex数据的时候效率真的堪忧。这篇文章重点聊聊CuteCom这个图形化串口调试工具在Ubuntu 22.04上从安装、配置到实测的完整过程以及我踩过的几个坑。CuteCom是一款基于Qt的轻量级串口调试助手界面简洁操作逻辑和Windows下常见的串口助手基本一致非常适合刚切换到Linux或者不爱记命令的开发者也能让老手在调试时省下不少时间。如果你正在找Ubuntu下的串口图形化工具这篇文章可以直接帮你落地。文中涉及的所有操作都在Ubuntu 22.04上实测过确认可用。1. 为什么我弃用minicom改用CuteCom1.1 命令行串口工具有什么痛点minicom和screen在Linux下确实够用但实际用起来问题不少。minicom的配置菜单是基于文本的第一次进去要先设置串口设备、波特率还经常遇到按键不生效的情况比如CtrlA是菜单键结果发到设备端成了别的字符。screen更极简启动参数全靠记忆screen /dev/ttyUSB0 115200这种命令稍微复杂一点的场景就吃力了。我调试一块ESP32开发板时需要先以115200波特率看日志然后切换到9600读某个传感器的数据最后还要以74880这个非标准波特率查看上电信息。用minicom的话每切换一次波特率都得进配置菜单来回至少六步操作实际用起来非常痛苦。命令行工具不是不能用而是这种高频的参数切换操作效率太低还容易出错。CuteCom的好处在于所有关键参数都在主界面上直接列出来波特率、数据位、停止位、校验位、流控方式下拉框随手一点就切换改了立刻生效不需要保存配置再退出重进。这一点在实际调试中的价值比界面好不好看重要得多。1.2 CuteCom和几款主流工具的横向对比拿CuteCom和Ubuntu下常见的几款串口工具做个对比方便你判断哪个适合自己。工具界面类型配置复杂度非标准波特率支持定时发送hex收发适合场景minicom终端文本高一般不支持支持但麻烦老牌服务器调试screen终端高依赖内核不支持不支持临时应急CuteComQt图形化低支持自定义支持支持嵌入式开发日常putty图形化低一般不支持不支持SSH串口两用CuteCom在设备列表刷新、打开失败提示、数据接收显示这几个环节上对新手特别友好。设备没插好或者权限不足时它会直接弹对话框告诉你原因而不是像终端工具那样无声无息地卡住。这个失败时给反馈的特性对排查问题帮助很大。2. Ubuntu 22.04安装CuteCom的两种方式与权限配置2.1 用apt安装最简单的方式Ubuntu 22.04的官方软件源里直接有CuteCom安装非常简单sudo apt update sudo apt install cutecom装完就能用不需要额外配置依赖。官方源的版本虽然不是最新的但功能和稳定性完全够用。这类串口工具本质上是对内核tty子系统的封装版本新旧对实际功能的影响不大稳定才是关键。启动方式有两种一种是在终端输入cutecom另一种是在应用菜单里搜索CuteCOM点图标。我建议日常用终端启动因为能看到有没有报错信息比如权限不足之类的错误会直接打印在终端里。2.2 想用新版本源码编译安装apt源里的版本可能滞后如果你想用新版本可以去GitHub拉源码编译。CuteCom依赖Qt开发库编译前需要先装sudo apt install qtbase5-dev libqt5serialport5-dev cmake g git clone https://github.com/neundorf/CuteCom.git cd CuteCom mkdir build cd build cmake .. make -j4 sudo make install编译过程中最常见的坑是缺Qt模块。如果你在cmake阶段报找不到Qt5的包检查一下qtbase5-dev装了没有。源码编译的好处是版本新界面和功能可能更多但对普通用户来说apt版已经足够没必要自己编译。2.3 串口权限问题90%的新手都卡在这装好CuteCom后双击打开在Device下拉框里选了/dev/ttyUSB0点击Open结果弹窗提示无法打开。这个问题的根本原因是当前用户没有访问串口设备的权限。Linux下串口设备属于dialout组普通用户不在这个组里就没权限读写。解决方法很直接把当前用户添加到dialout组sudo usermod -aG dialout $USER改完之后需要注销重新登录或者重启电脑才能生效。验证是否生效groups如果输出里能看到dialout就说明成功了。不想注销的话也可以用newgrp dialout临时切换组身份但只对当前终端有效治标不治本。还有一种临时方案是直接sudo cutecom启动但我不推荐因为以后每次都得sudo而且以root身份运行图形工具万一操作失误影响面更大。3. CuteCom核心功能拆解与实操配置3.1 界面布局与关键参数设置CuteCom的主界面分两大块上半部分是一排串口参数配置项下半部分是接收区和发送区。接收区默认显示收到的数据发送区是你编辑要发送的内容。参数配置这块我用一个实际场景来说明。假设你手里有一块GPS模块手册上写着串口参数是115200, 8, N, 1意思就是波特率115200、数据位8位、无校验、停止位1位。在CuteCom里这样设置Device选择/dev/ttyUSB0或者/dev/ttyS0根据你的设备实际节点来Baud rate下拉选择115200Data bits8Stop bits1ParityNoneFlow controlNone这里解释一下这些参数为什么这么设。串口通信的双方必须使用完全相同的参数否则数据在底层就会被错误解析表现出来就是乱码或者完全收不到。数据位8位是标准配置因为ASCII字符是8位的绝大多数设备默认都是这个值。停止位1位是最常见的它的作用是一个字节传输结束的分隔符。校验位用来检测传输错误的一个bit像GPS模块这种短距离低干扰场景通常不需要校验所以选None。流控分为硬件流控(RTS/CTS)和软件流控(XON/XOFF)。最常遇到的问题就是流控设错了导致设备不响应。我调试一个工业级串口屏时因为默认开启了硬件流控发送指令后屏幕毫无反应排查了半天才发现是这个问题。所以如果设备不响应第一件事就是检查流控是不是设成了None。3.2 基于真实板卡的收发测试流程用一块常见的CH340芯片USB转串口模块连接STM32开发板我走一遍完整流程。准备材料CH340 USB转TTL模块一个STM32F103C8T6最小系统板一块杜邦线三根USB线一根连线方式CH340模块的TXD接STM32的RXRXD接STM32的TXGND接GND。注意TXD和RXD要交叉连接不能直连。如果CH340模块没有RTS/DTR引脚的话可以不管如果带了就不要接STM32的BOOT0和BOOT1否则STM32可能意外进入串口下载模式。打开CuteCom设备选择/dev/ttyUSB0波特率115200数据位8停止位1无校验无流控点击Open按钮状态栏会变成绿色显示Opened。STM32板的程序很简单#include stm32f1xx_hal.h UART_HandleTypeDef huart1; static void MX_GPIO_Init(void); static void MX_UART1_Init(void); int main(void) { HAL_Init(); MX_GPIO_Init(); MX_UART1_Init(); uint8_t rxBuf[64]; while (1) { uint8_t len 0; uint8_t data; while (HAL_UART_Receive(huart1, data, 1, 100) HAL_OK) { rxBuf[len] data; if (data \n || len 64) break; } HAL_UART_Transmit(huart1, rxBuf, len, 100); HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); } }这段程序的作用是每收到一行数据以换行符结尾就原样回送同时翻转板载LED。这样就能在CuteCom里直观验证发送-接收-板上执行这一完整链路。实测操作在CuteCom的Input框里输入hello\r\n点Send。如果一切正常接收区会原样显示hello\r\n同时STM32板上的LED会翻转一次。如果LED亮了但接收区没显示说明回发通路有问题重点检查RXD/TXD是否交叉接反。输入AT\r\n如果LED翻转但没回显说明发送路径没问题接收路径出问题了大概率是TXD/RXD接错。如果LED都不闪烁说明发送本身就失败检查CH340模块是否被系统识别。3.3 定时发送与hex模式调试传感器的好帮手CuteCom的定时发送功能在多传感器数据读取场景里特别有用。比如读取一个温湿度传感器传感器要求主机每隔100ms发送一次查询命令用手工点发送按钮完全不现实用定时发送就能解决。在Options菜单里勾选Send on timer设置间隔时间单位是毫秒。我调试SHT30温湿度传感器时就是用的这个功能每200ms发一次读命令0x2C 0x06数据就源源不断地回传下来配合日志保存功能连续观察温度变化曲线非常方便。Hex模式也需要重点说明。很多传感器和模组的指令手册里指令都是十六进制表示的比如0x01 0x03 0x00 0x00 0x00 0x01 0x84 0x0A这种。默认的ASCII模式下输入这些会被当成普通文本发送设备根本看不懂。勾选Hex模式后CuteCom就会把输入框里的内容按十六进制逐字节发送同时接收区的显示也会变成十六进制格式。我遇到过一种情况某温控模块需要发送特定字节里面包含不可见字符0xFF和0x00。ASCII模式下这两个字符会被处理成文本或者直接吞掉怎么发都不对。换成Hex模式输入FF 00 A1一秒钟搞定。所以遇到指令包含非ASCII字符或者需要精确控制字节内容时一定记得切到Hex模式。3.4 日志保存复现Bug和自动化分析的基础CuteCom支持把接收到的数据保存到文件。这个功能看似简单但在实际调试中价值很大。之前排查一个串口通信偶发丢包的问题让我盯着屏幕看了半小时那数据一闪就过去了根本没法逐帧分析。后面把日志开起来把收到的几十万条数据全部保存成文件再用Python脚本去统计帧间隔和丢包率问题原因一下就找到了。操作方法是点击工具栏上的Save接收日志图标选择文件路径。CuteCom保存的是原始数据没有添加任何时间戳之类的东西。如果你想带时间戳可以自己在接收数据中插入时间标记或者写个小脚本监控日志文件。我在实际项目中会把CuteCom的日志文件直接喂给Python的serial库做离线回放用来复现设备端的问题。4. 实际工作中最常用的三种CuteCom使用场景4.1 场景一读取传感器/模块数据以读取一个常见的GPS模块为例完整的调试流程是这样的。GPS模块上电后一般默认以9600波特率输出NMEA 0183格式的数据就是$GPGGA,....开头的那种ASCII文本。打开CuteCom设备选对波特率设9600打开串口。正常情况下接收区会不断滚动输出类似这样的数据$GPGGA,083559.00,3404.70417,N,11726.34356,W,1,12,1.0,0.0,M,0.0,M,,*6A $GPGSA,A,3,04,05,06,13,12,24,21,19,17,32,01,18,0.8,0.6,1.2*38如果没有任何输出优先检查模块的供电是否正常、TXD是否接到了CuteCom对应的RXD、波特率是否匹配。注意GPS模块的TX引脚一般是3.3V电平如果你的USB转串口模块不支持3.3V需要加电平转换否则可能损坏模块也可能就是收不到数据。如果需要主动向模块发送配置命令比如把波特率从9600改成115200就要在Input框输入$PMTK251,115200*2A\r\n然后点Send。之后模块会以115200重新输出数据。这时候把CuteCom的波特率也切到115200就能继续正常收数据。实战里我一般先把数据保存下来等到波特率切换生效后再看新数据是否正常方便回看。4.2 场景二调试路由器/嵌入式Linux开发板的串口登录玩过路由器或者嵌入式Linux开发板的人一定懂串口登录是急救手段。系统起不来、SSH没配置好的时候串口是唯一的救命通道。CuteCom在这种情况下完全能替代minicom。NanoPi系列开发板出厂自带U-Boot通过串口可以看到启动日志。打开CuteCom波特率设为115200具体看板子手册打开串口然后给开发板上电。接收区会刷出类似这样的启动日志U-Boot 2018.01-rc2 (Jan 10 2019 - 10:38:15 0000) DRAM: 1 GiB MMC: sdhcife330000: 0, mmcfe320000: 1这时可以敲回车进入U-Boot命令行。这就能在U-Boot阶段设置启动参数、擦写flash、引导系统内核功能上和minicom没什么区别。我在给一个开发板刷系统时因为分区表写错了内核永远起不来。这种情况下SSH根本不可能网口也不一定有IP。幸好有CuteCom连上了串口在U-Boot里重新设置bootcmd把启动命令改回正确的分区表路径救回来了。这个场景里CuteCom的图形界面优势很明显看不到U-Boot菜单时可以直接看到完整滚动的历史输出而不像minicom那样需要额外配置scrollback buffer。4.3 场景三调试自制USB转串口模块和设备识别还有一种需求不仅仅是调设备而是要确认USB转串口模块本身有没有被系统识别。插入USB转串口模块后先执行dmesg | tail ls -l /dev/ttyUSB*正常情况会看到类似usb 1-2: cp210x converter now attached to ttyUSB0的提示。如果没有这个提示说明驱动没加载或者硬件有问题。在Windows上常见的问题是插入串口设备显示未知设备在Ubuntu下一般不会出现这种情况只要内核识别了USB设备就会自动创建/dev/ttyUSB0节点。如果内核识别了但CuteCom还打不开那就回到用户组权限的问题按我之前说的dialout组配置一遍就行。CuteCom捕获到的异常信息比Windows下的设备管理器要详细得多例如我可以从dmesg输出判断是CH340、CP210x还是FT232芯片然后根据芯片类型决定是否需要额外驱动。对经常在不同电脑上调试的人来说这套排查思路是通用的。5. 常见问题与排查技巧实录5.1 设备列表里看不到/dev/ttyUSB0这是最典型的问题。插上USB转串口模块后CuteCom的设备下拉列表里没有/dev/ttyUSB0。原因一般是内核没识别到设备或者是你没刷新列表。处理步骤在终端执行lsusb看看有没有对应的USB设备。CH340一般显示为1a86:7523CP210x显示为10c4:ea60FT232显示为0403:6001。如果lsusb里有设备但/dev/ttyUSB0不存在多半是驱动没加载。执行sudo modprobe ch341或者sudo modprobe cp210x加载对应模块。如果加载了还是没节点尝试换一根USB线。我之前遇到过线材质量差只有电源线没有数据线的情况插上去只充电不识别这坑很常见。CuteCom设备下拉列表不会实时刷新。比如你打开CuteCom时设备还没插好插好后下拉列表里依然没有。解决办法是关掉CuteCom重新打开或者点设备下拉框旁边的小箭头看是否有Refresh选项。所以操作顺序上建议先插好USB转串口模块再打开CuteCom。5.2 打开串口提示Permission denied这个我前面详细讲过了核心就是用户不在dialout组。但还有一种特殊情况就是系统里有其他程序占用了串口。比如你之前用screen连着退出时没按正确姿势后台进程还占着串口CuteCom自然打不开。排查方法sudo lsof /dev/ttyUSB0如果有进程在占用会显示进程号和命令名。用sudo kill -9 进程号强制结束然后再打开CuteCom。我经常遇到的情况是之前调试时开着的minicom没真正退出占用了/dev/ttyUSB0结果CuteCom怎么都打不开最后杀掉minicom进程才解决。所以遇到打开失败的提示先怀疑权限再怀疑占用。5.3 能打开串口但收不到数据或者全是乱码乱码问题优先排查以下三个方向第一波特率是否匹配。发送方和接收方的波特率必须完全一致差一点点都会乱码。注意有些设备出厂默认是115200但可能是双倍波特率或者半波特率可以在附近几个选项试试比如57600、38400。第二数据位、校验位、停止位是否一致。大多数设备都是8N1但是也有例外。比如有些工业仪表用7E1即7位数据、偶数校验、1位停止位。参数完全不设对比如停止了位设成2数据看起来就是乱的。第三TXD/RXD是否接反。这个问题在自制连接线上太常见了。记住一个原则设备的TXD要接USB转串口模块的RXD设备的RXD要接模块的TXD地线一定要共地。如果你用杜邦线自己接建议先看模块上引脚丝印不要想当然。如果以上都排除了还是乱码就要怀疑硬件问题了。比如USB转串口模块的晶振精度不够会造成波特率偏移短距离调试偶尔能用长距离或者干扰大的时候就会随机错位。我在一个野外的项目现场就遇到过笔记本连设备就是乱码接台式机就正常后来发现是那个USB转串口模块的晶振漂移了换了一个模块就好了。5.4 Hex发送和字符串发送的困惑很多从Windows下串口助手转过来的用户对CuteCom的Hex模式有误解。在Windows下的串口助手里勾选HEX发送后输入01 03 00 00表示发4个字节但在CuteCom里如果勾选了Hex模式你输入01 03 00 00它也是按4个字节发送这点是一致的。容易出错的是带空格的hex和不带空格的hex的兼容性。CuteCom默认能识别01 03 00 00这种带空格的写法但如果你习惯写01030000这种紧凑格式CuteCom也认只要每两个十六进制字符作为一个字节即可前提是勾选了Hex模式。如果没勾选Hex模式无论你怎么输入都会被当成ASCII字符发送很多新手就在这儿栽了跟头。另外还有一个细节就是发送框里的\r\n。在ASCII模式下CuteCom会把\r\n原样解析成回车换行符这个特性非常实用。比如你给模块发送AT指令需要在末尾加回车直接在输入框写AT\r\n就行不用手动去敲看不见的回车。如果你的设备手册要求ATOK后面必须有回车那在CuteCom里发ATOK\r\n就能得到正确效果。这个转义解析功能在Hex模式下无效因为Hex模式下输入框里的每个字符都是按字节解析的。5.5 小技巧用CuteCom搭配脚本做自动化测试如果你想更进一步CuteCom还可以配合外部脚本完成自动化。思路是用CuteCom的日志保存功能把接收数据写到文件然后在你的脚本里读取这个文件做分析。我之前做过一个简单的压力测试脚本每秒钟发送一次固定指令同时监控日志文件里是否正确返回了预期的响应。如果连续多次没有正确响应就判定为通信异常并记录时间点。这种自动化方式虽然比较土但不依赖额外的库稳定可靠。对比直接用Python的serial库写程序CuteCom这边有一个优势你能先手动确认通信正常把参数和报文都调对了再启动脚本去跑。如果是纯代码开发万一报文格式错了排查起来成本高得多。所以对于临时测试和验证CuteCom加脚本算是一个效率很高的组合。6. 分享几个从长期使用中总结的小细节最后聊几个CuteCom使用过程中容易被忽略、但实际很影响体验的细节。第一打开串口之前先确认/dev/ttyUSB0存在并且你属于dialout组。这两个前提不满足后面所有操作都是白费。次次都先检查一下养成习惯后能省很多无用功。第二CuteCom的接收区有最大行数限制长时间开机接收大量数据旧数据会被自动挤掉。如果你要长时间监控并且需要保留全部数据务必把日志保存功能打开。我的习惯是一开始调试就开启日志保存即使暂时用不到也比事后发现数据丢了强。第三CuteCom在Line breaks设置里有几个可选项可以控制接收到的数据如何换行。默认不自动换行数据很长时可能会挤在一起。调试那种连续输出的设备时把Append LF打开接收区数据会整齐很多看起来不累。第四如果你需要同时调试多路串口开多个CuteCom实例就行互不干扰。我调试一个主从设备通信时同时开两个CuteCom一个连主设备一个连从设备两边数据对照着看问题定位就非常快。说实话用过这么多年串口工具CuteCom不算功能最全的但它的轻量、稳定、上手快让我在日常调试中一直留着它。比起每次调试都要背命令参数、建配置文件、记热键的minicomCuteCom这种打开就用的图形化工具属于用过就回不去的类型。如果你刚开始在Ubuntu下做串口开发或者正被minicom折腾得恼火装一个CuteCom试试大概率会让你的调试体验提升一个台阶。
Ubuntu 22.04下CuteCom串口调试工具安装配置与实战指南
做嵌入式、单片机开发或者偶尔折腾路由器、交换机的人一定绕不开串口调试这关。不管是看启动日志、调AT指令还是和传感器模块对接都得跟串口打交道。Ubuntu 22.04下很多人第一反应是minicom或者screen但命令行工具参数多、界面不直观尤其是要频繁切换波特率、发送hex数据的时候效率真的堪忧。这篇文章重点聊聊CuteCom这个图形化串口调试工具在Ubuntu 22.04上从安装、配置到实测的完整过程以及我踩过的几个坑。CuteCom是一款基于Qt的轻量级串口调试助手界面简洁操作逻辑和Windows下常见的串口助手基本一致非常适合刚切换到Linux或者不爱记命令的开发者也能让老手在调试时省下不少时间。如果你正在找Ubuntu下的串口图形化工具这篇文章可以直接帮你落地。文中涉及的所有操作都在Ubuntu 22.04上实测过确认可用。1. 为什么我弃用minicom改用CuteCom1.1 命令行串口工具有什么痛点minicom和screen在Linux下确实够用但实际用起来问题不少。minicom的配置菜单是基于文本的第一次进去要先设置串口设备、波特率还经常遇到按键不生效的情况比如CtrlA是菜单键结果发到设备端成了别的字符。screen更极简启动参数全靠记忆screen /dev/ttyUSB0 115200这种命令稍微复杂一点的场景就吃力了。我调试一块ESP32开发板时需要先以115200波特率看日志然后切换到9600读某个传感器的数据最后还要以74880这个非标准波特率查看上电信息。用minicom的话每切换一次波特率都得进配置菜单来回至少六步操作实际用起来非常痛苦。命令行工具不是不能用而是这种高频的参数切换操作效率太低还容易出错。CuteCom的好处在于所有关键参数都在主界面上直接列出来波特率、数据位、停止位、校验位、流控方式下拉框随手一点就切换改了立刻生效不需要保存配置再退出重进。这一点在实际调试中的价值比界面好不好看重要得多。1.2 CuteCom和几款主流工具的横向对比拿CuteCom和Ubuntu下常见的几款串口工具做个对比方便你判断哪个适合自己。工具界面类型配置复杂度非标准波特率支持定时发送hex收发适合场景minicom终端文本高一般不支持支持但麻烦老牌服务器调试screen终端高依赖内核不支持不支持临时应急CuteComQt图形化低支持自定义支持支持嵌入式开发日常putty图形化低一般不支持不支持SSH串口两用CuteCom在设备列表刷新、打开失败提示、数据接收显示这几个环节上对新手特别友好。设备没插好或者权限不足时它会直接弹对话框告诉你原因而不是像终端工具那样无声无息地卡住。这个失败时给反馈的特性对排查问题帮助很大。2. Ubuntu 22.04安装CuteCom的两种方式与权限配置2.1 用apt安装最简单的方式Ubuntu 22.04的官方软件源里直接有CuteCom安装非常简单sudo apt update sudo apt install cutecom装完就能用不需要额外配置依赖。官方源的版本虽然不是最新的但功能和稳定性完全够用。这类串口工具本质上是对内核tty子系统的封装版本新旧对实际功能的影响不大稳定才是关键。启动方式有两种一种是在终端输入cutecom另一种是在应用菜单里搜索CuteCOM点图标。我建议日常用终端启动因为能看到有没有报错信息比如权限不足之类的错误会直接打印在终端里。2.2 想用新版本源码编译安装apt源里的版本可能滞后如果你想用新版本可以去GitHub拉源码编译。CuteCom依赖Qt开发库编译前需要先装sudo apt install qtbase5-dev libqt5serialport5-dev cmake g git clone https://github.com/neundorf/CuteCom.git cd CuteCom mkdir build cd build cmake .. make -j4 sudo make install编译过程中最常见的坑是缺Qt模块。如果你在cmake阶段报找不到Qt5的包检查一下qtbase5-dev装了没有。源码编译的好处是版本新界面和功能可能更多但对普通用户来说apt版已经足够没必要自己编译。2.3 串口权限问题90%的新手都卡在这装好CuteCom后双击打开在Device下拉框里选了/dev/ttyUSB0点击Open结果弹窗提示无法打开。这个问题的根本原因是当前用户没有访问串口设备的权限。Linux下串口设备属于dialout组普通用户不在这个组里就没权限读写。解决方法很直接把当前用户添加到dialout组sudo usermod -aG dialout $USER改完之后需要注销重新登录或者重启电脑才能生效。验证是否生效groups如果输出里能看到dialout就说明成功了。不想注销的话也可以用newgrp dialout临时切换组身份但只对当前终端有效治标不治本。还有一种临时方案是直接sudo cutecom启动但我不推荐因为以后每次都得sudo而且以root身份运行图形工具万一操作失误影响面更大。3. CuteCom核心功能拆解与实操配置3.1 界面布局与关键参数设置CuteCom的主界面分两大块上半部分是一排串口参数配置项下半部分是接收区和发送区。接收区默认显示收到的数据发送区是你编辑要发送的内容。参数配置这块我用一个实际场景来说明。假设你手里有一块GPS模块手册上写着串口参数是115200, 8, N, 1意思就是波特率115200、数据位8位、无校验、停止位1位。在CuteCom里这样设置Device选择/dev/ttyUSB0或者/dev/ttyS0根据你的设备实际节点来Baud rate下拉选择115200Data bits8Stop bits1ParityNoneFlow controlNone这里解释一下这些参数为什么这么设。串口通信的双方必须使用完全相同的参数否则数据在底层就会被错误解析表现出来就是乱码或者完全收不到。数据位8位是标准配置因为ASCII字符是8位的绝大多数设备默认都是这个值。停止位1位是最常见的它的作用是一个字节传输结束的分隔符。校验位用来检测传输错误的一个bit像GPS模块这种短距离低干扰场景通常不需要校验所以选None。流控分为硬件流控(RTS/CTS)和软件流控(XON/XOFF)。最常遇到的问题就是流控设错了导致设备不响应。我调试一个工业级串口屏时因为默认开启了硬件流控发送指令后屏幕毫无反应排查了半天才发现是这个问题。所以如果设备不响应第一件事就是检查流控是不是设成了None。3.2 基于真实板卡的收发测试流程用一块常见的CH340芯片USB转串口模块连接STM32开发板我走一遍完整流程。准备材料CH340 USB转TTL模块一个STM32F103C8T6最小系统板一块杜邦线三根USB线一根连线方式CH340模块的TXD接STM32的RXRXD接STM32的TXGND接GND。注意TXD和RXD要交叉连接不能直连。如果CH340模块没有RTS/DTR引脚的话可以不管如果带了就不要接STM32的BOOT0和BOOT1否则STM32可能意外进入串口下载模式。打开CuteCom设备选择/dev/ttyUSB0波特率115200数据位8停止位1无校验无流控点击Open按钮状态栏会变成绿色显示Opened。STM32板的程序很简单#include stm32f1xx_hal.h UART_HandleTypeDef huart1; static void MX_GPIO_Init(void); static void MX_UART1_Init(void); int main(void) { HAL_Init(); MX_GPIO_Init(); MX_UART1_Init(); uint8_t rxBuf[64]; while (1) { uint8_t len 0; uint8_t data; while (HAL_UART_Receive(huart1, data, 1, 100) HAL_OK) { rxBuf[len] data; if (data \n || len 64) break; } HAL_UART_Transmit(huart1, rxBuf, len, 100); HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); } }这段程序的作用是每收到一行数据以换行符结尾就原样回送同时翻转板载LED。这样就能在CuteCom里直观验证发送-接收-板上执行这一完整链路。实测操作在CuteCom的Input框里输入hello\r\n点Send。如果一切正常接收区会原样显示hello\r\n同时STM32板上的LED会翻转一次。如果LED亮了但接收区没显示说明回发通路有问题重点检查RXD/TXD是否交叉接反。输入AT\r\n如果LED翻转但没回显说明发送路径没问题接收路径出问题了大概率是TXD/RXD接错。如果LED都不闪烁说明发送本身就失败检查CH340模块是否被系统识别。3.3 定时发送与hex模式调试传感器的好帮手CuteCom的定时发送功能在多传感器数据读取场景里特别有用。比如读取一个温湿度传感器传感器要求主机每隔100ms发送一次查询命令用手工点发送按钮完全不现实用定时发送就能解决。在Options菜单里勾选Send on timer设置间隔时间单位是毫秒。我调试SHT30温湿度传感器时就是用的这个功能每200ms发一次读命令0x2C 0x06数据就源源不断地回传下来配合日志保存功能连续观察温度变化曲线非常方便。Hex模式也需要重点说明。很多传感器和模组的指令手册里指令都是十六进制表示的比如0x01 0x03 0x00 0x00 0x00 0x01 0x84 0x0A这种。默认的ASCII模式下输入这些会被当成普通文本发送设备根本看不懂。勾选Hex模式后CuteCom就会把输入框里的内容按十六进制逐字节发送同时接收区的显示也会变成十六进制格式。我遇到过一种情况某温控模块需要发送特定字节里面包含不可见字符0xFF和0x00。ASCII模式下这两个字符会被处理成文本或者直接吞掉怎么发都不对。换成Hex模式输入FF 00 A1一秒钟搞定。所以遇到指令包含非ASCII字符或者需要精确控制字节内容时一定记得切到Hex模式。3.4 日志保存复现Bug和自动化分析的基础CuteCom支持把接收到的数据保存到文件。这个功能看似简单但在实际调试中价值很大。之前排查一个串口通信偶发丢包的问题让我盯着屏幕看了半小时那数据一闪就过去了根本没法逐帧分析。后面把日志开起来把收到的几十万条数据全部保存成文件再用Python脚本去统计帧间隔和丢包率问题原因一下就找到了。操作方法是点击工具栏上的Save接收日志图标选择文件路径。CuteCom保存的是原始数据没有添加任何时间戳之类的东西。如果你想带时间戳可以自己在接收数据中插入时间标记或者写个小脚本监控日志文件。我在实际项目中会把CuteCom的日志文件直接喂给Python的serial库做离线回放用来复现设备端的问题。4. 实际工作中最常用的三种CuteCom使用场景4.1 场景一读取传感器/模块数据以读取一个常见的GPS模块为例完整的调试流程是这样的。GPS模块上电后一般默认以9600波特率输出NMEA 0183格式的数据就是$GPGGA,....开头的那种ASCII文本。打开CuteCom设备选对波特率设9600打开串口。正常情况下接收区会不断滚动输出类似这样的数据$GPGGA,083559.00,3404.70417,N,11726.34356,W,1,12,1.0,0.0,M,0.0,M,,*6A $GPGSA,A,3,04,05,06,13,12,24,21,19,17,32,01,18,0.8,0.6,1.2*38如果没有任何输出优先检查模块的供电是否正常、TXD是否接到了CuteCom对应的RXD、波特率是否匹配。注意GPS模块的TX引脚一般是3.3V电平如果你的USB转串口模块不支持3.3V需要加电平转换否则可能损坏模块也可能就是收不到数据。如果需要主动向模块发送配置命令比如把波特率从9600改成115200就要在Input框输入$PMTK251,115200*2A\r\n然后点Send。之后模块会以115200重新输出数据。这时候把CuteCom的波特率也切到115200就能继续正常收数据。实战里我一般先把数据保存下来等到波特率切换生效后再看新数据是否正常方便回看。4.2 场景二调试路由器/嵌入式Linux开发板的串口登录玩过路由器或者嵌入式Linux开发板的人一定懂串口登录是急救手段。系统起不来、SSH没配置好的时候串口是唯一的救命通道。CuteCom在这种情况下完全能替代minicom。NanoPi系列开发板出厂自带U-Boot通过串口可以看到启动日志。打开CuteCom波特率设为115200具体看板子手册打开串口然后给开发板上电。接收区会刷出类似这样的启动日志U-Boot 2018.01-rc2 (Jan 10 2019 - 10:38:15 0000) DRAM: 1 GiB MMC: sdhcife330000: 0, mmcfe320000: 1这时可以敲回车进入U-Boot命令行。这就能在U-Boot阶段设置启动参数、擦写flash、引导系统内核功能上和minicom没什么区别。我在给一个开发板刷系统时因为分区表写错了内核永远起不来。这种情况下SSH根本不可能网口也不一定有IP。幸好有CuteCom连上了串口在U-Boot里重新设置bootcmd把启动命令改回正确的分区表路径救回来了。这个场景里CuteCom的图形界面优势很明显看不到U-Boot菜单时可以直接看到完整滚动的历史输出而不像minicom那样需要额外配置scrollback buffer。4.3 场景三调试自制USB转串口模块和设备识别还有一种需求不仅仅是调设备而是要确认USB转串口模块本身有没有被系统识别。插入USB转串口模块后先执行dmesg | tail ls -l /dev/ttyUSB*正常情况会看到类似usb 1-2: cp210x converter now attached to ttyUSB0的提示。如果没有这个提示说明驱动没加载或者硬件有问题。在Windows上常见的问题是插入串口设备显示未知设备在Ubuntu下一般不会出现这种情况只要内核识别了USB设备就会自动创建/dev/ttyUSB0节点。如果内核识别了但CuteCom还打不开那就回到用户组权限的问题按我之前说的dialout组配置一遍就行。CuteCom捕获到的异常信息比Windows下的设备管理器要详细得多例如我可以从dmesg输出判断是CH340、CP210x还是FT232芯片然后根据芯片类型决定是否需要额外驱动。对经常在不同电脑上调试的人来说这套排查思路是通用的。5. 常见问题与排查技巧实录5.1 设备列表里看不到/dev/ttyUSB0这是最典型的问题。插上USB转串口模块后CuteCom的设备下拉列表里没有/dev/ttyUSB0。原因一般是内核没识别到设备或者是你没刷新列表。处理步骤在终端执行lsusb看看有没有对应的USB设备。CH340一般显示为1a86:7523CP210x显示为10c4:ea60FT232显示为0403:6001。如果lsusb里有设备但/dev/ttyUSB0不存在多半是驱动没加载。执行sudo modprobe ch341或者sudo modprobe cp210x加载对应模块。如果加载了还是没节点尝试换一根USB线。我之前遇到过线材质量差只有电源线没有数据线的情况插上去只充电不识别这坑很常见。CuteCom设备下拉列表不会实时刷新。比如你打开CuteCom时设备还没插好插好后下拉列表里依然没有。解决办法是关掉CuteCom重新打开或者点设备下拉框旁边的小箭头看是否有Refresh选项。所以操作顺序上建议先插好USB转串口模块再打开CuteCom。5.2 打开串口提示Permission denied这个我前面详细讲过了核心就是用户不在dialout组。但还有一种特殊情况就是系统里有其他程序占用了串口。比如你之前用screen连着退出时没按正确姿势后台进程还占着串口CuteCom自然打不开。排查方法sudo lsof /dev/ttyUSB0如果有进程在占用会显示进程号和命令名。用sudo kill -9 进程号强制结束然后再打开CuteCom。我经常遇到的情况是之前调试时开着的minicom没真正退出占用了/dev/ttyUSB0结果CuteCom怎么都打不开最后杀掉minicom进程才解决。所以遇到打开失败的提示先怀疑权限再怀疑占用。5.3 能打开串口但收不到数据或者全是乱码乱码问题优先排查以下三个方向第一波特率是否匹配。发送方和接收方的波特率必须完全一致差一点点都会乱码。注意有些设备出厂默认是115200但可能是双倍波特率或者半波特率可以在附近几个选项试试比如57600、38400。第二数据位、校验位、停止位是否一致。大多数设备都是8N1但是也有例外。比如有些工业仪表用7E1即7位数据、偶数校验、1位停止位。参数完全不设对比如停止了位设成2数据看起来就是乱的。第三TXD/RXD是否接反。这个问题在自制连接线上太常见了。记住一个原则设备的TXD要接USB转串口模块的RXD设备的RXD要接模块的TXD地线一定要共地。如果你用杜邦线自己接建议先看模块上引脚丝印不要想当然。如果以上都排除了还是乱码就要怀疑硬件问题了。比如USB转串口模块的晶振精度不够会造成波特率偏移短距离调试偶尔能用长距离或者干扰大的时候就会随机错位。我在一个野外的项目现场就遇到过笔记本连设备就是乱码接台式机就正常后来发现是那个USB转串口模块的晶振漂移了换了一个模块就好了。5.4 Hex发送和字符串发送的困惑很多从Windows下串口助手转过来的用户对CuteCom的Hex模式有误解。在Windows下的串口助手里勾选HEX发送后输入01 03 00 00表示发4个字节但在CuteCom里如果勾选了Hex模式你输入01 03 00 00它也是按4个字节发送这点是一致的。容易出错的是带空格的hex和不带空格的hex的兼容性。CuteCom默认能识别01 03 00 00这种带空格的写法但如果你习惯写01030000这种紧凑格式CuteCom也认只要每两个十六进制字符作为一个字节即可前提是勾选了Hex模式。如果没勾选Hex模式无论你怎么输入都会被当成ASCII字符发送很多新手就在这儿栽了跟头。另外还有一个细节就是发送框里的\r\n。在ASCII模式下CuteCom会把\r\n原样解析成回车换行符这个特性非常实用。比如你给模块发送AT指令需要在末尾加回车直接在输入框写AT\r\n就行不用手动去敲看不见的回车。如果你的设备手册要求ATOK后面必须有回车那在CuteCom里发ATOK\r\n就能得到正确效果。这个转义解析功能在Hex模式下无效因为Hex模式下输入框里的每个字符都是按字节解析的。5.5 小技巧用CuteCom搭配脚本做自动化测试如果你想更进一步CuteCom还可以配合外部脚本完成自动化。思路是用CuteCom的日志保存功能把接收数据写到文件然后在你的脚本里读取这个文件做分析。我之前做过一个简单的压力测试脚本每秒钟发送一次固定指令同时监控日志文件里是否正确返回了预期的响应。如果连续多次没有正确响应就判定为通信异常并记录时间点。这种自动化方式虽然比较土但不依赖额外的库稳定可靠。对比直接用Python的serial库写程序CuteCom这边有一个优势你能先手动确认通信正常把参数和报文都调对了再启动脚本去跑。如果是纯代码开发万一报文格式错了排查起来成本高得多。所以对于临时测试和验证CuteCom加脚本算是一个效率很高的组合。6. 分享几个从长期使用中总结的小细节最后聊几个CuteCom使用过程中容易被忽略、但实际很影响体验的细节。第一打开串口之前先确认/dev/ttyUSB0存在并且你属于dialout组。这两个前提不满足后面所有操作都是白费。次次都先检查一下养成习惯后能省很多无用功。第二CuteCom的接收区有最大行数限制长时间开机接收大量数据旧数据会被自动挤掉。如果你要长时间监控并且需要保留全部数据务必把日志保存功能打开。我的习惯是一开始调试就开启日志保存即使暂时用不到也比事后发现数据丢了强。第三CuteCom在Line breaks设置里有几个可选项可以控制接收到的数据如何换行。默认不自动换行数据很长时可能会挤在一起。调试那种连续输出的设备时把Append LF打开接收区数据会整齐很多看起来不累。第四如果你需要同时调试多路串口开多个CuteCom实例就行互不干扰。我调试一个主从设备通信时同时开两个CuteCom一个连主设备一个连从设备两边数据对照着看问题定位就非常快。说实话用过这么多年串口工具CuteCom不算功能最全的但它的轻量、稳定、上手快让我在日常调试中一直留着它。比起每次调试都要背命令参数、建配置文件、记热键的minicomCuteCom这种打开就用的图形化工具属于用过就回不去的类型。如果你刚开始在Ubuntu下做串口开发或者正被minicom折腾得恼火装一个CuteCom试试大概率会让你的调试体验提升一个台阶。
