Dual-MCU Industrial Motor Controller Board (Modbus RTU/TCP)

An industrial motor controller board built around two microcontrollers with clearly separated responsibilities: a communication MCU that speaks Modbus RTU (over RS-485) and Modbus TCP (over Ethernet) to the plant/SCADA, and a control MCU that runs the deterministic motor-control logic. The two processors exchange setpoints and telemetry over a high-speed SPI channel, keeping heavy network traffic away from the control loop.

Industrial motor control and industrial communication have conflicting timing needs:

• Motor control must be hard real-time — current/speed loops, PWM updates, encoder reads, and fault/limit handling have to run on a fixed, jitter-free schedule.
• Modbus RTU/TCP traffic is bursty and unpredictable — a master can flood the device with register polls, and a TCP stack adds variable latency.

Running both on one MCU means a burst of network activity can stall the control loop — unacceptable when real motors are moving. The board had to guarantee that communication load could never compromise control determinism.

Two MCUs, one clear split

The board uses a dual-MCU architecture so each processor does one job well:

• Communication MCU — runs the full Modbus RTU stack over RS-485 and Modbus TCP over Ethernet, exposes the device register map to the SCADA/PLC master, and handles configuration.
• Control MCU — runs the deterministic motor-control loop: PWM generation, encoder/feedback, acceleration profiles, and fault / limit / E-stop handling on a fixed schedule.

High-speed SPI bridge

The two MCUs are linked by a high-speed SPI channel with a defined message protocol:

• The communication MCU acts as SPI master, pushing setpoints/commands down and pulling status/telemetry back.
• Frames are length-prefixed and CRC-checked, with double-buffering so an in-flight transfer never exposes a half-updated register.
• A mirrored register map keeps Modbus registers and control parameters in sync across the link, so a Modbus write transparently becomes a motor setpoint.

:::info
Because control lives on its own MCU, the loop keeps running even while the communication MCU is saturated with Modbus polling — comms jitter can't reach the motors.
:::

• Decoupled networking from control: the control loop runs uninterrupted regardless of Modbus traffic.
• Independently testable firmware: each MCU can be developed, debugged, and updated on its own.
• Reusable Modbus RTU/TCP stack shared with other industrial products.

Add to confirm and quantify: control-loop rate (kHz), SPI clock (MHz), number of motor channels/axes, MCU parts (e.g. STM32F4 for control, STM32F4/F7 for comms), and any deployment/customer context.