Quick Answer
An STM32 Industrial Serial Server with 8 isolated RS-485 ports enables simultaneous connection of up to 8 serial devices — PLCs, variable frequency drives, power meters, sensors, and RTUs — to an Ethernet network. Each port operates independently with configurable baud rates up to 115200 bps, supporting Transparent TCP, Modbus RTU-to-TCP Gateway, Virtual COM Port, and MQTT Bridge operating modes. The design uses the STM32F437VIT6 with 64MB DDR3 SDRAM for data buffering.
https://innovchip.net/wp-content/uploads/2026/06/pexels_2047905-5.jpg
Why We Designed a Custom 8-Port Serial Server
Commercial serial servers from Moxa, USR IOT, and NPort work well for simple point-to-point applications: one serial device to one Ethernet connection. But when you need 8 isolated ports with custom protocol handling, data logging, edge computing, and multi-protocol bridging — off-the-shelf products fall short in three ways. First, isolation: most commercial multi-port serial servers share a common ground across all ports, which is unacceptable in installations where devices are powered from different power sources (ground loop risk). Second, flexibility: they typically support only transparent TCP and basic Modbus RTU-to-TCP translation. If you need MQTT bridging or custom protocol parsing, you are out of luck. Third, data handling: they do not buffer data locally during network outages.
We designed our 8-port serial server for a chemical plant client who needed to consolidate 8 separate Modbus RTU networks (each on a different RS-485 bus segment) into a single Ethernet backbone. The total system comprised 96 Modbus devices across 8 networks, with data forwarded to a central SCADA system via Modbus TCP and simultaneously published to a cloud platform via MQTT for remote monitoring.
Hardware Architecture
The core microcontroller is the STM32F437VIT6, a 168 MHz Cortex-M4F with 1MB flash, 256KB SRAM, and an extensive peripheral set. We selected this MCU specifically because it provides 7 USART/UART peripherals (USART1, USART2, USART3, UART4, UART5, USART6, USART7) — enough for 8 ports when we use USART1 with a half-duplex RS-485 transceiver (automatic DE/RE direction control). The hardware floating-point unit enables efficient data scaling and CRC computation without the performance penalty of software emulation.
Each RS-485 port uses the ADM2587EBRWZ isolated transceiver. This single chip provides 2500Vrms galvanic isolation and a full RS-485 transceiver (1/4 unit load, supporting up to 128 devices per bus) in a 20-lead wide-body SOIC package. The 8 ports are divided into two isolation groups of 4 ports each. Each group has a dedicated isolated DC-DC converter (MAX5087ASA+, 5V output from 24V industrial input, 1W output power) that powers the transceiver and the isolator’s secondary side. This dual-isolation architecture prevents ground loops between port groups while keeping the BOM cost reasonable (the MAX5087 costs approximately $2.50 per unit).
The memory subsystem includes 64MB DDR3 SDRAM (MT41K64M16TW-107, 800 MHz) connected via the STM32F4’s FMC (Flexible Memory Controller) for data buffering, and 32MB SPI NOR flash (W25Q256, 133 MHz) for configuration storage, data logging, and firmware images. A MicroSD card slot (SDIO interface) provides additional logging capacity for extended offline operation.
The Ethernet interface uses the LAN8720AI PHY connected to the STM32F4’s MAC via RMII at 100 Mbps. For industrial applications, we use the HR911105A RJ45 connector with integrated magnetics and LED indicators, which simplifies PCB layout and improves EMI performance.
Four Operating Modes
The serial server supports four distinct operating modes, selectable per port through the web management interface:
Mode 1: Transparent TCP Server. Each RS-485 port maps to a dedicated TCP port on the Ethernet interface. For example, RS-485 port 1 maps to TCP port 4001, port 2 to 4002, and so on. When a client application (SCADA system, custom software) establishes a TCP connection to port 4001, all data received on RS-485 port 1 is forwarded to the TCP client, and vice versa. This mode is ideal for existing applications that use TCP socket communication.
Mode 2: Modbus RTU to Modbus TCP Gateway. This is the most commonly used mode in our deployments. Modbus RTU frames received from field devices are translated into Modbus TCP frames on the Ethernet side. The gateway handles the protocol differences transparently: Modbus RTU uses CRC-16 error checking while Modbus TCP uses a 6-byte MBAP header with transaction ID, protocol ID, length, and unit ID. The slave ID in the RTU frame maps to the unit ID in the TCP frame, preserving the device addressing. A Modbus TCP master (SCADA system, HMI, or data historian) communicates with the field devices as if they were directly connected via Modbus TCP.
Mode 3: Virtual COM Port. A Windows driver (provided with the serial server) creates virtual COM ports (COM3 through COM10) that map to the RS-485 ports over Ethernet. This enables existing serial communication software (legacy terminal programs, custom C/C++ applications, Python scripts using pyserial) to work without any modification. The driver encapsulates serial data in a proprietary protocol over TCP, handling baud rate, parity, and flow control settings transparently.
Mode 4: MQTT Bridge. Serial data is published to MQTT topics and received MQTT messages are written to serial ports. This mode is designed for IoT integration where field devices need to communicate with cloud platforms. For example, data from a power meter on port 3 (Modbus RTU, holding registers 40001-40020) can be published to topic site/power/meter_3/telemetry as a JSON payload with device ID, timestamp, and engineering-unit-scaled values.
Firmware Architecture
The firmware runs FreeRTOS 10.4.0 with 9 tasks organized in a priority scheme from 5 to 9. Eight serial port handler tasks (priority 6) manage the UART RX/TX for each port. One network management task (priority 7) handles TCP connections, Modbus TCP protocol processing, MQTT client operations, and the web server. A watchdog supervisor task (priority 9) monitors all other tasks and resets the MCU if any task fails to check in within its expected interval.
Each serial handler uses DMA-based UART reception. The DMA is configured in circular mode for RX, with a 512-byte buffer per port. An IDLE line interrupt fires when the RS-485 bus is silent for more than one character time, indicating the end of a received frame. The ISR calculates the frame length from the DMA NDTR register, copies the frame to a per-port ring buffer, and signals the network task via a binary semaphore. For transmission, we use interrupt-driven UART TX to conserve DMA channels (the STM32F437 has only 16 DMA streams total, and we need them judiciously).
Modbus CRC-16 computation uses the STM32’s CRC hardware peripheral. The CRC unit normally computes CRC-32, but by configuring it with the appropriate polynomial (0x8005 for CRC-16-Modbus, reflected form 0xA001), initial value (0xFFFF), and input/output reversal settings, we can compute Modbus CRC-16 in 4 clock cycles per byte — compared to approximately 50 cycles per byte with a software lookup table implementation. This hardware acceleration is critical when processing 8 simultaneous data streams at 115200 baud.
Performance Characteristics
At 115200 baud, each port handles approximately 11,520 bytes per second (8 data bits, no parity, 1 stop bit = 10 bits per byte, 115200/10 = 11,520 bytes/sec). With all 8 ports operating simultaneously at maximum baud rate, the total throughput is 92,160 bytes/second (approximately 73.7 Mbps with overhead), well within the 100 Mbps Ethernet capacity. In practice, actual throughput is limited by the serial baud rates, not the Ethernet interface.
Latency measurements (RS-485 frame received to Ethernet frame transmitted): transparent TCP mode, 0.5-2ms depending on TCP window state; Modbus RTU-to-TCP mode, 1-5ms (includes CRC verification and MBAP header construction); MQTT bridge mode, 5-20ms (includes topic matching and JSON serialization). These latency figures are measured with a single device per port; latency increases linearly with the number of devices being polled on each port.
Web Management Interface
A built-in HTTP web server (lightweight, single-threaded, approximately 20KB firmware footprint) provides a responsive configuration interface accessible from any browser on the same network. The interface is built with HTML5, CSS3, and vanilla JavaScript (no external frameworks) to minimize firmware size. Configuration pages include: Port Configuration (baud rate, parity, stop bits, operating mode per port), TCP Settings (port mapping, TCP timeouts, keepalive intervals), Modbus Parameters (slave ID range, function code filter, polling configuration), MQTT Settings (broker address, port, TLS options, topic templates), Network Configuration (static IP, subnet, gateway, DNS, DHCP toggle), and System (firmware version, uptime, diagnostic counters, factory reset). All configuration changes are saved to SPI flash immediately and take effect without reboot.
Engineer’s Notes: Technical Lessons
Designing an 8-port serial server with the STM32F437 revealed several non-obvious challenges. First, DMA channel allocation is the single biggest constraint. The STM32F4 has 2 DMA controllers (DMA1 and DMA2), each with 8 streams, and each stream has 4 channel requests. With 8 UARTs all using DMA for reception, plus Ethernet TX/RX DMA, SPI flash DMA, and SDRAM refresh DMA, we ran out of available DMA streams. The solution: use DMA for UART reception only (critical for frame boundary detection with IDLE line interrupt), and use interrupt-driven transmission (acceptable because TX latency is less critical than RX timing). This required manual DMA channel assignment in STM32CubeMX and careful priority configuration to avoid contention.
Second, shared SPI flash access from multiple FreeRTOS tasks requires a mutex with priority inheritance. Without it, a high-priority task waiting for the SPI flash will block, and a lower-priority task holding the mutex will never get CPU time to release it — a classic priority inversion problem. We use a binary semaphore with priority inheritance (xSemaphoreCreateMutexStatic) to protect all SPI flash operations, limiting access to one task at a time with automatic priority boosting for the holding task.
Third, thermal management of the ADM2587E isolated transceivers was an unexpected issue. These chips dissipate approximately 300mW each under continuous load (8 ports at 115200 baud, continuous polling = continuous transceiver switching). Eight transceivers together dissipate 2.4W in a confined PCB area, raising the local temperature by approximately 15°C above ambient in our initial prototype. We solved this with thermal vias (0.3mm diameter, 1mm pitch) connecting the ground pads under each transceiver to an internal ground plane, and adding a copper fill on the bottom layer under the transceiver area to spread the heat.
Frequently Asked Questions
Can different ports use different baud rates simultaneously?
Yes. Each port is completely independent with its own USART peripheral, DMA channel (for RX), and configuration. Port 1 can run at 9600 baud for slow Modbus RTU devices while Port 2 runs at 115200 baud for high-speed serial data. Configuration is per-port and persists in SPI flash across power cycles. Changing baud rate on one port does not affect any other port.
What is the maximum number of devices per port?
RS-485 supports up to 32 unit-load devices on a standard bus. The ADM2587E presents a 1/4 unit load, so theoretically up to 128 devices can be connected per port. In practice, we recommend a maximum of 32 devices per port for reliability — this keeps the bus capacitance well within the RS-485 specification (maximum 2500pF) and ensures adequate signal quality. For networks with more than 32 devices, RS-485 repeaters are required.
Does the serial server support RS-232 as well as RS-485?
The standard configuration is 8 RS-485 ports. However, any individual port can be configured as RS-232 at the hardware design stage by replacing the ADM2587E isolated transceiver with a MAX3232 RS-232 transceiver and removing the isolation barrier for that port. Common configurations we have built include: 6x RS-485 + 2x RS-232 (for connecting 2 legacy RS-232 devices alongside 6 RS-485 networks), and 4x RS-485 + 4x RS-232 (for mixed-protocol environments). This is a build-time configuration, not switchable in the field.
How is firmware updated?
Firmware updates are delivered via the web management interface (upload an .bin file) or via TFTP (Trivial File Transfer Protocol) for automated deployment. The bootloader occupies the first 16KB of flash and performs a CRC check of the application firmware before jumping to it. If the CRC check fails, the bootloader enters recovery mode and waits for a firmware upload via the USB DFU (Device Firmware Upgrade) interface or UART. This dual-update mechanism ensures the device is never bricked by a failed firmware update.
What certifications does the hardware meet?
The 8-port serial server is designed to meet CE (EN 61000-6-2 EMC immunity, EN 61000-6-4 EMC emissions), FCC Part 15 Class A, and IEC 61000-4-2/3/4/5/6/8 surge, EFT, and ESD standards. EMC compliance is achieved through the isolated transceivers, ferrite beads on all I/O lines, and a 4-layer PCB with solid ground planes. We provide pre-compliance test reports and assist with formal certification testing at accredited labs.
Need a custom multi-port industrial serial server? Contact InnovChip Electronics — we design and manufacture custom serial connectivity solutions with full source code ownership and 12-month warranty.