是下位机的程序处理问题，还是上位机的问题

1万 · 2018-12-7 12:56

我用官网的库例程编了个虚拟串口+HID，分别用F1、F3和F4的板子都实现了，但是发现一个问题，之前调试的时候也有注意到，但没在意：
1.连接后，成功驱动，PC端串口助手打开对应的串口号，和设备通讯无误。但是如果一旦设备出问题，比如进入了死循环，如果此时PC端的串口助手点击关闭串口，串口助手就会卡死，必须重启下位机或者拔掉USB。
2.串口助手打开对应的串口号，拔掉USB，然后再连上，无法和硬件串口一样能继续正常通信，中途串口助手不点击关闭串口。
3.串口助手关闭串口后，必须有一次释放串口的过程，比如重启下位机，插拔USB，这样串口助手才能再次打开原来的串口，这也和硬件串口不同

对于以上3点疑问，我想请教，是下位机的程序处理问题，还是上位机的问题？

1万 · 2018-12-7 13:00

上位机的驱动问题

1万 · 2018-12-7 13:04

上位机的串口助手问题

1万 · 2018-12-7 13:07

下位机的程序是用的官网的库，驱动是在原有驱动文件里面加了一个MI_00（复合IAD设备），串口助手试了好几个，也自己用QT编了一个，都一样

1万 · 2018-12-7 13:10

CDC好像会出现你说的问题，我同事调的时候发现这种情况，怎么解决有待研究

1万 · 2018-12-7 13:15

LZ描述的三个现象，对于单一的虚拟串口（不是LZ所用的复合设备）仍存在么？设备（MCU端）进入死循环，但是对上位机的通信响应，ST的例程都是基于中断来驱动的。

1万 · 2018-12-7 13:19

除非这个死循环是在某个比USB中断优先级更高的中断里

2万 · 2018-12-7 13:22

嗯，否则设备端应该依然可以响应USB通信。

2万 · 2018-12-7 13:26

上位机串口程序卡死。。。没有做过PC端程序和驱动的开发，不太清楚原因。但是如果使用官网上的虚拟串口例程搭配某个串口上位机能够重现这个现象，则可以用USB分析仪抓抓此时此刻USB总线上发生了神马，从而来确定是PC端，还是MCU端的问题。

1万 · 2018-12-7 13:32

这个我之前写的时候也有遇到，后面也想到好的解决方案，所以没用ＶＣＰ了

1万 · 2018-12-7 13:35

2这个问题也可以功过USB分析仪来查看。比如开启串口程序后，连上USB线缆后，然后选择某端口点击打开的操作，拔下线缆，再连上。

2万 · 2018-12-7 13:38

串口助手会卡死？。。。像是pc端的问题哦，这个时候看看device manager里面还有木有st的虚拟串口设备了、。？~

1万 · 2018-12-7 13:42

单一的VCP针对问题2、3已测，情况和复合设备一样，也都是用的官网的东西

1万 · 2018-12-7 13:46

然后呢？你是怎么应对这个的呢

1万 · 2018-12-7 13:50

开启串口程序，打开串口后，拔掉USB，在连上，，串口程序此时找不到对应的串口。但是设备管理器里面是可以看到虚拟串口已经连上了，也能看到串口号。
必须在重新插拔usb才能找到串口号

1万 · 2018-12-7 13:52

怀疑是PC端问题，但具体是串口程序问题还是驱动问题不确定。

1万 · 2018-12-7 13:56

还有，cp2102实质上也是一个虚拟串口，但是它就不会出现我提到的问题，这又让我怀疑是不是下位机函数处理部分哪里考虑的不周全了。

1万 · 2018-12-7 14:00

什么意思？不是很明白你说的什么，能再解释一下这个现象吗

1万 · 2018-12-7 14:03

通过打开多个串口程序测试，发现当一个串口号被占用时，其他串口程序也是能找到改串口号的，只是被占用了，无法打开而已，而不是找不到。

1万 · 2018-12-7 14:10

由此是否可以推断，当串口程序打开虚拟串口号，拔掉虚拟串口后，就算此时关闭串口，实际上并没有释放掉虚拟串口，虽然windows硬件里面能找到该虚拟串口，单应用层找不到