-
Notifications
You must be signed in to change notification settings - Fork 202
Driver Compatibility with SerialPortStream
This section is intended to capture some of the quirks and behaviours of serial drivers. The SerialPortStream implementation is very reliant on how the Operating System behaves and how individual drivers behave.
When designing your software to talk over the serial port, do not rely on the correctness of error checking (e.g. Parity). Instead, use packet based protocols with your own CRC checks (or use existing protocols for your design, such as HDLC).
I recommend always using the most recent version of the driver. Some USB serial port adapters come with outdated drivers that often cause Blue Screen crashes.
Data corruption can occur when using synchronous settings with the PL2303 drivers (observed with the first implementation in 2010). The code block below should block until data arrives and if data is already in the buffer, it should return immediately. However, using loop back devices showed the data to be corrupted (it appeared interleaved) indicating an issue in the driver.
// Non-asynchronous behaviour timeouts.ReadIntervalTimeout = -1; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0;
The solution is to use read interval time outs. This block hasn't been tested with the newer PL2303RA chip sets that have working drivers for Windows 8 and later, as the workaround to have different settings is also compatible with all current drivers.
timeouts.ReadIntervalTimeout = 10; timeouts.ReadTotalTimeoutConstant = 100; timeouts.ReadTotalTimeoutMultiplier = 0;
The FTDI chipset is by far one of the most reliable and best working chip sets and drivers that I've encountered.
You must make sure to set the Binary flag in the DCB to true. MSDN says that the fBinary flag should be set to TRUE as no other mode is supported. Setting this to false (or typically not setting it at all) will result in small delays in receiving data when a 0x0A byte is received. Setting to Binary mode avoids this delay.
For Windows, com0com is the software driver that is used often to test SerialPortStream from Windows XP to Windows 10 (1607). The Windows SerialPort class will only work with COMx interfaces, not names such as CNCA0. This implementation will work with CNCA0, etc.
This driver is based on bytes, not individual bits, so some of the test cases will fail with this driver as we send 8-bit data to be received using a configuration of 7-bit data with parity. Naturally this will work with real serial ports as the data is indistinguishable.
You should also refer to the document dll/serialunix/README.linux for more information. Some of it is repeated here.
This appears to be the only driver that I've tested that works flawlessly, including receiving invalid data, and properly handling parity errors on receive.
On receiving data that has parity errors, the PL2303H and PL2303RA all receive invalid data, not just for the byte that has the parity error, but a block of bytes.
The test cases are
libnserial/comptest SerialParityTest.Parity7O1ReceiveError SerialParityTest.Parity7E1ReceiveError
For example, for the case that the byte 0x45 has received the wrong parity, the following results might be expected:
In this case, bytes 0x3A to 0x45 were considered incorrect, even though only bytes 0x45 was the only incorrectly sent byte.
0000030: 3031 3233 3435 3637 3839 ff00 3aff 003b 0123456789..:..; 0000040: ff00 3cff 003d ff00 3eff 003f ff00 40ff ..<..=..>..?..@. 0000050: 0041 ff00 42ff 0043 ff00 44ff 0045 4647 .A..B..C..D..EFG
And in this case 0x44 was considered incorrect.
0000030: 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f 0123456789:;<=>? 0000040: 4041 4243 ff00 4445 4647 4849 4a4b 4c4d @ABC..DEFGHIJKLM 0000050: 4e4f 5051 5253 5455 5657 5859 5a5b 5c5d NOPQRSTUVWXYZ[\]
The same issues as observed above for #Parity for PL2303H, RA are observed here also.