CH340的驱动CPU占用率比竞品高很多

只看该作者 · 2021-7-8 08:39

本帖最后由 charleydeng 于 2021-7-8 08:52 编辑

WCH@TECH39 发表于 2021-7-2 21:26
您好，根据如上测试，我们做了相关对比验证，详细测试过程见链接中视频。结论是：CH340驱动的CPU占用率没有 ...

一、串口属于低速通信设备，CH340一般也主要是用于电脑主机等USB-UART Dongle这类场合，以“确保实时性”（却显著牺牲了CPU的占用率）作为理由解释，似乎有些牵强。
对于低速串口通信，“收到数据后”按照1ms超时还是16ms超时，能对实时性会产生显著区别性的影响？许多人使用FT232并未认为性能差。所以，采用1ms而非16ms的预制参数，本身也存在合理性探讨。

二、 WCH内部可再做一个测试，在CH340的驱动里将这个‘延迟计时器’参数临时从1ms改成16ms，查看一下CH340实际的CPU占用率是否会显著降低，达到和FT232等一样的效果？这样可能可以更”直接“定位CH340的驱动导致CPU占用率异常的根源，是否和这个参数有关。

三、这里提到 ” 包含‘延迟计时器’参数，接收到USB数据后不会立刻传递给串口“，说的是主机通过驱动经由CH340向外”发送“数据。更合理的查询场合，应该时反过来的主机接收阶段吧？也就是” CH340的串口收到数据后，驱动是否立刻去查询是否收到了数据并传给USB再串口调试助手软件“？请问驱动对这种查询判断是否一直存在？即使实际并未有数据接收？如果答案是否，那么对CPU的占用率，应该主要表现在单向，即主要是做接收时。WCH也可以测试看看，对CPU的占用率，是否存在明显的单向性特征。

请进一步澄清或协助，谢谢！

只看该作者 · 2021-7-8 10:07

本帖最后由 LiuShuai1981 于 2021-10-3 18:16 编辑

charleydeng 发表于 2021-7-8 08:39
一、串口属于低速通信设备，CH340一般也主要是用于电脑主机等USB-UART Dongle这类场合，以“确保实时性” ...

USB转串口的数据接收流程：

a.串口数据-> b.CH340芯片RX接收->c.CH340 USB上传端点上传->d.驱动程序接收到USB缓存队列->e.驱动程序将数据转移至面向应用端的缓冲区->f.应用层接收。

cpu占用率差别与串口软件数据的刷新显示的频率有关。需不需要延时与产品的应用定位有关。

CH340和CP2102侧重于工业应用实时性和原生串口的兼容性，有数据就尽快通知应用层，而FT默认是积聚一段时间的数据再通知应用层，这只是FT产品定位与CH/CP不同，FT应改成1ms设置再进行比较测试，其16ms默认设置未必适合对超时有要求的实时应用，这可能也是FT用量不如其他几家的原因之一。

举例说，如调试类工具软件需要显示，而协议软件不需要显示，更注重实时性。

不知道这样解释，您觉得是否到位。期待与您电话实时沟通。我电话是18951773205，也可以留下您的电话我联系您。

只看该作者 · 2021-7-8 11:35

LiuShuai1981 发表于 2021-7-8 10:07
USB转串口的数据流程：
a.串口数据-> b.CH340芯片RX接收->c.CH340 USB上传端点上传->d.驱动程序接收到USB ...

您的解释到位，但是一些细节还是值得验证。所以，私信您了，麻烦您做个临时定制的驱动，我们来对照测试，并把实验结果反馈给您。

毕竟在这里，单位时间内转送显示的数据总量一定，而且有串口速度本身相对较慢且基本恒定这个前提，更快的频率转送刷新更短的数据段，理论上可能会增加一些CPU占用率，但是总认为不至于造成这么大好几倍的提升。这里也不是因为波特率和数据总吐吞速度的数倍提升，而带来的CPU占用率的提升。

另外，在我们自己写的串口程序里进行了一项测试：只做串口数据接收，不发送到编辑框里显示刷新，发现CPU占用率基本上没有多少改善，占用率依然比较高。推测大概还是因为串口吞吐速度本身较慢，这类刷新的影响不是很显著，不比高速海量数据吞吐的场合。

只看该作者 · 2021-7-8 12:52

本帖最后由 LiuShuai1981 于 2021-10-3 18:21 编辑

麻烦你电话或加我微信：18951773205，我这帐号发不了信息。

只看该作者 · 2021-7-8 12:53

本帖最后由 LiuShuai1981 于 2021-10-3 18:20 编辑

楼上提到没多少改善，应该是你的应用程序中某个地方没有及时释放空闲时间给系统的原因。

如调用系统函数ClearCommError() 循环去查询串口接收缓冲区有无数据，有数据再调ReadFile读取数据，此时建议在循环中增加Sleep，因为ClearCommError()会立即返回串口缓冲区内数据长度，如循环中不增加如Sleep函数让出CPU，则会增加CPU占用率。采用同步方式加超时也是可以，串口操作方式有很好种，MSDN内有相应的串口函数说明和范例可参考。

只看该作者 · 2021-7-8 13:48

在人们的固有印象中，串口是个低速接口，常用的115200bps波特率，实际也就是11kB/s的速度，如果这么点速度占用10%以上的CPU，怎么都是说不过去的。

只看该作者 · 2021-7-8 16:58

本帖最后由 LiuShuai1981 于 2021-10-3 17:52 编辑

imdx 发表于 2021-7-8 13:48
在人们的固有印象中，串口是个低速接口，常用的115200bps波特率，实际也就是11kB/s的速度，如果这么点速度 ...

不可能驱动会占用10%的，占用率很小，参考前面实测，CH无显示占用3%,其他CPU占用率应该是显示刷新导致。如FT按CH和CP的实时设置，将延时时间设为1MS并加显示，CPU可达24%.
如果你遇到高占用率，可电话我18951773205，我们帮你找问题，估计是应用程序中没有及时释放空闲时间给系统的原因。

只看该作者 · 2021-7-8 17:32

LiuShuai1981 发表于 2021-7-8 16:58
不可能驱动会占用10%的，占用率很小，前面有实测结果。
如果你遇到高占用率，可电话我18951773205，我们 ...

看正文**吧，测试结果都写了。
使用你们的COMTransmit，CH340N，115200自发自收，CPU占用率在10%-12%之间跳动。
sscom4.2能稍微低一点，6~10%之间跳动，最高也会超过10%。

只看该作者 · 2021-7-9 09:39

本帖最后由 LiuShuai1981 于 2021-10-3 16:28 编辑

关闭显示后CPU占用率都是３％，已说明不是驱动程序引起，而是显示刷新的原因。

FT如果要达到CH和CP的实时性，可将驱动设置为1MS，我们实测会到24%。不知道我这样解释你能否到位，我非常乐意和你更深入地探究此技术问题，同时也希望驱动能满足客户的各种需求。
如果你需要数据延后上报或上报频率可调，你联系我 18951773205 或发邮件至TECH@WCH.CN.

只看该作者 · 2021-7-9 11:54

最好不要默认开等待，有些软件协议不允许数据延时，比如工业上常用的MODBUS，115200波特率下，2ms就断帧了。修改运行条件，会导致设备无法工作，终端用户只在乎设备是否正常运行，大多连串口怎么配置都不会操作，修改这种参数无疑会给用户造成极大困扰。

最好的做法是根据需求选择产品，而不是让一个产品兼容所有功能。

只看该作者 · 2021-7-9 12:25

本帖最后由 charleydeng 于 2021-7-9 12:32 编辑

LiuShuai1981 发表于 2021-7-8 12:53
在我们自己写的串口程序里进行了一项测试：只做串口数据接收，不发送到编辑框里显示刷新，发现CPU占用率基 ...

我们串口接收的流程是，一个带while循环的接收监控线程，在while循环里使用了WaitCommEvent()等待触发机制，然后是通过ClearCommError()先查询串口缓冲区内到达的字节数，获取读长度，接着就是调用ReadFile函数读取长度的数据。读取到数据后，通过一个消息发送出去，供上层界面显示和处理。

1、麻烦先看看，这里是否可能存在导致CPU占用率提高的因素？或者，本质上，和您所说的加入sleep的测试建议，其实已经一致了？

如果有必要，我们也可以改成，去掉WaitCommEvent()，改成纯循环查询，然后如您所提到的，在读循环中，加入10ms延时对照看看。您确认一下，我们的对您建议的理解是否正确。

此外，我们前面所说的，“临时关闭接收的刷新显示的实验”，就是在代码里，调用ReadFile函数读取函数后，直接扔掉，不转给界面显示层来刷新显示和处理。但是这样进行对照测试，没有发现对CPU占用率有明显改善。

2、WaitCommEvent()配套有个setCommTimeouts()来设置COMMTIMEOUTS参数，这个参数也是可以设置“等待时间”

COMMTIMEOUTS参数中，也有ReadIntervalTimeout、ReadTotalTimeoutMultiplier、ReadTotalTimeoutConstant等参数机制。请问，这几个参数的含义，是否和前面提到的 “延时计数器”相关或意义一致？驱动里是否实现了关联？或者是否应该在驱动层支持两者关联？

我们也尝试修改这里的参数，表现出来的接收现象（就是对根据帧间时间延时判断退出返回）会有影响，也就是该参数起作用了（不清楚是在驱动层，还是MFC的API层起的作用），但是没有发现对CPU的占用率有显著影响。

3、此外，ReadFile()可以指定这次读取返回的数据长度，也是可以调节的，并不一定要是ClearCommError()得到的当前缓冲区的长度，也可以设定为一个较大的上限长度

(然后，配合ReadIntervalTimeout参数的设置，实现一次串口“自定义协议包”尽量完整的接收，有助于避免数据消息被胡乱分段，有助于减少上层处理的复杂性，这一点和本主题无关了，不展开)

ReadFile()不按照当前缓冲区的实际长度而选择一个较大的长度，辅以ReadIntervalTimeout参数的配合，可以带来一个效果，就是这个ReadIntervalTimeout函数会暂时阻塞于此，直到收到了足够长度的字节，或者ReadIntervalTimeout计时超时。不知道这种机制，理论上是否会导致CPU的占用率升高（ReadFile阻塞时具体会做什么），但是我们对照测试过，在调用ReadFile时，无论指定的长度是ClearCommError()所得到的当前缓冲区的实际长度（因此ReadFile不会等待阻塞），还是自己指定的一个更大的长度（因此因此ReadFile会出现等待阻塞），连续测试时，对于CPU的占用率，没有发现区别。

4、好的，谢谢你，我们加您的微信和给您发邮件，我们拿到定制驱动后，再线下对比测试看看。分析交流的太多可能性后，做一下测试，也有利于更好的定位和缩小范围。谢谢！

只看该作者 · 2021-7-9 17:29

本帖最后由 LiuShuai1981 于 2021-10-3 18:14 编辑

charleydeng 发表于 2021-7-9 12:25
我们串口接收的流程是，一个带while循环的接收监控线程，在while循环里使用了WaitCommEvent()等待触发机制 ...

那可能与你程序的写法有关。

CH340串口驱动兼容系统提供的所有的串口API，用法无区别，且驱动是通过微软数字签名的。包括实时性也是为了兼容原生串口(原计算机主板自带串口)的串口软件。
我没看到你加微信。麻烦加一下 18951773205，谢谢。
你能把串口那部分代码贴出来，我看一下。

只看该作者 · 2021-7-30 14:26

CH340       FIFO TX Buffer 32Bytes    FIFO RX Buffer 32Bytes
FT232RL    FIFO TX Buffer 128Bytes FIFO RX Buffer 256Bytes
HT42B534 FIFO TX Buffer 128Bytes FIFO RX Buffer 128Bytes
XR21       FIFO TX Buffer 128Bytes FIFO RX Buffer 384Bytes
CP2102    FIFO TX Buffer 640Bytes FIFO RX Buffer 576Bytes
PL2303    FIFO TX Buffer 256Bytes FIFO RX Buffer 256Bytes
PL2303    FIFO TX Buffer 128Bytes FIFO RX Buffer 384Bytes

只看该作者 · 2021-9-8 10:21

WCH@TECH39 发表于 2021-6-30 18:06
您好，您反馈的现象可能与串口应用软件开启了显示功能有关。您可以使用我司的串口软件，在是否显示接收2种 ...

蓝屏问题到底是：
1、实习生开发的驱动，主要写的BUG，还是，
2、串口调试助手BUG，还是，
3、系统自带BUG。
不过网上说FT232没有问题，但是CH34*就是会蓝屏，以前我还不信，稍微用了下就体验了蓝屏。
以下几点可能因素：
1、串口助手软件：Win10应用商店的串口调试助手、山外调试助手均发生蓝屏。
2、一直运行接收数据，时间一久自动蓝屏。
3、波特率高于115200，极容易蓝屏，我试过256000蓝屏跟买菜一样轻松。

Win10蓝屏提示，均是：CH341驱动导致的。，疑惑老觉得是实习生写的驱动。是不是驱动更新过，我用的旧的啊？

只看该作者 · 2021-9-26 15:09

本帖最后由 WCH@TECH39 于 2021-10-2 22:45 编辑

您说的现象原因可能为驱动程序不匹配，CH340十多年来更新过几次芯片固件和几次驱动程序，因为前几年有些盗版芯片，其芯片固件与我司驱动程序未必匹配。正常只要确认2点就不会有蓝屏：芯片来源正常、使用官网下载的驱动程序。

CH340的驱动CPU占用率比竞品高很多

技术高手奖章

常驻人口

涓涓之细流