ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

嵌入式开发必备:VSPD虚拟串口调试实战指南

嵌入式开发必备:VSPD虚拟串口调试实战指南 1. 为什么嵌入式开发者需要一个假的串口搞嵌入式开发的人电脑上插着三四个USB转串口模块是常态。STM32核心板一个、ESP32模组一个、还有个老设备调试口占着一个USB Hub插满了不说设备管理器里那一堆COM口号还经常打架。更头疼的是很多调试场景压根不需要真实硬件——比如上位机协议解析逻辑的验证、串口通信状态机的单元测试、或者单纯想模拟两个设备之间的数据对发。这时候如果还靠插拔硬件来切换效率低得让人抓狂。VSPDVirtual Serial Port Driver就是解决这个问题的。它能在Windows系统里凭空创建出一对或多对虚拟串口这些串口在设备管理器里看起来和真实的物理串口没有任何区别应用程序打开COM口、设置波特率、收发数据所有操作都跟操作真实串口一模一样。但数据实际上是在内存里从一个虚拟口流向另一个虚拟口完全不经过物理线路。这个工具在嵌入式开发中的价值我总结下来主要是三个场景。第一是协议栈开发阶段你写了一个Modbus RTU的主站程序但手头没有从站设备用VSPD建一对虚拟口一个口给主站程序另一个口用串口调试助手模拟从站响应整个通信链路就能跑通。第二是多设备联调比如你的系统里有一个主控通过串口连接一个4G模组和一个传感器真实硬件还没到齐用VSPD建两对虚拟口把三个程序分别绑定到对应的COM口上逻辑层面的联调可以提前完成。第三是自动化测试CI流水线里不可能挂一堆真实串口设备虚拟串口对配合脚本就能实现串口通信的自动化回归测试。这篇文章面向的是有一定Windows操作基础、正在做嵌入式开发或串口通信相关工作的工程师。不管你是刚接触STM32串口调试的新手还是已经在做嵌入式Linux应用开发的老手只要你的工作涉及Windows环境下的串口通信验证VSPD都能帮你省下大量插拔硬件和等待设备的时间。下面我会从安装、配置、调试技巧到常见问题排查把整个流程拆开讲清楚。2. VSPD 7.2的安装与授权从下载到可用状态2.1 安装包获取与版本选择VSPD的版本迭代不算快7.2版是目前在Windows 10和Windows 11上兼容性最稳定的一个版本。网上流传的版本很多有7.0、7.1、8.0甚至9.0的但我实测下来7.2在驱动签名和系统兼容性之间平衡得最好。8.0之后的版本对Windows 11的驱动强制签名要求更严格安装过程中容易卡在驱动安装环节。下载渠道方面建议从官方渠道获取安装包。安装包本身不大大概5MB左右安装后的驱动文件也就几百KB。需要注意的是网上有些所谓的绿色版或便携版这类版本通常缺少数字签名的驱动程序在Windows 10 1903之后的版本上安装会直接失败系统会拦截未签名的驱动加载。所以如果你看到安装过程中弹出Windows无法验证此驱动程序软件的发布者的警告说明你拿到的安装包驱动签名有问题换一个来源重新下载。安装前有一个准备工作容易被忽略关闭所有正在使用串口的程序。包括串口调试助手、Putty、SecureCRT、Arduino IDE的串口监视器等等。因为安装过程需要替换系统的串口驱动文件如果有程序正在占用串口资源安装程序会提示文件被占用导致安装不完整。我遇到过好几次装完之后虚拟串口创建失败排查半天发现是后台还挂着一个串口监视器没关。2.2 安装过程中的关键选项双击安装包后安装向导的步骤不多但有两个地方需要留意。第一个是驱动安装确认。安装程序会提示即将安装虚拟串口驱动这个驱动是VSPD的核心组件它向Windows系统注册一个虚拟的串口设备类。在Windows 10上可能会弹出两次驱动安装确认窗口一次是安装VSPD的主驱动一次是安装串口枚举器驱动。两次都要选择安装或仍然安装。如果只点了一次后面创建虚拟串口时会出现无法创建端口的错误。第二个是安装路径选择。默认路径是C:\Program Files (x86)\Virtual Serial Port Driver\建议保持默认。有些朋友喜欢把工具都装到D盘但VSPD的驱动文件路径是写在注册表里的如果安装后手动移动了文件夹驱动会找不到对应的可执行文件导致虚拟串口创建后无法正常收发数据。安装完成后需要重启系统。这一步不能跳过因为驱动加载需要在系统启动时完成初始化。我试过不重启直接打开VSPD界面能打开但创建虚拟串口时一直转圈然后报错。重启之后一切正常。2.3 授权状态确认与功能限制VSPD 7.2安装后默认是试用版试用版可以创建虚拟串口对但有一些限制创建的虚拟串口对数量有限制通常是2对而且每次重启系统后可能需要重新创建。对于临时调试来说试用版其实够用但如果你需要长期稳定的多对虚拟串口就需要进行授权。授权的方式是在软件界面里输入序列号。这里要提醒一句网上搜到的很多注册码或激活码要么已经失效要么对应的版本不匹配。7.2版的授权机制和7.1、8.0都不通用。如果你输入了一个格式看起来正确但提示无效的序列号大概率是版本不对应。授权成功后软件界面上方的状态栏会显示Licensed to加上授权信息同时创建虚拟串口的数量限制会解除。我个人的建议是如果只是短期项目调试试用版完全够用如果是团队长期使用走正规渠道获取授权省去后面反复折腾的时间。3. 虚拟串口对的创建与管理核心操作详解3.1 创建第一对虚拟串口打开VSPD的主界面布局很简洁左侧是Serial ports列表显示当前系统已有的物理串口和虚拟串口右侧是Virtual serial port pairs区域用来创建和管理虚拟串口对。创建一对虚拟串口的操作很直接在右侧的Pair下拉框里选择一对尚未被占用的COM口号比如COM10和COM11然后点击Add pair按钮。软件会立即在系统里注册这两个虚拟串口设备左侧列表里会同时出现COM10和COM11并且标注为Virtual。这里有一个细节值得展开说为什么是一对而不是一个。VSPD创建的虚拟串口是成对出现的两个口之间有一条虚拟的零调制解调器线连接。你往COM10写数据COM11就能读到往COM11写COM10就能读到。这模拟的是两个设备通过串口线直连的场景。如果你只需要一个虚拟串口来假装有一个设备那创建一对之后只用其中一个口就行另一个口留着不用也不影响。COM口的选择上建议避开系统已经占用的低编号端口。Windows系统本身可能会保留COM1到COM4给一些传统设备虽然现在很多电脑没有物理串口了但系统保留的端口号仍然存在。我一般从COM10开始往上选这样不容易和物理串口冲突。如果你不确定哪些端口被占用了可以在创建前打开设备管理器展开端口(COM和LPT)看看已有的端口号分布。3.2 批量创建与命名管理实际项目中经常需要模拟多个设备同时通信。比如你要模拟一个主控连接三个从站设备的场景那就需要创建三对虚拟串口。VSPD支持批量创建在右侧区域连续添加多对即可。但这里有个经验不要一次性创建太多。我试过一次性创建8对虚拟串口结果系统里突然多出16个COM口设备管理器刷新了好几次才全部识别出来而且有些串口调试助手在枚举端口列表时直接卡死了。后来我改成每次创建2到3对创建完等几秒钟让系统完成设备枚举再继续创建就稳定多了。创建好的虚拟串口对可以在右侧列表里看到每一对显示为COMx - COMy的形式。如果你觉得COM10、COM11这样的编号不好记VSPD本身不提供重命名功能但你可以通过Windows设备管理器来修改端口的友好名称。在设备管理器里右键虚拟串口选择属性在端口设置选项卡里点击高级底部的COM端口号可以修改但注意不要改成已经被占用的端口号。3.3 删除与重新配置删除虚拟串口对的操作同样简单在右侧列表里选中要删除的端口对点击Delete pair按钮。但这里有一个容易踩的坑如果虚拟串口正在被程序占用比如串口调试助手还开着这个COM口删除操作会失败但VSPD可能不会给出明确的错误提示只是端口对从列表里消失了实际上驱动层面的虚拟串口还在。这种情况下正确的做法是先关闭所有打开该串口的程序然后在VSPD里删除端口对最后重启一次系统。重启后打开设备管理器确认虚拟串口已经消失。如果重启后还在说明驱动层面的注册信息没有清理干净需要手动在设备管理器里卸载对应的虚拟串口设备然后重新安装VSPD驱动。另外VSPD的配置是持久化的。你创建了一对COM10和COM11重启系统后这对虚拟串口仍然存在不需要每次开机重新创建。这个特性对于需要长期保持调试环境的场景很友好。但如果你临时创建了很多对项目结束后记得清理掉不然系统里会积累一堆无用的虚拟串口影响后续的端口管理。4. 串口调试实战从回环测试到协议模拟4.1 用串口调试助手做回环验证虚拟串口创建好之后第一件事应该是验证这对串口是否真的能正常收发数据。最直接的方法就是用两个串口调试助手分别打开这对虚拟串口一个发一个收。具体操作打开两个串口调试助手实例比如sscom或xcom第一个打开COM10第二个打开COM11波特率都设为115200数据位8停止位1无校验。然后在第一个助手的发送区输入Hello点击发送。如果第二个助手的接收区出现了Hello说明虚拟串口对工作正常。这个测试看起来简单但有几个细节会影响结果。波特率必须一致虽然虚拟串口不涉及实际的时钟分频但VSPD会模拟波特率匹配的逻辑如果两边设置不同数据可能无法正确传输。流控设置要一致默认是无流控如果你在一端开了硬件流控而另一端没开数据流会被阻塞。串口调试助手的自动断帧功能可能会影响接收显示如果发送的数据没有换行符有些助手会把多帧数据合并显示看起来像是丢包了实际上是显示逻辑的问题。我个人的习惯是回环测试时发送一串包含数字、字母和特殊字符的测试数据比如ABC123!#这样能同时验证数据完整性和字符编码处理。如果接收端显示的内容和发送端完全一致说明虚拟串口的基本通信功能没有问题。4.2 模拟设备响应协议调试的核心技巧回环测试通过后就可以进入真正的调试场景了。假设你在开发一个STM32的Modbus RTU主站程序需要验证主站发送的请求帧是否正确以及主站能否正确解析从站的响应帧。用VSPD建一对COM10和COM11。STM32主站程序运行在PC上的模拟程序或通过USB转串口连接的真实STM32绑定到COM10。串口调试助手打开COM11用来模拟从站设备。调试的第一步是验证请求帧格式。主站程序发送一帧Modbus请求比如读取保持寄存器的功能码03从站地址01起始地址0000寄存器数量000A。串口调试助手在COM11端应该收到这样的十六进制数据01 03 00 00 00 0A C5 CD。如果收到的数据不对比如地址错了、功能码错了、或者CRC校验不对那就说明主站程序的帧组装逻辑有问题。第二步是模拟从站响应。在串口调试助手里手动构造一帧响应数据比如01 03 14 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 0A XX XX其中14是字节数10个寄存器共20字节后面是10个寄存器的值最后是两个字节的CRC。把这帧数据通过COM11发送出去观察主站程序能否正确解析出10个寄存器的值。这个过程中有一个非常实用的技巧在串口调试助手里开启定时发送功能让从站响应帧每隔100ms自动发送一次。这样主站程序可以连续收到多帧响应方便测试程序的稳定性和异常处理逻辑。我调试Modbus主站时经常这么干比手动一帧一帧点发送效率高得多。4.3 多对虚拟串口协同复杂系统联调当系统里有多个串口设备需要同时模拟时VSPD的多对虚拟串口就派上用场了。举个例子一个嵌入式网关设备通过串口1连接4G模组AT指令通过串口2连接温湿度传感器Modbus RTU通过串口3输出调试日志。用VSPD创建三对虚拟串口COM10-COM11、COM12-COM13、COM14-COM15。网关程序分别打开COM10、COM12、COM14。然后开三个串口调试助手分别打开COM11、COM13、COM15对应模拟4G模组、传感器和日志接收端。这种场景下的调试要点是数据隔离。三对虚拟串口之间的数据是完全独立的COM10发出去的数据只会出现在COM11不会串到COM12或COM14。这一点VSPD做得很好底层是独立的内存缓冲区不存在数据交叉的问题。但要注意程序端的串口打开顺序。有些嵌入式程序在启动时会按固定顺序打开串口如果某个串口打开失败程序可能直接退出。用虚拟串口调试时要确保所有需要的虚拟串口都已经在VSPD里创建好并且没有被其他程序占用。我遇到过一种情况网关程序启动时先打开COM10再打开COM12但COM12被之前没关掉的串口调试助手占用了导致程序打开COM12失败后直接崩溃。排查了半天才发现是调试助手没关。4.4 串口调试助手的选择与配置要点说到串口调试助手市面上选择很多sscom、xcom、友善串口调试助手、AccessPort等等。我平时用得最多的是sscom和xcom两个各有特点。sscom的优势是十六进制显示和发送做得很顺手支持自动添加CRC校验、支持多条发送指令的预设、支持定时发送。调试Modbus协议时sscom的多条字符串发送功能特别实用可以把常用的请求帧和响应帧都预设好调试时直接点对应的按钮就行。xcom的优势是界面简洁、资源占用低而且支持串口数据的实时波形显示。如果你调试的是传感器数据想把收到的数值直接画成曲线xcom的波形显示功能比sscom更方便。配置上有几个参数需要特别注意。接收缓冲区大小默认通常是4096字节如果你调试的场景数据量比较大比如高速数据采集建议调到8192或更大避免数据溢出丢失。接收超时这个参数决定了串口助手多久没有收到新数据就认为一帧结束。对于变长协议超时设置很关键设得太短会把一帧数据拆成多帧设得太长会把多帧数据合并成一帧。我一般设20ms到50ms之间具体看协议的帧间隔。还有一个容易忽略的配置串口调试助手的打开串口操作会独占该COM口。如果你先用sscom打开了COM11再用xcom去打开COM11xcom会提示打开失败。这时候需要先关闭sscom的串口连接。虚拟串口和物理串口在这方面的行为是一致的都是独占访问。5. 常见问题排查与避坑指南5.1 虚拟串口创建失败或不可见这是最常见的问题表现是VSPD界面里显示创建成功但设备管理器里看不到对应的COM口或者串口调试助手的端口列表里没有出现新建的虚拟串口。排查思路按优先级来第一检查驱动状态。打开设备管理器展开端口(COM和LPT)看看有没有带黄色感叹号的设备。如果有说明驱动没有正确加载。右键选择更新驱动程序手动指向VSPD安装目录下的驱动文件夹。第二检查系统重启。安装VSPD后如果没有重启驱动可能没有完成初始化。重启一次再试。第三检查端口号冲突。如果你选的COM口号已经被系统保留或占用虚拟串口创建会静默失败。换一个高编号的端口比如COM20以上再试。还有一种情况是Windows 11的驱动签名强制导致的。Windows 11对未签名驱动的拦截比Windows 10更严格。如果安装过程中驱动签名验证失败需要临时禁用驱动签名强制安装完VSPD后再重新启用。具体操作是按住Shift键点击重启进入高级启动选项选择禁用驱动程序强制签名然后正常启动系统安装VSPD。5.2 数据收发异常丢包、乱码、阻塞虚拟串口能创建但数据收发不正常这个问题比创建失败更让人头疼因为现象多样原因也各不相同。丢包的典型表现是发送端发了100个字节接收端只收到80个。虚拟串口的缓冲区大小是有限的如果发送速度远大于接收端的读取速度缓冲区满了之后新数据就会覆盖旧数据。解决办法是降低发送速率或者在接收端提高读取频率。串口调试助手的接收保存到文件功能会降低接收效率如果开了这个功能更容易出现丢包。乱码通常和波特率、数据位、停止位、校验位的设置有关。虚拟串口虽然不涉及物理时钟但VSPD会模拟波特率匹配的逻辑。如果一端设了115200另一端设了9600数据就会乱。另外如果发送的是中文或特殊字符要注意字符编码。串口调试助手默认可能是GBK编码而你的程序发送的是UTF-8接收端显示就会乱码。统一用十六进制模式收发可以避免编码问题。阻塞的表现是发送端调用写串口的函数后一直不返回或者接收端读不到数据。这通常和流控设置有关。如果一端开了硬件流控RTS/CTS而另一端没有对应的流控信号数据流会被阻塞。虚拟串口默认不支持硬件流控信号所以两端都应该设置为无流控。检查串口调试助手和你的程序里的流控设置确保都是None。5.3 程序无法打开虚拟串口你的程序在打开虚拟串口时返回错误提示拒绝访问或端口不存在。这种情况有几个可能的原因。端口被占用是最常见的。检查是否有其他程序已经打开了这个COM口。串口调试助手、Putty、甚至一些后台服务都可能占用串口。用任务管理器看看有没有可疑的进程或者直接重启系统再试。端口号超出程序支持范围。有些老旧的串口程序只支持COM1到COM9对于COM10及以上的端口号需要用\\.\COM10这样的格式来打开。这是Windows API的历史遗留问题COM1到COM9可以直接用COM1这样的名称打开但COM10以上必须用\\.\COM10的格式。如果你用的是自己写的程序检查一下打开串口的代码是否处理了这种情况。权限问题。在某些系统上普通用户可能没有权限打开串口设备。尝试以管理员身份运行你的程序。如果管理员权限下能打开说明是权限配置的问题需要调整用户组策略或串口设备的访问权限。5.4 系统重启后虚拟串口消失或错乱VSPD创建的虚拟串口默认是持久化的重启后应该还在。但有时候会出现虚拟串口消失或者端口号发生变化的情况。消失的原因通常是驱动加载失败。检查VSPD的服务是否正常启动。在Windows服务管理器里找到Virtual Serial Port Driver服务看看状态是否是正在运行。如果服务没有启动虚拟串口就不会被创建。可以手动启动服务或者设置服务为自动启动。端口号错乱的情况比较少见但确实发生过。比如你创建了COM10和COM11重启后变成了COM12和COM13。这通常是因为系统在启动时重新枚举了所有串口设备物理串口和虚拟串口的枚举顺序发生了变化。解决办法是尽量使用高编号的端口COM20以上减少和物理串口枚举冲突的概率。另外在VSPD里创建虚拟串口时可以勾选Lock port names选项如果有的话锁定端口号不变。5.5 常见问题速查表问题现象可能原因排查步骤解决方案虚拟串口创建后不可见驱动未加载检查设备管理器有无黄色感叹号重启系统手动更新驱动数据收发丢包缓冲区溢出降低发送速率检查接收频率增大缓冲区提高读取频率接收数据乱码波特率或编码不一致核对两端串口参数统一波特率和字符编码程序打开串口失败端口被占用或格式错误检查占用进程确认端口号格式关闭占用程序使用\\.\COMx格式重启后虚拟串口消失服务未启动检查VSPD服务状态设置服务自动启动删除虚拟串口失败端口被程序占用关闭所有串口程序重启后重新删除6. 进阶用法虚拟串口在自动化测试中的角色6.1 配合脚本实现串口自动化测试虚拟串口最大的价值之一是让串口通信的自动化测试成为可能。在CI流水线里你不可能挂一堆真实的串口设备但虚拟串口可以随用随建。思路是这样的用Python的pyserial库打开虚拟串口的一端另一端用另一个Python脚本或串口调试助手来模拟设备响应。测试脚本发送请求帧读取响应帧然后断言响应内容是否符合预期。整个过程不需要任何硬件。具体实现上VSPD提供了命令行工具可以在脚本里调用命令行来创建和删除虚拟串口对。比如在测试开始前执行创建命令测试结束后执行删除命令。这样每次CI运行时环境都是干净的。Python端的代码大概长这样import serial import time # 打开虚拟串口的一端 ser serial.Serial(COM10, 115200, timeout1) # 发送Modbus请求帧 request bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x0A, 0xC5, 0xCD]) ser.write(request) # 读取响应 time.sleep(0.1) response ser.read(25) # 预期响应长度 # 断言响应内容 assert response[0] 0x01 # 从站地址 assert response[1] 0x03 # 功能码 assert response[2] 0x14 # 字节数 ser.close()另一端可以用一个简单的Python脚本模拟从站监听COM11收到请求后回复预设的响应帧。这样整个测试链路就闭环了。6.2 与嵌入式Linux开发的配合虽然VSPD是Windows软件但它在嵌入式Linux开发中也有用武之地。很多嵌入式Linux开发者的工作流是在Windows上写代码、编译然后通过串口把固件烧录到开发板或者通过串口查看开发板的启动日志。在开发早期开发板可能还没到手或者硬件有问题暂时无法启动。这时候可以用VSPD在Windows上创建一对虚拟串口一端给Windows上的串口终端软件比如Putty或SecureCRT另一端给一个模拟开发板启动日志的脚本。这样你可以提前调试你的串口终端配置、日志解析脚本等开发板到了直接切换过去就行。另外如果你在Windows上用WSLWindows Subsystem for Linux做嵌入式Linux开发WSL可以访问Windows的COM口。在WSL里用/dev/ttyS加上对应的编号来访问虚拟串口。不过WSL对串口的支持有一些限制需要先在Windows端把虚拟串口创建好然后在WSL里用stty命令配置串口参数。我实测下来WSL2对虚拟串口的兼容性比WSL1好一些但偶尔还是会有数据延迟的问题调试时要注意。6.3 虚拟串口与MQTT网关模拟现在很多嵌入式项目需要把串口数据转发到MQTT服务器。比如一个STM32采集传感器数据通过串口发给一个4G模组模组再把数据以MQTT协议发到云端。在开发阶段4G模组和云端可能都不具备这时候可以用虚拟串口来模拟整个链路。具体做法STM32程序绑定COM10一个Python脚本绑定COM11。Python脚本收到STM32发来的串口数据后把数据打包成MQTT消息发到本地的MQTT Broker比如Mosquitto。另一个Python脚本订阅MQTT主题收到消息后打印出来。这样整条数据链路——从STM32串口输出到MQTT消息接收——就全部在本地模拟完成了。这个方案的好处是你可以单独测试每一段逻辑。比如只测试STM32的串口输出格式或者只测试MQTT消息的组装和解析。等真实硬件和云端就绪后只需要把Python脚本替换成真实的4G模组和云端服务其他部分不用改动。7. 一些踩过坑之后才明白的经验VSPD这个工具本身不复杂但实际用起来细节上的坑不少。我把自己和团队里其他人踩过的坑整理了几条都是文档里不会写的。第一条虚拟串口的波特率设置是假的但必须一致。虚拟串口不涉及实际的时钟分频理论上波特率设成多少都不影响数据传输。但VSPD在驱动层面会检查两端的波特率设置如果不一致数据可能被丢弃。所以不管是用串口调试助手还是自己写程序两端的波特率、数据位、停止位、校验位都要设成一样的。我一般统一用115200-8-N-1这是最通用的配置。第二条不要依赖虚拟串口的流控信号。VSPD的虚拟串口对不支持硬件流控RTS/CTS和软件流控XON/XOFF。如果你在程序里开了流控虚拟串口的行为可能和真实串口不一致。调试阶段建议关闭所有流控等切换到真实硬件时再根据实际需要开启。第三条虚拟串口的数量不是越多越好。每创建一对虚拟串口系统里就多出两个COM口设备。Windows对COM口的总数是有上限的虽然理论上可以到256个但实际使用中超过20个COM口之后设备管理器的刷新和串口程序的端口枚举都会变慢。我建议按需创建项目结束后及时清理。第四条串口调试助手的自动断帧功能要慎用。这个功能的本意是好的根据帧间隔自动把数据流切分成一帧一帧显示。但如果你的协议帧间隔很短或者数据量很大自动断帧可能会把一帧完整的数据拆成好几段显示看起来像是通信出了问题。调试变长协议时我一般关掉自动断帧直接看原始数据流。第五条虚拟串口不能完全替代真实串口调试。虚拟串口验证的是协议逻辑和程序流程但真实串口还有电气特性、信号质量、电磁干扰等问题。虚拟串口调通了不代表真实硬件上就没问题。我的习惯是虚拟串口上先把协议逻辑跑通然后尽早切换到真实硬件上做联调把电气层面的问题暴露出来。第六条VSPD的配置信息存在注册表里重装系统前记得备份。如果你创建了很多对虚拟串口并且配置了固定的端口号重装系统后这些配置会丢失。VSPD没有提供配置导出功能但配置信息在注册表的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vspd路径下。重装前导出这个注册表项重装后导入可以恢复虚拟串口的配置。不过驱动文件还是需要重新安装。最后分享一个提高调试效率的小习惯我会为常用的调试场景创建一套标准的虚拟串口配置比如COM10-COM11用于Modbus调试COM12-COM13用于AT指令调试COM14-COM15用于日志输出。每次开始新项目时直接按这套配置创建虚拟串口不用每次都重新想端口号怎么分配。串口调试助手里也把常用的波特率、数据位等参数保存成默认配置打开就能用。这些准备工作花不了几分钟但能省下大量重复配置的时间。
返回列表