GigaDevice Explains Why Ether‑CAT Is Essential for Robot Joint Control

What the company claims

During a web‑seminar titled Secure Robotics in Motion, GigaDevice promoted its GD32H75E MCU as a “one‑stop” solution for robot joint control. The key selling points were:

• Ether‑CAT slave controller integrated on the same die as a Cortex‑M7 core (up to 600 MHz, dual‑precision FPU, DSP extensions).
• Cycle times of 20 – 250 µs with jitter under 1 µs.
• Hardware blocks for motion‑control math (trigonometric unit, FIR/IIR filters, high‑performance digital filter, encoder‑frequency divider).
• Security accelerators (AES, SHA, HMAC, TRNG, secure boot) aimed at network‑connected robots.

The company framed these numbers as “critical” for synchronizing the 10‑20 DOF typical of a dexterous humanoid hand.

What’s actually new

Ether‑CAT basics

Ether‑CAT is a deterministic, master‑slave fieldbus that re‑uses standard Ethernet physical layers but differs in how frames are processed. A single Ethernet frame is injected by the master and passes through every slave node; each node reads or writes its data on‑the‑fly without waiting for the frame to be fully received. This “on‑the‑fly” processing eliminates the per‑node latency that plagues classic TCP/IP or even standard industrial Ethernet (e.g., Profinet RT).

Because the frame traverses the line only once, the overall cycle time scales with cable length and node count rather than with the number of protocol stacks. In practice, a well‑tuned Ether‑CAT network can achieve sub‑250 µs cycles on a 10‑node chain, which matches the numbers GigaDevice quoted. The distributed clock (DC) mechanism further aligns all slaves to a common time base, limiting jitter to sub‑microsecond levels.

Integration level

What GigaDevice really adds is the integration of the Ether‑CAT slave controller and two Ethernet PHYs into the same silicon package as the MCU. Competing approaches typically use a separate Ether‑CAT ASIC or an FPGA‑based slave. By moving these blocks onto the GD32H75E, board designers can drop a handful of external components (slave controller, PHY, termination resistors), reducing BOM cost and PCB area.

The MCU’s motion‑control extensions (TMU, FIR/IIR, HPDF, EDOUT) are not unique to GigaDevice; similar DSP‑oriented peripherals exist in other high‑performance MCUs (e.g., ST’s STM32H7 series, NXP’s i.MX RT). The novelty lies in bundling them with Ether‑CAT rather than offering them as optional peripherals.

Security features

AES‑256, SHA‑256, HMAC, a true‑random number generator, e‑Fuse key storage, and secure boot are now commonplace in industrial‑grade MCUs. GigaDevice’s claim that these are “critical for robots connecting to networks” is accurate, but the security posture still depends on firmware update policies, key management, and the master’s own security stack—none of which are addressed by the chip alone.

Limitations and trade‑offs

• Determinism vs. network topology: Ether‑CAT’s low jitter assumes a linear or ring topology with short cable runs. Adding switches or long fiber links re‑introduces latency and may require Ether‑CAT‑compatible bridge devices, which can erode the claimed cycle times.
• Scalability: While a 10‑node chain fits comfortably within the 20‑250 µs window, larger robots (e.g., full‑scale humanoids with >30 joints) often need multiple Ether‑CAT segments and a more powerful master. The GD32H75E does not address master functionality, so a separate controller is still required.
• Processing headroom: The Cortex‑M7 at 600 MHz can handle the motion‑control math, but complex trajectory planning or vision‑based feedback may exceed the MCU’s capacity, forcing a co‑processor or an external AI accelerator.
• Toolchain maturity: GigaDevice provides an Ether‑CAT stack, but integration with popular robotics middleware (ROS 2, OROCOS) still requires custom glue code. The learning curve for developers unfamiliar with Ether‑CAT can be steep.
• Cost comparison: Integrated solutions reduce board‑level component count, yet the GD32H75E’s per‑unit price is comparable to a standard Cortex‑M7 MCU plus a discrete Ether‑CAT slave. For low‑volume projects, the cost advantage may be marginal.

Practical takeaways

1. If you need a compact joint‑controller board for a modest‑size robot (≤10 axes) and you already plan to use Ether‑CAT, the GD32H75E offers a tidy package that cuts down on external parts.
2. For larger systems you’ll still need a dedicated Ether‑CAT master and possibly multiple slave segments; the MCU’s integration does not eliminate that architectural complexity.
3. Security is only as strong as the overall system. Hardware accelerators help, but you must enforce secure firmware delivery and key provisioning at the system level.
4. Benchmarking matters. The advertised 20 µs lower bound assumes an optimal setup; real‑world measurements on a full robot will likely land in the 100‑200 µs range, which is still acceptable for most joint‑level loops but not for high‑speed haptic feedback.

Bottom line

GigaDevice’s GD32H75E is not a paradigm‑shifting product, but it does represent a sensible step toward tighter integration of real‑time fieldbus and motion‑control hardware. The performance numbers line up with what Ether‑CAT can deliver, and the on‑chip security blocks are a practical addition for connected robots. Designers should still evaluate network topology, master requirements, and overall processing load before assuming the chip solves all timing and safety challenges.

References

• Ether‑CAT Technology Overview – EtherCAT Technology Group
• GD32H75E datasheet – GigaDevice
• ROS 2 and Ether‑CAT integration guide – ROS‑Industrial