Wiznet makers

Open Source Contribution: ESP32 + W6100 Driver PR Under Review at Espressif

The ESP32 series is widely used for its built-in Wi-Fi and Bluetooth, but in industrial environments or applications requiring wired network connectivity, Ethernet is often essential. Espressif's official SDK, ESP-IDF, first introduced SPI Ethernet support in v4.4, including an official W5500 driver. While the W5500 driver has remained part of ESP-IDF through v5.x, its successor — the W6100, which adds native IPv6 support — has had no official driver available.

In January 2026, developer docwilco submitted a Pull Request to Espressif's external Ethernet driver repository, esp-eth-drivers, adding full W6100 driver support. This is the first publicly available implementation enabling the W6100 to work directly within the ESP-IDF ecosystem.

The Role of the WIZnet W6100

The W6100 is a Hardwired TCP/IP Ethernet controller with the entire TCP/IP stack implemented in hardware. The MCU only needs to access socket registers over SPI to handle TCP, UDP, IPv4, and IPv6 communication — no software TCP/IP stack required. This makes it well-suited for resource-constrained MCU environments where reliable network performance is needed.

Key differences from the W5500:

According to the contributor's own testing, the W6100 showed slightly higher throughput than the W5500 under identical conditions.

How It Works

The driver follows ESP-IDF's Ethernet driver architecture, separating the MAC and PHY layers. Here's a breakdown of the key design decisions.

1. wiznet_common — Shared 3-Layer Architecture

Common code shared between W5500 and W6100 has been extracted into a wiznet_common component, covering the SPI transport (wiznet_spi.c), MAC common logic (wiznet_mac_common.c), and PHY common logic (wiznet_phy_common.c). The W6100 driver only needs to implement a wiznet_chip_ops_t structure defining chip-specific behavior; TX/RX handling, the EMAC task, and initialization sequences are all handled by the shared layer. The W5500 driver has been refactored to use the same structure.

esp-eth-drivers/
├── wiznet_common/          ← Shared layer for W5500 / W6100
│   ├── wiznet_spi.c        SPI transport
│   ├── wiznet_mac_common.c MAC TX/RX, EMAC task
│   └── wiznet_phy_common.c PHY link detection, speed/duplex negotiation
├── w5500/                  ← Depends on wiznet_common, chip-specific ops only
└── w6100/                  ← Depends on wiznet_common, chip-specific ops only

2. WIZnet-Specific SPI Frame Format

WIZnet chips use a non-standard SPI frame layout. The driver maps this to ESP-IDF's SPI driver fields as follows:

[ command_bits = 16 ]  [ address_bits = 8 ]  [ data ]
     Address phase         Control phase       R/W data

For register reads of 4 bytes or less, the SPI_TRANS_USE_RXDATA flag is used to prevent 4-byte boundary overwrites.

3. Chip Initialization Sequence

Software reset (clear RST bit in SYCR0)
      ↓
Wait for stabilization (60.3ms per datasheet)
      ↓
Poll W6100_REG_CIDR → verify Chip ID = 0x6100
      ↓
Unlock NETLCKR → clear NETMR (disable IPv4/IPv6 blocking)
      ↓
Call wiznet_setup_default()
(buffer allocation, socket mode, interrupt setup)
      ↓
Set SYCR1 IEN bit → enable global interrupt

4. PHY Register Bit Interpretation — Inverted from W5500

The W6100's PHYSR (PHY Status Register) has inverted speed and duplex bit meanings compared to the W5500:

The driver abstracts this difference via the speed_when_bit_set/clear fields in phy_wiznet_config_t and an opmode lookup table, so upper layers remain chip-agnostic.

5. Multicast Filtering

The W6100 controls multicast reception via the MMB (IPv4 multicast block) and MMB6 (IPv6 multicast block) bits in the Socket Mode Register (SMR).

add_mac_filter(addr) called
      ↓
Identify by MAC address prefix:
  01:00:5e:xx → IPv4 multicast
  33:33:xx    → IPv6 multicast
      ↓
Increment internal counter (v4_cnt / v6_cnt)
counter 0 → 1: clear MMB / MMB6 bit (allow reception)

rm_mac_filter(addr) called → decrement counter
counter 1 → 0: re-enable MMB / MMB6 bit (block reception)

While W5500 can only block IPv4 multicast, W6100 supports independent control of both IPv4 and IPv6 multicast.

6. ESP-IDF Version-Gated Features

// Multicast filter API only available on ESP-IDF v5.5 and above
#if ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(5, 5, 0)
    mac->add_mac_filter    = emac_w6100_add_mac_filter;
    mac->rm_mac_filter     = emac_w6100_rm_mac_filter;
    mac->set_all_multicast = emac_w6100_set_all_multicast;
#endif

Potential Applications

Once merged into esp-eth-drivers, the ESP32 + W6100 combination will be easily integrated into any project via the ESP-IDF Component Manager.

Applicable scenarios include:

• Industrial automation and edge gateways: Devices that require stable wired Ethernet rather than Wi-Fi, such as PLC-connected units or data acquisition gateways
• IPv6 transition environments: New systems such as telecom infrastructure or smart home hubs that require native IPv6 support
• Multicast-dependent protocols: Implementing mDNS, CoAP, or IGMP-based services on ESP32, where W6100's IPv6 multicast filtering becomes a practical advantage
• ODM/OEM design: Migrating from W5500-based boards to W6100 is straightforward thanks to the shared wiznet_common layer, minimizing driver migration effort

The contributor has also mentioned plans to develop a W6300 driver once this PR is merged, meaning the wiznet_common architecture is already positioned as the foundation for future WIZnet chip support.

Technical Summary

Current Status

This PR is currently under active development, with code feedback being exchanged between the contributor and Espressif's internal reviewers. Developers interested in the ESP32 + W6100 combination are encouraged to follow the PR. If you have thoughts on the implementation or test results, leaving a comment on the PR would be a helpful contribution.

👉 https://github.com/espressif/esp-eth-drivers/pull/133