Using the RS485 interface and saving legs
Once I needed to connect more than two controllers with each other, and even do it at a fairly decent distance. In the process of googling, the choice fell on the ModBus protocol in the implementation over the RS485 interface. ModBus descriptions are ubiquitous and are not considered in this article. Let us dwell in more detail on the RS485 interface.
Twisted pair is most commonly used to transfer data between devices. One pair of data goes in both directions, but not simultaneously, but in turn. All devices that need to communicate, "sit" on the line in parallel. The interface uses differential inputs and outputs. Here are the main points ...
What can we get from using this interface? Of the benefits:
- Ability to transfer over long distances;
- The transmission medium is sufficiently noise-free;
- Easy to add devices to existing lines;
- Transmission at high speed ...
')
Of the minuses - you need to think over the policy of arbitration. Think over the protocol so that either there are no situations when two devices are trying to transmit data simultaneously, or ways out of similar situations. I went on the first, simpler path. I chose the communication option of Single Master controllers (one controller is a master and either sends information to any other or requests information transfer from the device)
The classic connection of the controller to the RS485 network is as follows:
It uses the MAX485 chip (ad485, st485 or equivalent). Leg 1 - received data, leg 4 - data to be transmitted to the line, and 2 and 3 (combined in the figure) to turn on the receiver or transmitter. When merging by a level change, we change the direction of data transfer (to us - from us). I deliberately do not write about which of the levels includes the receiver, and which transmitter for here I myself caught the rake with my forehead.
In the presented picture everything is correctly drawn - here the receiver is turned on with a low signal level, and the transmitter - with a high level. I somehow did not pay attention to this and decided to “improve” the scheme in the following way:
The jamb was detected after the wiring of the board and the assembly of the device: in the standby mode at the TxD output a logical “1” is constantly “on duty”, and in the process of data transmission, there are “zeros”. Thus, my receiver is turned off all the time and the transmitter is turned on.
I have come up with two ways out of this situation:
1. Software. Instead of a hardware serial port, use software, in which all data would be inverted at the output. Plus - it is obvious: you do not need to re-manufacture the board (and I had five of them).
2. Hardware. Put the inverter between the controller output and the input of the converter. The advantages are also obvious: you do not need to write your serial port emulation curves.
There was also a third option - to return to the original, “not optimized” scheme - but it would immediately entail changes in the board and changes in the program - therefore it was immediately discarded. He created difficulties himself - I will overcome it myself.
Looking ahead - I did not rewrite anything and did not dilute new boards. Truth be told - laziness is the engine of progress. Inverter on one transistor, I collected, well, so, in terms of the experiment, right on the cut track.
It turned out scary, but it worked!
The final scheme:
In order to preserve the coloring of the finishing touch from the smd transistor and two output impedances, the circuit is drawn in the point.
In the live it looked the same sloppy and scary, but after three layers of varnish ...
In general, I still save one leg of the microcontroller in the same way, although the scheme has undergone several changes and I began to plant landing areas in advance.
This is part of the scheme. A resistor has been added that will keep the transistor open, if there is no control from the foot of the controller. (If the controller is removed from the panel, it will not interfere with the communication of other devices).
And by the way, that very first system, the third year, how it works, will soon begin.
Twisted pair is most commonly used to transfer data between devices. One pair of data goes in both directions, but not simultaneously, but in turn. All devices that need to communicate, "sit" on the line in parallel. The interface uses differential inputs and outputs. Here are the main points ...
What can we get from using this interface? Of the benefits:
- Ability to transfer over long distances;
- The transmission medium is sufficiently noise-free;
- Easy to add devices to existing lines;
- Transmission at high speed ...
')
Of the minuses - you need to think over the policy of arbitration. Think over the protocol so that either there are no situations when two devices are trying to transmit data simultaneously, or ways out of similar situations. I went on the first, simpler path. I chose the communication option of Single Master controllers (one controller is a master and either sends information to any other or requests information transfer from the device)
The classic connection of the controller to the RS485 network is as follows:
It uses the MAX485 chip (ad485, st485 or equivalent). Leg 1 - received data, leg 4 - data to be transmitted to the line, and 2 and 3 (combined in the figure) to turn on the receiver or transmitter. When merging by a level change, we change the direction of data transfer (to us - from us). I deliberately do not write about which of the levels includes the receiver, and which transmitter for here I myself caught the rake with my forehead.
In the presented picture everything is correctly drawn - here the receiver is turned on with a low signal level, and the transmitter - with a high level. I somehow did not pay attention to this and decided to “improve” the scheme in the following way:
The jamb was detected after the wiring of the board and the assembly of the device: in the standby mode at the TxD output a logical “1” is constantly “on duty”, and in the process of data transmission, there are “zeros”. Thus, my receiver is turned off all the time and the transmitter is turned on.
I have come up with two ways out of this situation:
1. Software. Instead of a hardware serial port, use software, in which all data would be inverted at the output. Plus - it is obvious: you do not need to re-manufacture the board (and I had five of them).
2. Hardware. Put the inverter between the controller output and the input of the converter. The advantages are also obvious: you do not need to write your serial port emulation curves.
There was also a third option - to return to the original, “not optimized” scheme - but it would immediately entail changes in the board and changes in the program - therefore it was immediately discarded. He created difficulties himself - I will overcome it myself.
Looking ahead - I did not rewrite anything and did not dilute new boards. Truth be told - laziness is the engine of progress. Inverter on one transistor, I collected, well, so, in terms of the experiment, right on the cut track.
It turned out scary, but it worked!
The final scheme:
In order to preserve the coloring of the finishing touch from the smd transistor and two output impedances, the circuit is drawn in the point.
In the live it looked the same sloppy and scary, but after three layers of varnish ...
In general, I still save one leg of the microcontroller in the same way, although the scheme has undergone several changes and I began to plant landing areas in advance.
This is part of the scheme. A resistor has been added that will keep the transistor open, if there is no control from the foot of the controller. (If the controller is removed from the panel, it will not interfere with the communication of other devices).
And by the way, that very first system, the third year, how it works, will soon begin.
Source: https://habr.com/ru/post/147393/
All Articles