I'm trying to implement a UART on a dsPIC33E microcontroller to communicate with an industrial controller (cRIO by National Instruments) over RS485 (2-wire, half-duplex).

What I want to know is should I implement a delay before the first start bit and the last stop bit of the whole message? If yes, is there any recommendation (standard) how "long" this delay should be?

Here is a waveform of a message recorded at a serial port of the industrial controller:

Waveform of a message sent over RS485

For easier referencing, let's say that the far left vertical line denotes t=0 ms, whereas time division is set to 1 ms. Since the serial port is configured in a half-duplex mode, data direction can be either transmit or receive. At t=1 ms it can be seen that the port is set to the transmit mode, and at t=7.2 ms it releases the data bus, i.e., it is set to the receive mode. However, I'm concerned about these delays before the first start bit and the last stop bit. Should I also implement these delays on my microcontroller? Is this defined by any standard - hardware or software standard?

Thank you in advance!

  • 2
    \$\begingroup\$ RS-485 is NOT a protocol, it simply carries signals in a differential format. That is why you can pipe RS-232/IC2/MODBUS over RS-485 connections. Some protocols like IC2 require a 7 clock period of silence before the same port can transmit again, mostly to give other ports a chance to briefly act as buss-master and send data. \$\endgroup\$
    – user105652
    Jul 27, 2016 at 18:07
  • 2
    \$\begingroup\$ I'm not aware of any sort of standard for this. Typically when I implement a RS485 bus I try to ensure that I release the bus as soon as I am sure that the last bit of my message has been shifted out of the UART and spent its allocated bit-time on the bus. This ensures that I avoid a conflict with another device on the bus which wants to talk next and was waiting for me to finish. \$\endgroup\$
    – brhans
    Jul 27, 2016 at 18:25
  • \$\begingroup\$ @brhans I also implemented RS485 in that way - as soon the last stop bit is transmitted (on dsPIC I can use an interrupt for this), I release the data bus. However, I'm not sure about the delay before the first start bit - should I use any? A datasheet says that I should use a software delay (single-bit time), after enabling UART transmitter. Should I delay like this every time I send a message? \$\endgroup\$ Jul 27, 2016 at 19:23
  • 1
    \$\begingroup\$ A problem with adding a delay before the first start-bit is that other devices cannot detect when you start driving the bus, they can only detect the edge of the start-bit. So if your communication is asynchronous, then you are opening a window where another device can start driving the bus at the same time. \$\endgroup\$
    – Mark
    Jul 27, 2016 at 19:45
  • \$\begingroup\$ @Mark I agree, by allowing delays before the first start bit, another device might also try to transmit at the same time, since the "delay-state" cannot be detected by a receiver. As for the delay after the last stop bit, it makes sense to release the data bus as soon as possible. Thank you all for useful comments! \$\endgroup\$ Jul 27, 2016 at 20:15

2 Answers 2


It is driver output enabled state, like DE pin set HIGH on MAX485. Check RS485 on a Scope.

Common sense dictates that device shall disable transmitter ASAP after last stop bit is sent (to release the bus): check "Auto Switching Link" paragraph on this Maxim tutorial. On the other hand, if line quality is low and this phase is short, the receiving transceiver might not detect start first data bit correctly (stated in the first link).

Besides this, communication protocols over RS-485, for example Modbus requires at least 3.5 character silence between frames (or inter frame gap). So to be on safe side, you might introduce delay of say 0.5-1 char bit (in case of Modbus) after enabling transmitter but before transmitting (and also after end of frame).

  • \$\begingroup\$ Yes, I've heard about the 3.5 character (3.5 bits) silence recommended by Modbus, but I'm not sure what does Modbus have to do with it since Modbus is just a software protocol, or I'm getting something wrong? As for the protocol (software) implementation, I connected the RS485 driver to the UART on my dsPIC, and I have two (program) buffers: one transmit and one receive buffer. E.g., after I receive a WHOLE message, I process this message under Modbus rules. Is this OK? As for the delays, I will not be using a delay after the last stop bit, nor before the first start bit. \$\endgroup\$ Jul 27, 2016 at 20:13
  • \$\begingroup\$ Regarding UART basically yes, but since RS-485 is half-duplex, you can do either listen (receive) or transmit (send) at a time. So usually you drive the RS-485 transceiver by 3rd control pin (DE which is also connected to negative RE) before receiving or transmitting by UART. Some transceivers do it automatically, in this case you don't need to drive like this. \$\endgroup\$
    – Flanker
    Jul 27, 2016 at 20:34
  • \$\begingroup\$ Regarding delay, point was if you want to insert them it is OK since Modbus (if it is in your case) requires some delays anyway, and during this delay slave will not send an answer anyway. \$\endgroup\$
    – Flanker
    Jul 27, 2016 at 20:37
  • \$\begingroup\$ I understand that Modbus requires some delays, but I don't understand why. As far as I know, Modbus is just a software protocol, i.e., a set of rules which messages have to follow. Why does it care how messages are actually transmitted/received? As for the transceiver, I have the one for which the direction is controlled by a GPIO. Anyway, I won't use these delays, and see if it works that way. Thanks! \$\endgroup\$ Jul 27, 2016 at 20:46
  • \$\begingroup\$ Rules must ensure message/frame integrity check, reliable transmission and identification, including start of frame, end of frame.. etc and silences are useful there (besides frame format). Regarding the direction, make sure that last byte is wholly transmitted by UART before switching the transceiver into listening. \$\endgroup\$
    – Flanker
    Jul 27, 2016 at 20:56

Having rs485 float can cause false start bits. When switching from transmit to receive it can help if you bias the lines to an idle state. Only do this at one point in the network. I read an application note about 20 years ago that did this.


Your Answer

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

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