On Tue, 2022-03-29 at 13:19 +0000, David Laight wrote: > From: Matthias Schiffer > > Sent: 29 March 2022 14:03 > > > > On Tue, 2022-03-29 at 12:55 +0000, David Laight wrote: > > > From: Matthias Schiffer > > > > Sent: 29 March 2022 11:39 > > > ... > > > > I guess that would work. The fact that even the different > > > > variants of the 8250 are implemented inconsistently makes this > > > > especially ugly... It certainly puts a damper on the efforts to > > > > make > > > > the handling of RS485 in serial drivers more generic. > > > > > > One thing to remember is that RS232 (IIRC really V.38) line > > > driver > > > chips are typically inverting. > > > > > > So the modem signals on a TTL level output will have the > > > opposite polarity to that required on the actual connector. > > > > > > Normally a UART will have an 'active high' register bit for > > > a modem signal that drives and 'active low' pin so you get > > > the correct polarity with an inverting line driver. > > > > > > David > > > > > > > Indeed. As far as I can tell, this property of UARTs is what got us > > into this mess: Some people interpreted SER_RS485_RTS_ON_SEND as > > "set > > the RTS flag in the MCR register on send", while other thought it > > should mean "set the RTS pin to high on send", leading to opposite > > behaviours in different UART drivers (and even different UART > > variants > > in the same driver, in the case of the 8250 family). > > Hmmm... A complete mess. > The 'RTS pin' that needs to go high is the one on the (typically) 'D' > connector after the inverting line driver. > Not the pin on the uart package. > I'd expect TTL level serial interfaces to require active low > modem signals. > > If RS485 is trying to do half duplex using RTS (request to send) > and CTS (clear to send) you've typically got bigger problems > than asserting RTS before a transmit. > The real problem is removing RTS once the last transmit data bit > (the stop bit) has left the UART pin. > I've used local loopback (tx to rx) to detect that in the past. > > Of course, if it is just doing flow control that should use RFS > (ready for sending) to indicate space in the receive fifo but > using the RTS pin instead that is a different matter. > > David > I'm aware of the difficulties of deasserting RTS after the transmission is complete, but that's completely orthogonal to the issue I'm trying to solve right now :) Regards, Matthias
