[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DU0PR02MB7899EC8515D8FF35B4D01465C4292@DU0PR02MB7899.eurprd02.prod.outlook.com>
Date: Thu, 14 Mar 2024 22:13:03 +0000
From: Cameron Williams <cang1@...e.co.uk>
To: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: CH341 RTS/CTS flow control disabled in driver?
Hi all.
I am wondering if anyone knows anything regarding the RTS/CTS lines on the CH341 (maybe CH340 though I have no chip example).
I have two CH341-based devices, both a generic 3V3 uart and also an all-in-one type device with SPI/I2C.
>From my tests, neither of them seem to have RTS/CTS respected, and I don't believe they are fake?
My test procedure is as follows:
1) Have nothing connected except TxD/RxD via a jumper.
2) Open `statserial` to check the status of the lines. On all devices, RTS is set to 1 and CTS is set to 0.
3) Open PuTTY, ttyUSB0, 9600 baud, RTS/CTS flow control. Data should not flow as CTS is not high. Close PuTTY.
4) Open PuTTY again, same settings, but with no flow control. Characters buffered from step 3 should now appear thanks to the loopback in step 1.
Alternatively, for step 3 and 4, set Picocom to use RTS/CTS, send some data, then disable flow control, and the buffered data will now flow.
Using an (albeit fake) FTDI device, and PL2303 based device, they both work as expected.
A CP2102 doesn't like to exit with stuff already in the buffer (just hangs PuTTY), but thats a separate issue, and at least it is respecting CTS/RTS.
However with both CH341 devices I have, on step 3, the data flows regardless. Checking in statserial, CTS is indeed still set to 0.
Is this intended behaviour? Looking through the source I can see RTS/DTR should be supported, but it just doesn't seem to work.
If anyone wants to look at it I'm happy to help debug.
Powered by blists - more mailing lists