Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
You must take care with RTS signal, it's used to indicate to RS485 what is the way of communication (for example if you are transmiting or receiving). The problem is that in windows, cause it takes control of your system, when you transmit a data to your system, you put the RTS on, then when you finish transmiting you put the RTS off, but in windows it's not OK, it's not synchronize exactly when data is transfered (you cannot know when data is really transfered to RS485), it delays up to 10 msecs, so, the other system must wait almost 10msecs before it responses to windows packet... It delays all your transmition.
Yeah, but the same thing is valid at the MCU side...
Unless you were connecting ONLY two devices in a four-wire configuration, each MCU must control its RS485 driver, according to an algorithm, strategy or whatever for avoiding data collision.
As mentioned earlier, you must turn off the RS-485 transmitter driver when each transmission is complete so that you can receive on the same RS-485 wire pair. This is called "turnaround."
It was also mentioned that you must delay turnaround for some amount of time (10 milliseconds has been cited) after transmitting. THIS IS NOT STRICTLY TRUE:
* Some uarts can generate an interrupt upon completion of character transmission. When this interrupt occurs, you can disable the transmit driver immediately if there are no more chars queued for transmission.
* If the uart does not have the ability to interrupt upon char completion, you can use an external hardware timer to time the char transmission and generate an interrupt upon transmit completion.
In both of the above cases, the remote node can begin transmitting a very short time after receiving the final char of your message. Typical times are on the order of 100 microseconds, or whatever is the worst-case interrupt response time of the message origination node.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
