I got my prototype RS-485 circuit working. Now, I've connected it to my PC through RS-232 as I want to make the PC as the master. However, when I connect to the circuit using Hyperterminal, the RTS line, connected to RE and DE, always goes high. The PC can send data to the circuit but not receive, since the RTS never goes low. Changing the handshaking from none to hardware didn't help.

I later made mods to the circuit, so that, on the PIC side, the pin that drives the SN75176's RE and DE high when transmitting data will also drive the SN75176's RE and DE on the PC side low to enable receiving. This in effect turns the line from two to three. It's wrong, but I'm just doing it to see how it'll really work if the RTS pin is working properly.

enter image description here

How do I go on making the RTS pin working correctly? I know I can just create an app using Visual Studio to connect to the line and have RTS toggled manually, but doing so is too troublesome and I'd rather have a hardware solution if possible.

  • \$\begingroup\$ People typically use a timer to hold the transmitter active for some time delay after the first transition. Subsequent time delays would reset the time, delaying de-activation. You want the deactivation time to be longer than the maximum interval between transitions in a transmission (probably most of a character time) but shorter than the interval before someone else would start transmitting. Cutting it that close of course makes it baud-rate dependent. \$\endgroup\$ Dec 20, 2011 at 17:08

3 Answers 3


This man RS485 to RS232 converter - seems to be doing what you are doing and achieving success.

It sounds like Hyperterminal should be capable of proper RTS control.

  • 1
    \$\begingroup\$ Actually, no - he's manually telling Hyperterminal to assert & deassert RTS, then gets into custom software. \$\endgroup\$ Dec 20, 2011 at 17:11
  • \$\begingroup\$ AFAIK there is no "proper RTS control" in the sense you want - the RS232 standard was written for a point-to-point line, not for a multidrop. RTS asks for the line to be available, think of a modem intitializing after power-up. There is no request on the host to relinguish the line at any time. \$\endgroup\$ Dec 20, 2011 at 19:20
  • \$\begingroup\$ @WoutervanOoijen - the RTS signal is almost always arbitrarily controllable from driver level software, and most operating systems allow doing so from their main serial API as well, though there is a catch that you have to ensure (at application level perhaps without access to low level verification, ie by using a timer with a safety margin) that the data has actually been transmitted and not just buffered. Even at driver level it can require work to ensure that the final byte has left the shift register, since normally loading it into the shift register is the last operation. \$\endgroup\$ Dec 20, 2011 at 20:03
  • \$\begingroup\$ I should mention that a 2-wire implementation makes software control of the line driver from high level code easier than with a 4-wire implementation, because with a 2-wire implementation you receive your own transmission and can use receiving the end of it as proof that the buffers have been flushed to the wire and it is safe to deactivate your line driver. \$\endgroup\$ Dec 22, 2011 at 15:35
  • \$\begingroup\$ @ChrisStratton: One problem with software-level control is that most PC com ports nowadays have really crummy timing characteristics and 115,200 there may be no way to guarantee that RTS gets released within nine character times of the last transmission. If the remote end has a good serial port, it may send its reply while the originating PC is still holding RTS. \$\endgroup\$
    – supercat
    Jan 19, 2012 at 20:15

FTDI USB to serial converters such as FT232R, FT2232R, FT2232H etc. when operated in a UART mode have a direction pin which goes high while the chip is transmitting. I've implemented a USB/RS-485 converter board using a FTDI IC, and it works without problems. Now that's not what you probably want to hear but it's probably the easiest, most reliable method. As far as RS-232 to RS-485 is concerned, I remember reading about using a monostable to provide the direction signal for the RS-485 driver IC.


On my Orange Pi Zero I ended up controlling the RTS via GPIO... I use python, so defintely not very accurate, but, for a 19200 UART - RS485 connection to my ABB inverter it's accurate enough.


ser = serial.Serial('/dev/ttyS1', 19200)
gpio.output(led, 1)
data ="\001\002\003\004"
print len(data)


enter image description here


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.