Wiznet makers

Summary

This project is a hands-on comparison of two common ways to add wired Ethernet to an ESP32: an RMII PHY (LAN8720) versus a SPI Ethernet controller (WIZnet W5500). The author’s real deployment constraint—stable connectivity inside a closed electrical cabinet while measuring power consumption—drives the decision: even though LAN8720 can reach much higher throughput, the W5500 path wins on integration simplicity and practical stability for typical industrial IoT traffic.

What the Project Does

Adrian Jimenez set up repeatable throughput tests to answer a very practical question: “Which Ethernet approach is actually better on ESP32 when you account for wiring, boot behavior, and real network performance?” The test setup uses ESP-IDF v5.5.1 on an ESP32-DEVKITC-V4, forces link modes using ethtool, and measures TCP/UDP throughput with iperf (ESP32 as client, PC as server).

The work is split into two deliverables:

• A detailed write-up (the Medium article) documenting the real hardware problems encountered and how they impacted results.
• A reproducible ESP-IDF codebase (esp32_ethernet_modules) that abstracts Ethernet bring-up behind a common init/start flow.

Where WIZnet Fits

WIZnet’s W5500 represents the “SPI Ethernet controller” approach: instead of relying on the ESP32’s internal Ethernet MAC + an external RMII PHY, the ESP32 talks to the Ethernet module over SPI, using far fewer pins and avoiding RMII clock/pin constraints. The article highlights these practical advantages (SPI-only wiring, no ESP32 RAM used for packet buffering, and lower CPU load), at the cost of lower throughput and some added latency from the SPI path.

For industrial deployments, that trade-off often lines up with reality: most cabinet-mounted endpoints are pushing MQTT/HTTP telemetry, not saturating 100 Mbps. The author’s conclusion reflects that: the W5500 is slower, but “more stable” and easier to implement without board-level modifications.

(Reference specs that matter when sizing the design: W5500 provides a hardwired TCP/IP offload model with up to 8 sockets and 32 KB internal TX/RX buffer memory, and communicates over high-speed SPI.)

Implementation Notes

This project includes real, buildable code that selects W5500 through ESP-IDF’s Ethernet configuration and instantiates the W5500 driver when that option is enabled.

Snippet 1 — Selecting W5500 in project configuration
File: components/ethernet_connect/Kconfig.projbuild

config USE_W5500
    bool "W5500 Module"
    select ETH_SPI_ETHERNET_W5500

Snippet 2 — Creating the W5500 MAC/PHY instances in the Ethernet bring-up code
File: components/ethernet_connect/ethernet_connect.c (inside the SPI Ethernet init path)

#elif CONFIG_USE_W5500
  eth_w5500_config_t w5500_config = ETH_W5500_DEFAULT_CONFIG(CONFIG_ETH_SPI_HOST, &spi_devcfg);
  w5500_config.int_gpio_num = CONFIG_ETH_SPI_INT_GPIO;
  esp_eth_mac_t *mac = esp_eth_mac_new_w5500(&w5500_config, &mac_config);
  esp_eth_phy_t *phy = esp_eth_phy_new_w5500(&phy_config);
#endif

Practical Tips / Pitfalls

• LAN8720 boot trap on ESP32: the article documents REF_CLK on GPIO0 (boot strap) causing random “waiting for download” boots unless you redesign/modify the clock/enable behavior.
• RMII signal integrity is real engineering, not a software tweak: a ~5 cm REF_CLK run without termination produced an “OK link, unusable throughput” failure mode; shortening the clock line to ~1–2 cm and adding ~33 Ω series termination is called out as a fix/design practice.
• Expect the speed gap: measured W5500 throughput tops out around ~7.1–9.1 Mbps, while LAN8720 can reach ~55.8–93.8 Mbps (with reported packet loss in the best UDP case).
• Pin budgeting favors W5500: LAN8720 RMII uses fixed ESP32 pins for data/control plus REF_CLK; W5500 only needs SPI + CS/INT/RST, which is easier to fit into real products.
• If your traffic is telemetry, prioritize stability: the author observed less bandwidth variation and no UDP packet loss with W5500 in the presented results, and chose it on that basis.

FAQ

Q1. Why choose W5500 here if LAN8720 is much faster?
Because the project’s success criteria weren’t “max Mbps,” but stable wired networking in a harsh RF/mechanical environment (a closed electrical cabinet) with minimal hardware risk. The tests show LAN8720 can be an order of magnitude faster, but the write-up highlights boot/pin and signal-integrity hazards that can dominate real-world reliability.

Q2. How does W5500 connect to ESP32 in this setup?
Over SPI plus a few control lines. The article’s example wiring lists RST/INT and SPI signals (MISO/MOSI/SCLK/CS), which is substantially simpler than RMII pin requirements for an external PHY.

Q3. What role does W5500 play in this project specifically?
W5500 is one of the Ethernet backends under test. In the accompanying ESP-IDF project, selecting the W5500 option routes Ethernet initialization through esp_eth_mac_new_w5500() / esp_eth_phy_new_w5500() so the exact same iperf test application can run on top.

Q4. Can beginners reproduce this comparison without designing custom hardware?
Yes—if they stick to off-the-shelf modules and treat LAN8720 as “not plug-and-play.” The test method (ESP-IDF + iperf + ethtool) is reproducible, but the LAN8720 path may require board modifications or a better RMII layout to avoid boot/clock integrity issues. W5500 tends to be the easier starting point because it avoids RMII constraints.

Q5. What’s the most important comparison versus the alternative (LAN8720 RMII PHY)?
LAN8720 leverages the ESP32’s internal MAC and can reach near–Fast Ethernet throughput, but it consumes many fixed pins and is sensitive to clock routing and board design. W5500 is slower due to SPI limits, but uses fewer pins, avoids RMII clock pitfalls, and is often “good enough” for industrial IoT telemetry where robustness beats raw bandwidth.