Modbus RTU vs Modbus TCP, and Building an RTU→TCP Gateway with the W5500 / DM9051
Modbus RTU and TCP are really two transport layers of the same protocol: identical data model and function codes, differing only in physical layer, framing and checksum (RTU uses CRC-16 over serial; TCP uses an MBAP header on port 502 with no CRC). This guide explains the difference and how to build an RTU→TCP gateway with the hardwired-TCP/IP W5500 (least effort) or the SPI MAC+PHY DM9051 (most flexible).
The same Modbus, two transport layers
Modbus comes in two common forms: Modbus RTU (over RS-485/RS-232 serial) and Modbus TCP (over Ethernet). Many people think they are two different protocols, but at the core they are the same one: both share the identical data model and function codes — the same four tables of Coils, Discrete Inputs, Input Registers and Holding Registers, and the same function codes. What actually differs is only three things: the physical layer (serial vs Ethernet), the framing, and the integrity check. Once you grasp “same core, different shell,” you see why an RTU↔TCP conversion doesn’t translate the application layer — it only swaps the frame.
RTU (CRC-16 + serial) vs TCP (MBAP + port 502)
Where does the framing differ? A Modbus RTU frame = a 1-byte slave address + function code + data + a 16-bit CRC, with the start/end delimited by a silent interval of at least 3.5 character times; integrity is handled by the CRC-16 itself; a bus holds up to 247 slaves (addresses 1–247, 0 = broadcast). Modbus TCP instead replaces the “address + CRC” with a 7-byte MBAP header (Transaction Identifier + Protocol Identifier + Length + Unit Identifier), runs on TCP port 502, and does no Modbus-layer CRC — because the lower-layer Ethernet frame CRC and TCP checksum/retransmission already guarantee integrity, so another layer would be redundant. Also, TCP is client-server and supports multiple simultaneous connections, while RTU is single-master/multi-slave sharing one bus, one transaction at a time.
What an RTU→TCP gateway does
What does an RTU→TCP gateway do? Upward it is a Modbus TCP server (port 502); downward it is an RS-485 master polling the legacy devices; in between it does a two-way “re-shell”: downstream (SCADA→device), on receiving a TCP request it takes the PDU after the MBAP (function code + data, untouched), uses the MBAP’s Unit ID as the RS-485 slave address at the front of an RTU frame, appends the CRC-16, and sends it on the serial bus; upstream (device→SCADA), it takes the serial reply, strips the trailing CRC, rebuilds the MBAP using the original request’s Transaction ID, and sends it back over TCP. The key point: the application-layer PDU is never altered — the gateway only swaps the shell and manages “which Unit ID maps to which serial slave.” So your field full of legacy RS-485 Modbus devices doesn’t need replacing; add one gateway and they connect to Ethernet/SCADA. (Details like timeouts, retries and exception-code pass-through vary slightly between implementations.)
The gateway’s three pieces: why W5500 is least effort, DM9051 most flexible
The gateway hardware is just three pieces: on the serial side an RS-485 transceiver (half-duplex, you must control the transmit/receive direction); in the middle an MCU (handling Modbus frame assembly/disassembly, CRC calculation, Unit-ID mapping, and the most demanding part — serial timing and bus turnaround, since RTU is delimited by the 3.5-character silence and discards a frame if the inter-character gap exceeds 1.5 characters); and on the TCP side an Ethernet chip providing the port-502 socket. How you pick the Ethernet chip is decisive: the WIZnet W5500 builds the whole TCP/IP stack into silicon (hardwired TCP/IP), so the MCU just does socket programming over SPI (open/listen/recv/send) and never runs TCP/IP in firmware — leaving the MCU only Modbus framing + serial timing, with very light code, low RAM/Flash needs and steady real-time behavior that even a low-end MCU can handle (the W5500 has a 32KB buffer and 8 sockets, serving several SCADA clients at once). The DAVICOM DM9051 is instead an SPI MAC+PHY (it has IP/TCP/UDP checksum offload, but that is not the same as a hardwired TCP/IP stack), so TCP/IP still runs as a software stack (such as lwIP) on the host MCU: heavier on MCU resources, but in return more flexible — you can run other network functions needing raw sockets / custom protocols / RTOS integration on the same part, not boxed in by a fixed stack.
How to choose
How to choose: the field is RS-485 serial and you need it on Ethernet/SCADA → build an RTU→TCP gateway (legacy devices and wiring stay untouched). On the Ethernet side, if you just want a simple, stable Modbus TCP server with the lightest firmware and steadiest real-time behavior, even on a low-end MCU → choose the hardwired-TCP/IP W5500; if you also need to run other network protocols on the same part, want raw-socket flexibility, or already have an lwIP + RTOS architecture → choose the DM9051 (MAC+PHY + software stack). Neither RTU nor TCP is universally better — TCP has retransmission but also connection-latency jitter, while RTU has its own advantage in deterministic serial timing; it depends on the case. JLink Technology is an authorized distributor for both WIZnet and DAVICOM, supplying both Ethernet paths — hardwired TCP/IP (W5500/W6100) and SPI MAC+PHY (DM9051) — plus matching GD32 MCUs; tell us your device count, serial/Ethernet needs and real-time requirements, and we will help plan the gateway architecture and reply with samples, datasheets and pricing.
Products mentioned
W5500 Hardwired TCP/IP Ethernet Controller
W5500 is WIZnet's flagship Ethernet controller with a unique hardwired TCP/IP stack, enabling direct network connectivity without software TCP/IP implementation. Connects to the host MCU via SPI, features 32KB TX/RX buffer, supports up to 8 sockets — the most widely adopted Ethernet chip in the Arduino/Raspberry Pi ecosystem.
DM9051 SPI Interface 10/100M Ethernet Controller
DM9051 is a DAVICOM single-chip 10/100M Fast Ethernet controller with an SPI interface, eliminating the need for 8/16-bit parallel bus and greatly simplifying hardware design. Features 16KB SRAM TX/RX buffer, full-duplex flow control, and native Linux kernel driver support — ideal for network expansion on ARM or RISC-V MCU systems.
GD32F303 Arm Cortex-M4 Mainstream MCU
The GD32F303 is a mainstream Arm Cortex-M4 MCU from GigaDevice at 120MHz (with DSP/FPU/MPU), 128KB~3MB Flash, 32~96KB SRAM, 3× 12-bit ADC, 2× DAC, rich timers, and USB FS/CAN/SDIO. In LQFP48/64/100/144, it is commonly used as an M4 upgrade from STM32F1 or an STM32F303-class alternative.
Need these components or design help?
JLink Technology provides parts, datasheets, and engineering support.
Request a Quote