Hack to workaround misbehaving CH340 drivers on Windows

[cmaglie]

It seems that the CH340 driver does not correctly support the SetCommTimeouts system call.
In particular calling SetCommTimeouts with the following settings

Windows.CommTimeouts{
	ReadIntervalTimeout:         0xFFFFFFFF,
	ReadTotalTimeoutMultiplier:  0xFFFFFFFF,
	ReadTotalTimeoutConstant:    0xFFFFFFFE,
}

should set timeout to infinity and block the Read call until at least one byte is received. In reality, the CH340 behaves like there is no timeout, returning the available data immediately (or an empty read if there is no data). This violates the SetCommTimeout definition, while all the other drivers correctly honor the timeout.

If an application sets ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD, one of the following occurs when the ReadFile function is called:

• If there are any bytes in the input buffer, ReadFile returns immediately with the bytes in the buffer.
• If there are no bytes in the input buffer, ReadFile waits until a byte arrives and then returns immediately.
• If no bytes arrive within the time specified by ReadTotalTimeoutConstant, ReadFile times out.

Notably, the wrong behavior is present only with the "block until the first byte is received" timeout mode. Using the "block until the buffer is full" timeout mode

Windows.CommTimeouts{
	ReadIntervalTimeout:         0,
	ReadTotalTimeoutMultiplier:  0,
	ReadTotalTimeoutConstant:    0,
}

works as expected and the Read call lasts until the buffer given to the Read call is filled. BTW this kind of timeout is not useful for us because it will force us to do an inefficient read of one byte at a time if the amount of data received is not known in advance.

Another interesting discovery is that after setting a finite timeout (like for example 10 seconds):

Windows.CommTimeouts{
	ReadIntervalTimeout:         0xFFFFFFFF,
	ReadTotalTimeoutMultiplier:  0xFFFFFFFF,
	ReadTotalTimeoutConstant:    10000,
}

the CH340 behaves correctly and waits 10 seconds for the first byte to come in.
This made me think that maybe it's the highest value 0xFFFFFFFE that is not correctly interpreted by the driver, so I started searching the maximum-working-value, and after bisecting for a bit, I've found the "magic" number that finally makes the driver behave again: 0x7FFFFFFE. This makes me think that the bug in the driver is due to a signed-vs-unsigned comparison.

In any case, reducing the "infinity" value from 0xFFFFFFFE to 0x7FFFFFFE does solve the problem, and it keeps the library compatible with the other serial converters. Actually, it does halve the "infinity" timeout from circa 50 days (FFFFFFFE milliseconds) to 25 days (7FFFFFFE milliseconds), BTW I've added another patch that will transparently repeat the Read if this very long timeout should ever happen.