Performance, DTR, CH340 driver, and more

[arkypita]

Hi Jason
I am Diego, developer of LaserGRBL project, a software in .NET Framework 4.0 that is used to control small laser engraver for hobbyist market. Basically, it is a software that stream gcode commands through the serial port.

Recently, I've been struggling with a problem that arose as a result of updates to the CH340 converter driver released and distributed by Microsoft, which made my program unusable with a large number of laser markers that use this chip. LaserGRBL simply won't connect, and the COM port closes as soon as the connection is attempted.

It seems that not all programs are affected by this problem, in fact if I try to connect with PUTTY or other terminals, the connection is successful. It seems like something related to the management of the DTR signal, but I tried every way and with the SerialPort of the .NET framework there was no way to get around this problem.

So I had the idea of ​​replacing the System.IO.Ports.SerialPort component with a different component, to see if I could connect, and BANG! with your library I can connect it.

Everything works but, unfortunately, the performance I can measure is poorer than what I got with the serial port of the standard framework (yes, I have read and am aware of the fact that the library has threads and manages a stream inside it, and therefore it is normal to expect this effect).

So my questions are:

1. What do you know about this issue with CH340 chips? Do you know any details you can explain to me or is this new to you?

2. It is possible/easy to remove the stream/thread functionality of your SerialPortStream and use it as if it were the .NET Framework SerialPort, so to have the expected performance? (i have my own thread, so I don't need additional thread and context switching).

3. Do you have any suggestions on how to address the problem?

4. Is it ok to you if I will use your library in LaserGRBL project?

Best regards, Diego

[arkypita]

PS: I am using https://github.com/jcurl/RJCP.DLL.SerialPortStream/tree/v2.x branch

[jcurl]

Hello. The RJCP.SerialPortStream uses a thread for buffering and is a fundamental part of the design. It is not planned to change this at anytime. This is to abstract strange behaviours, limitations not documented but imposed by drivers and their buffering techniques.

It f you can observe by profiling opportunities for improvement, these could be considered for upstreaming.

I am not aware of any changes or breakages in any specific driver.

By all means, usage of the driver within the license provided is allowed.