In short: RS-485 is only an electrical (physical-layer) standard for balanced differential signalling on a shared bus; it defines no frames, addresses or error checking, so protocols such as Modbus RTU, Profibus DP and DMX512 sit on top of it, and the transmitter must be switched on and off by a direction-control pin.
RS-485 is a wire standard, not a protocol
A very common interview slip is to say "we talk to the meter over RS-485 protocol". There is no such thing. TIA/EIA-485 specifies voltage levels, driver and receiver behaviour, bus loading and common-mode range. It says nothing about what a byte means, who may talk, or how to detect corruption. Those jobs belong to the layers above, in the OSI sense: RS-485 is layer 1, while a UART supplies the bit-level framing (start bit, data, parity, stop) and a protocol supplies addressing, timing rules and a checksum.
That separation is why one transceiver chip such as the classic 8-pin MAX485 or SN65HVD72 can serve a PLC register map today and a stage-lighting rig tomorrow. Only the firmware changes. If you want the electrical story in more depth, read our RS-485 communication primer; here we concentrate on the layering and on the one piece of hardware control that trips up almost every first design.
What the physical layer actually guarantees
The driver pushes a differential voltage onto a twisted pair, called A and B (or D- and D+, and yes, vendors disagree on polarity naming, which is a classic commissioning headache). A receiver reads the difference, not the absolute level, and must resolve a signal as small as 200 mV. The permitted common-mode window is roughly -7 V to +12 V, so ground shifts between distant cabinets do not corrupt data. Because noise couples equally onto both conductors of a twisted pair, the subtraction cancels it.
- Multi-drop: 32 unit loads per segment in the original spec; fractional-load transceivers (1/4 or 1/8 unit load) allow up to 128 or 256 devices.
- Reach versus speed: about 10 Mbit/s over 12 m, falling to around 100 kbit/s at 1200 m of 24 AWG cable.
- Termination: 120 Ω at the two physical ends of the trunk only, never on every node, and stubs kept short.
- Half duplex on one pair: a two-wire network lets only one driver talk at a time. Four-wire variants give a master separate transmit and receive pairs.
Key fact: RS-485 allows many drivers on one pair, but only one may be enabled at any instant. Nothing in the standard arbitrates who that is; the protocol must.
Protocols that ride on it
| Protocol | Typical rate | Who talks | Notable framing |
|---|---|---|---|
| Modbus RTU | 9.6k to 115.2 kbit/s | One master, up to 247 slaves | Silence of 3.5 characters, CRC-16 |
| Profibus DP | 9.6 kbit/s to 12 Mbit/s | Token passing between masters, polled slaves | 126 addresses, 32 nodes per segment, shielded cable |
| DMX512 | 250 kbit/s fixed | One sender, receivers only listen | Break of at least 88 µs, 512 channels, 8N2 |
| BACnet MS/TP | 9.6 to 115.2 kbit/s | Token passing | Building automation, CRC-16 data frame |
Look at how different the upper layers are. Modbus RTU is strict request and reply: the master sends an address byte, a function code (03 reads holding registers), data, then a two-byte CRC. The frame boundary is not a delimiter at all, just a gap of silence of at least 3.5 character times. At 9600 baud with 11-bit characters that is about 4 ms, so a Linux userspace master that sleeps unpredictably between bytes can corrupt its own frames. Profibus DP adds token rotation and hard real-time cycles, using the same physical layer at far higher speeds, which is why its cables, connectors and termination rules are tightly specified. DMX512 is the simplest of all: a one-way broadcast, so the receivers do not even need a driver.
Key fact: Two devices both labelled "RS-485" will still not communicate unless they also agree on protocol, baud rate, parity and addressing. Matching the wire is only the first step.
Driver direction control, step by step
On a half-duplex bus, your transceiver has a driver enable pin (DE, active high) and a receiver enable pin (/RE, active low). Tie them together and drive them from one GPIO: high means transmit, low means listen. Forget this and either you transmit nothing, or you leave your driver enabled and block everyone else on the bus, which looks like total network failure even though only one node is faulty.
The turnaround timing trap
The subtle part is when you release the line. Calling a UART "write" function usually returns when bytes reach the transmit FIFO, not when the last stop bit has left the shift register. If you drop DIR immediately, the tail of your frame is chopped and the CRC fails at the receiver. The correct approach is to wait for the transmission-complete flag (TC on an STM32, TEMT in a 16550-style UART) before releasing. Better still, use hardware assistance: many STM32 parts have a driver-enable mode with programmable assertion and de-assertion times, and Linux exposes similar behaviour through the TIOCSRS485 ioctl. Cheap USB adapters often use automatic direction circuits that sense the TX line, which works but adds tens of microseconds of delay and fails at high baud rates.
Then comes the opposite problem. After the master finishes, the slave must not reply faster than the master can switch to listening. Modbus gives devices a configurable reply delay for this reason; a few hundred microseconds of margin avoids collisions with slow turnaround.
Bias, fail-safe and the idle state
When nobody drives the bus, A and B float and the receiver can output random bytes from noise. The fix is a bias network: a pull-up on A and pull-down on B (commonly around 680 Ω at one place only, the master) so the idle differential is above 200 mV. Modern fail-safe receivers guarantee a defined output even when the bus is shorted or open, but you still bias for noise margin on long cables. In Modbus RTU and DMX, a missing bias often shows up as stray framing errors on idle.
How engineers debug this in practice
- Probe A and B with a differential probe, or two single-ended probes with the scope's math subtract, and check that idle sits above +200 mV.
- Decode the protocol on the scope or a logic analyzer; a Saleae or a Siglent decoder will show Modbus function codes and CRC failures.
- Measure the gap between the last stop bit and DE falling, which is the usual cause of truncated frames.
- In simulation, model the transceiver as a behavioural block; mixed-signal teams use Cadence Spectre or Synopsys CustomSim for line reflections on a lossy twisted pair, then validate with a bench network.
If your team needs silicon or board design support for industrial interfaces, Avecas design services works on such mixed-signal blocks, and for structured training on the digital side, see ChipXpert VLSI training. For a gentle bridge to other serial standards, our UART, RS-232 and RS-485 comparison is a good next read.
Want to design and debug real serial buses, not just memorise them? Explore the hands-on interface and protocol modules in the CourseTron courses.
Frequently asked questions
Is RS-485 the same as Modbus?
No. RS-485 is the electrical layer; Modbus RTU is a protocol that defines frames, addresses and CRC. Modbus can also run over RS-232 or over Ethernet as Modbus TCP.
Do I need a direction pin for RS-485?
For half-duplex two-wire buses, yes: DE and /RE must be controlled, either by a GPIO, a UART RS-485 mode, or an automatic direction circuit. Full-duplex four-wire links with one driver per pair can leave the driver always enabled.
Why does my DMX line need no turnaround?
DMX512 is unidirectional, so the console permanently drives the line and the fixtures only receive, with no reply to arbitrate.
How many devices fit on one RS-485 segment?
Classically 32 unit loads, and up to 256 with 1/8 unit-load transceivers, provided cable length, baud rate and termination are respected. Repeaters extend the segment.