1
\$\begingroup\$

Is it possible to send/recieve on RS485 without flow control. I am working on stm32f4 platform with a MAX3160 multiprotocol transceiver(supports RS232 and RS485). The UART lines form STM32F4 are connected to the MAX3160. When the MAX3160 is configured to RS232 it works fine. But when configured to RS485(only 1 pin toggle on MAX3160, input/output lines are same) i am not able to send/receive data. The devices connected to RS485 are using modbus protocol. I am not using RTS/CTS and have configured NO_FLOWCONTROL on UART. My modbus devices also has just 2 wires A+ and B-.

Could the RS485 data enable or not configuring CTS/RTS causing this issue.

I am not very experienced in hardware. So any pointers will help.

EDIT: Yes. I am not too sure about the basics as this is the first time I am working on any hardware boards. I have a board with stm32f427. The USART1 lines are connected to a MAX3160 transreciever which supports both Rs232 and Rs 485, although not simultaneously. It can be configured with one pin. The input and output lines for both rs232 and Rs 485 are same. I connect the rx tx from these to the modbus device. I configure the uart with no flow control, 9600 baud rate, stopbit 1, no parity and enable Rs 232 pin on MAX3160. I use a rs232 to Rs 485 converter connector and connect the modbus device. It works fine. So i am sure the pi configuration is fine. Now I just enable pull the rs232/rs485 pin high to enable Rs 485. I remove the rs232 to Rs 485 converter and connect the modbus device directly. I am guessing it should work without any changes. But I hooked up a oasicalltor and I cannot detect anything. MAX3160 data sheet has some pin called DE485(data enable). Should this be set. Or some other change specific to Rs 485. Currently I have not set this data enable pin. If it needs to be set, when should it be set. My modbus device has only 2 wires A+ and B- which I have connected to Rx and Tx respectively.

\$\endgroup\$
  • 4
    \$\begingroup\$ Do you mean flow control or direction control? Flow control can be done in software or hardware. You seem to be very confused in general here and a lot of your question makes no sense. We need a schematic of how your system is set up and what you mean by flow control which I suspect is direction control. \$\endgroup\$ – DiBosco Aug 18 '17 at 10:18
  • 3
    \$\begingroup\$ You normally don't use hardware flow control with RS485 so that should be fine. But how do you know it's not sending / receiving? Are you looking at the lines with an oscilloscope, or is it just because the other device isn't responding? But you need some more details on all that in your question. \$\endgroup\$ – PeterJ Aug 18 '17 at 10:19
  • \$\begingroup\$ Edited my initial post to add more details. I might have confused flow control and direction control. But is either of them needed. \$\endgroup\$ – Sumanth V Aug 18 '17 at 14:30
  • \$\begingroup\$ I have designed fibre repeaters for RS-485 and as they had no idea which side of the link would talk next they idled in RX mode. As soon as they received bus data they would repeat it over the fibre. When they received fibre data they would enable the bus transmit for a period equal to a tiny portion less than a complete ASYNCH protocol word and then wait for the next activity ready to change direction at the end of each byte. Yes there were DIP switches. \$\endgroup\$ – KalleMP Aug 19 '17 at 19:54
3
\$\begingroup\$

RS485 is a multidrop bus, which means that a number of nodes are connected to the same bus and, in this case, they all have the potential to "talk" at the same time. For a device to take control of the bus and be able to talk, the RS485 transceiver (in your case the MAX3160) has to have its transmit enable pin be enabled. All the other devices on the bus need to have them disabled. If more than one device is enabled to transmit, data can become garbled because one device might be trying to drive the bus in one state and another device trying to drive the bus in a different state.

You enable the device to take control of the bus by setting the DE pin high. Once it is high, anything on the DI pin is transmitted on to the bus. It is important to note that all other devices on the bus should have their DE pins low.

The other enable pin on the transceiver is usually called the ~RE pin. Note that this is low for anything on the bus to be reflected on the RO pin. That looks like it's the R1OUT on your Max device.

A lot of the time, you see the ~RE and DE pins connected together and to a GPIO on the micro. This GPIO determines whether you are listening to what other nodes on the bus are saying or talking on the bus yourself.

All this is not to be confused with flow control which is often used on devices such as modems that are relatively dumb and have relatively small data buffers. This is a method of each device saying it is ready to send more data out or ready to receive data in. This can be done in hardware with RTS/CTS pins and can also be done in software with XON/OFF messages. There are lots of good resources on line that explain this very well and I still dip in and out of these every now and again because it can get confusing!

It's probably worth noting that there are various methods of deciding who is allowed to talk on the bus at any one time. There always needs to be a method of knowing who is the one master at any one moment in time.

So, to listen on the bus, ensure ~RE (R1OUT) and DE are low. To transmit on to the bus, DE should be high. If ~RE is high at the same time, you will not get what is being transmitted, send back to the Rx pin of the UART on your micro.

\$\endgroup\$
  • 1
    \$\begingroup\$ All my devices are just daisy chained and connected to the same rx and tx. I am sending a modbus req data to all the devices. One of the field in this request is slave address. So only the intended slave responds back. It's only half duplex. So I was of the assumption that not all devices will transmit simultaneously. So I never cared about direction control. Will try out the way you mentioned. \$\endgroup\$ – Sumanth V Aug 18 '17 at 23:41
  • \$\begingroup\$ Set the DE pin high just before transmitting on UART. Connected a wire from DE to ~RE. So both can be controlled with just DE pin. Set DE pin low in UART transmit complete interrupt. Now can send and receive the data. Occasionally i get the last byte that is transmitted back in RX at the micro. Looks like some timing issue regarding ~RE. Currently solving it in by adding some software logic. \$\endgroup\$ – Sumanth V Aug 22 '17 at 1:35
2
\$\begingroup\$
Is it possible to send/recieve on RS485 without flow control.

Yes, since there is no flow control in RS-485.

RS-485 is a single signal, implemented as a differential pair. That gives it good noise immunity and common mode rejection, but it is still a single signal. There is no provision for flow control.

Like everything beyond just sending a single character on RS-485, the rest is up to your implementation. It is up to you to decide when nodes know they are allowed to transmit, how much they are allowed to transmit at any one time, etc.

The best scenario for flow control is to make sure all receivers are capable of taking the maximum sustained data rate of any transmitter. If that is not the case, then you need to implement data throttling somehow, but that's completely outside the RS-485 spec.

Generally you implement data throttling as part of the higher level protocol that is used to decide who can send. Generally the sender is only allowed to send a single packet at a time. These usually have a maximum length, so there is a maximum a node can send without getting more permission, or another time slot, or whatever. Implementing data throttling by using low level flow control on a multi-drop bus like RS-485 doesn't make a lot of sense.

If all this sounds too complicated, take a look at CAN as a alternative to your RS-485 network. CAN also uses a single signal implemented as a differential pair, so has similar noise immunity and robustness. However, CAN defines several layers above the low level signalling. It includes whole packets, packet validation, collision detection and retry, and a few other niceties.

All these parts of CAN being standard allows them to be implemented in off the shelf silicon. There are many microcontrollers out there that implement CAN in hardware up to the packet level. The firmware sends and receives whole packets, with the hardware taking care of the rest, including the CRC checksum generation and validation.

If you are designing a new system today, RS-485 is rarely a good choice. Look seriously into CAN instead.

\$\endgroup\$
  • \$\begingroup\$ I have to respectfully disagree that RS485 is rarely a good choice, I think it very much depends on the system. I would still use RS485 in many situations and CAN has its own disadvantages like only having a maximum payload of eight bytes and only having a maximum speed of 1Mbit/s. CAN is fabulous where you have nodes that might all talk at any one time, but when you have a master slave system I think RS485 still has its place in many applications. \$\endgroup\$ – DiBosco Aug 21 '17 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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