ProtoCore

Why Does ESP32-S3 Need a W5500 for Wired Ethernet, and How Fast Does It Go?

1. What is this project?

ProtoCore is a framework that provides multiple standard network services such as HTTP, SSH, SNMP, and Telnet on ESP32 devices.

In simple terms, it turns an ESP32 from a basic IoT device into a network-managed device that can provide:

HTTP → Web configuration

SSH / Telnet → Remote maintenance

SNMP → Device monitoring

In this example, a W5500 is connected to the ESP32-S3 through SPI, allowing existing Wi-Fi-based network services to also operate over wired Ethernet.

2. Why is this project useful?

Normally, an ESP32 project may require separate libraries and interfaces for Web configuration, remote access, and device monitoring.

ProtoCore integrates these functions into a common network framework.

For example, an industrial gateway can provide:

HTTP → Web-based device configuration

SSH / Telnet → Remote maintenance

SNMP → Device status monitoring

This means a low-cost ESP32 can be extended from a simple IoT node into a small network-managed gateway or controller.

3. Why add W5500 to ESP32-S3?

ESP32-S3 supports Wi-Fi, but unlike the classic ESP32, it does not provide the same built-in RMII Ethernet MAC interface for directly connecting an external Ethernet PHY.

Therefore, an external Ethernet controller is required when wired Ethernet is needed.

In this project, the W5500 provides the wired Ethernet interface that the ESP32-S3 does not have.

The roles can be simplified as:

ESP32-S3 = Application + Network Services + TCP/IP

W5500 = Wired Ethernet Interface

This allows the system to keep the ESP32-S3's Wi-Fi capability while adding wired Ethernet.

The project backs this up with a dedicated example. In NetEgress, Wi-Fi and Ethernet stay
attached at the same time and esp_netif picks the outbound route; ProtoCore reports the active
one through Physical.link->egress() and a /net JSON endpoint. The README states it plainly:
"Wire an Ethernet PHY alongside WiFi and the reported interface flips when you pull the cable."
So the wired link is not a replacement for Wi-Fi — both stay live, and the OS fails over between them.

The result is a single ESP32-S3 platform capable of supporting both Wi-Fi and Ethernet connectivity.

4. How is the system structured?

ProtoCore and lwIP run on the ESP32-S3, while the W5500 is connected externally through SPI and provides the wired Ethernet interface.

ProtoCore provides the network services, lwIP handles TCP/IP, and the W5500 provides the physical Ethernet connection.

5. How is the W5500 used?

This is particularly important from the WIZnet perspective.

The W5500 normally provides a built-in Hardware TCP/IP Offload Engine, or TOE, with hardware sockets.

However, this project does not directly use the W5500 hardware socket API.

Instead, TCP/UDP processing is handled by lwIP on the ESP32-S3.

The W5500 is used primarily as an SPI-based Ethernet interface.

The architecture is therefore:

ProtoCore → lwIP → W5500 → Ethernet

6. Why use this architecture?

The main advantage is that Wi-Fi and Ethernet can share the same TCP/IP software architecture.

For Wi-Fi:

ProtoCore → lwIP → Wi-Fi

For Ethernet:

ProtoCore → lwIP → W5500

From ProtoCore's perspective, upper-layer services such as HTTP, SSH, and SNMP do not need major changes depending on whether the physical network is Wi-Fi or Ethernet.

In simple terms, the existing ESP32 network software can be reused while the physical network connection can be extended from Wi-Fi to wired Ethernet.

7. What does this demonstrate about W5500?

The W5500 is commonly known as a Hardware TCP/IP Offload chip.

However, this project demonstrates another way of using it.

Even without directly using the W5500 TOE, it can provide SPI-based wired Ethernet connectivity to an MCU that does not have a native Ethernet MAC.

This is particularly useful when the ESP32-S3 is selected for features such as:

Wi-Fi

USB

PSRAM

Higher MCU performance

but the final product also requires reliable wired Ethernet.

Instead of changing the MCU platform, the existing system can be extended by adding a W5500.

8. What performance can we expect?

Another useful aspect of this project is that it goes beyond simply demonstrating that Ethernet works.

The project also measures real network throughput.

The published tests show approximately 7–8 Mbit/s of actual throughput, together with large data transfers used to verify data integrity.

Although the W5500 has a 100 Mbps Ethernet interface, the actual application throughput is lower because the data path is:

ESP32-S3 ↔ SPI ↔ W5500

This provides a practical reference for the real performance that developers can expect when using W5500 as an SPI Ethernet interface with ESP32-S3.

9. Is 7–8 Mbit/s enough?

Not every industrial Ethernet application requires 100 Mbps of application throughput.

For typical device-management traffic such as:

Web UI

SSH remote maintenance

SNMP monitoring

Configuration and firmware/data transfer

7–8 Mbit/s can be sufficient.

For high-bandwidth applications such as large-scale video streaming, another Ethernet architecture may be more appropriate.

This project therefore provides useful data for deciding which applications are suitable for an ESP32-S3 + W5500 architecture.

10. Where can this architecture be used?

This architecture is particularly useful for devices that need both Wi-Fi and reliable wired management connectivity.

Possible applications include:

Industrial gateways

Factory controllers

Building automation

Test equipment

Remote monitoring devices

Web-based device configuration

SSH remote maintenance

SNMP-based device management

For example:

                ESP32-S3 Gateway
                 /             \
                /               \
             Wi-Fi             W5500
               │                 │
        Wireless Network     Factory LAN
               │                 │
                      ↓
                   ProtoCore
                      │
             HTTP / SSH / SNMP

This allows a small ESP32-S3 device to operate as a network-managed gateway with both wireless and wired connectivity.

11. Key takeaways

This project is more than simply:

“Connecting a W5500 to an ESP32-S3.”

First,

ProtoCore allows an ESP32 to provide standard network services such as HTTP, SSH, Telnet, and SNMP.

Second,

W5500 adds wired Ethernet to the ESP32-S3 without requiring a different MCU platform.

Third,

Wi-Fi and Ethernet share the same lwIP-based TCP/IP architecture, allowing upper-layer ProtoCore services to be reused across both interfaces.

Finally,

the measured 7–8 Mbit/s throughput provides practical data for determining which applications are suitable for this architecture.

Final Summary

ProtoCore extends the ESP32-S3 into a network-managed device with Web, SSH, Telnet, and SNMP capabilities.

By adding a W5500, the ESP32-S3 can keep its existing Wi-Fi connectivity while also gaining wired Ethernet.

In this project, the W5500 TOE is not directly used. Instead, ESP32 lwIP remains the common TCP/IP layer, allowing the same ProtoCore services to operate over both Wi-Fi and Ethernet.

This demonstrates that the W5500 can be useful not only as a TCP/IP offload device, but also as a simple way to add wired Ethernet to an MCU while preserving the existing software architecture.

One-line presentation summary

“This project keeps the ESP32-S3's existing Wi-Fi and network software architecture, while adding W5500 to extend the device into a wired industrial gateway supporting services such as HTTP, SSH, and SNMP.”

❓ FAQ

Does this project use the W5500's hardware TCP/IP stack?

No. Here the W5500 is the network interface (MAC+PHY) and lwIP on the ESP32-S3 handles TCP/UDP. The chip's hardware-socket mode is a different integration style used by other projects.

Why not use a classic ESP32 with RMII and a LAN8720?

That is faster (near 100 Mbit) and the project says so. But the S3 — chosen for USB, AI acceleration, and PSRAM — has no RMII controller at all. The W5500 is what makes wired Ethernet possible on that chip.

Is ~8 Mbit/s enough?

For a web UI, SSH sessions, SNMP polling, and firmware-sized transfers — comfortably. The 200 MB byte-exact download shows sustained integrity. It is not a choice for bulk-data streaming.

Is the limit the W5500 or the SPI bus?

Both meet near the same point: SPI-bound up to ~24 MHz, then flattening near the W5500's internal ~8.3 Mbit/s ceiling around 30 MHz. Past ~33 MHz, SPI reads corrupt before anything improves.

한국어 — ESP32-S3에 W5500을 붙여 유선 네트워크 서비스를 구현한 사례

1. 이 프로젝트가 뭔가

ProtoCore는 ESP32에서 HTTP, SSH, SNMP, Telnet 같은 여러 표준 네트워크 서비스를 하나의 프레임워크로 제공하는 프로젝트​입니다.

쉽게 말하면 ESP32를 단순한 IoT 센서가 아니라,

Web으로 설정하고, SSH/Telnet으로 원격 관리하고, SNMP로 상태를 모니터링할 수 있는 네트워크 장비로 만들어주는 프로젝트입니다.

이 사례에서는 ESP32-S3에 W5500을 SPI로 연결하여 기존 Wi-Fi 기반 서비스를 유선 Ethernet에서도 사용할 수 있도록 확장했습니다.

2. 왜 이 프로젝트가 유용한가

일반적인 ESP32 프로젝트에서는 Web Server, 원격 관리, 모니터링 기능이 필요할 때 각각의 라이브러리와 인터페이스를 따로 구성해야 합니다.

ProtoCore는 이런 기능을 하나의 네트워크 프레임워크에서 제공합니다.

예를 들어 산업용 Gateway 하나를 만든다면,

HTTP → Web 기반 장비 설정

SSH / Telnet → 원격 유지보수

SNMP → 장비 상태 모니터링

처럼 하나의 ESP32에서 여러 관리 인터페이스를 제공할 수 있습니다.

즉, 저렴한 MCU 하나를 단순 센서 노드가 아니라 실제 네트워크 관리 기능을 갖춘 Gateway나 Controller로 확장할 수 있다는 것이 이 프로젝트의 첫 번째 의미입니다.

3. 왜 ESP32-S3에 W5500을 붙였나

ESP32-S3는 Wi-Fi 기능은 갖고 있지만 Classic ESP32와 달리 기존 RMII Ethernet MAC이 없습니다.

따라서 안정적인 유선 Ethernet이 필요한 제품에서는 별도의 Ethernet Controller가 필요합니다.

여기서 W5500은 ESP32-S3에 없는 유선 Ethernet 기능을 추가하는 역할을 합니다.

구조를 간단하게 보면,

ESP32-S3 = Application + Network Services + TCP/IP

W5500 = Wired Ethernet Interface

입니다.

따라서 ESP32-S3의 Wi-Fi 기능을 포기하지 않으면서 유선 Ethernet이라는 또 하나의 네트워크 경로를 추가할 수 있습니다.

즉, 같은 ESP32-S3 플랫폼에서 Wi-Fi와 Ethernet을 모두 활용할 수 있다는 것이 두 번째 의미입니다.

프로젝트에는 이를 뒷받침하는 전용 예제가 있습니다. NetEgress 예제에서는 Wi-Fi와 이더넷이 동시에 연결된 상태로 유지되고, 어느 쪽으로 나갈지는 esp_netif가 고른다. ProtoCore는 현재 활성 경로를
Physical.link->egress()와 /net JSON 엔드포인트로 보고하게 됩니다. README 표현 그대로 "Wi-Fi 옆에 이더넷을 연결해 두고 케이블을 뽑으면 보고되는 인터페이스가 바뀐다". 즉 유선은 Wi-Fi를 대체하는 것이 아니라, 둘 다 살아 있고 OS가 그 사이를 failover 한다.

4. 전체 구조는 어떻게 되어 있나

ProtoCore와 lwIP는 ESP32-S3에서 실행되고, W5500은 SPI로 연결된 외부 Ethernet Interface입니다.

즉 ProtoCore가 서비스를 제공하고, lwIP가 TCP/IP를 처리하고, W5500이 실제 유선 Ethernet 연결을 담당합니다.

5. 여기서 W5500을 어떻게 사용했나

이 부분이 WIZnet 관점에서 특히 중요합니다.

W5500은 원래 TCP/UDP를 칩 내부에서 처리하는 Hardware TCP/IP, 즉 TOE 기능을 가지고 있습니다.

하지만 이 프로젝트에서는 W5500의 Hardware Socket을 직접 사용하지 않습니다.

TCP/UDP는 ESP32-S3의 lwIP가 처리하고,

W5500은 SPI 기반 Ethernet Interface 역할로 사용합니다.

즉,

ProtoCore → lwIP → W5500 → Ethernet

구조입니다.

6. 왜 굳이 이런 구조를 사용했나

가장 큰 이유는 Wi-Fi와 Ethernet을 같은 네트워크 구조에서 다룰 수 있기 때문입니다.

Wi-Fi를 사용할 때도,

ProtoCore → lwIP → Wi-Fi

Ethernet을 사용할 때도,

ProtoCore → lwIP → W5500

구조가 됩니다.

따라서 ProtoCore 입장에서는 네트워크가 Wi-Fi인지 Ethernet인지에 따라 HTTP, SSH, SNMP 같은 상위 서비스를 크게 변경할 필요가 없습니다.

즉, 기존 ESP32 네트워크 소프트웨어 구조를 유지하면서 물리적인 네트워크만 Wi-Fi와 Ethernet 사이에서 선택할 수 있다는 것이 이 구조의 장점입니다.

7. 이 사례에서 W5500이 보여주는 또 다른 가치

W5500은 흔히 Hardware TCP/IP Offload 칩으로 소개됩니다.

하지만 이 프로젝트에서는 조금 다른 활용 방법을 보여줍니다.

W5500의 TOE를 반드시 사용하지 않더라도, Ethernet MAC/PHY가 없는 MCU에 SPI Ethernet을 추가하는 Network Interface로 활용할 수 있습니다.

특히 ESP32-S3처럼

• Wi-Fi
• USB
• PSRAM
• 높은 MCU 성능

등의 장점 때문에 MCU 자체를 유지하고 싶지만 유선 Ethernet도 필요한 경우 유용합니다.

즉, MCU를 Ethernet 때문에 교체하지 않고 W5500을 추가해 기존 플랫폼을 그대로 확장할 수 있다는 점이 중요한 활용 포인트입니다.

8. 실제 속도는 어느 정도인가

이 프로젝트가 유용한 또 하나의 이유는 단순히 "동작한다"에서 끝나지 않고 실제 전송 성능까지 측정했다는 점입니다.

공개된 테스트에서는 약 7~8 Mbit/s 수준의 실제 전송 성능을 확인하고 대용량 데이터 전송을 통해 데이터 무결성도 검증했습니다.

여기서 중요한 것은 W5500의 Ethernet Link 자체는 100 Mbps지만,

ESP32-S3 ↔ SPI ↔ W5500

이라는 데이터 경로 때문에 실제 애플리케이션 처리량은 훨씬 낮다는 점입니다.

따라서 W5500을 ESP32-S3의 Ethernet Interface로 사용할 때 실제 어느 정도의 성능을 기대할 수 있는지 보여주는 현실적인 Reference가 됩니다.

9. 7~8 Mbit/s면 어디에 충분한가

모든 Ethernet 애플리케이션에 100 Mbps가 필요한 것은 아닙니다.

산업용 장비에서 흔히 필요한

Web UI

SSH 원격 유지보수

SNMP Monitoring

장비 설정 및 Firmware/Data 전송

같은 관리 트래픽에서는 7~8 Mbit/s도 충분히 실용적인 범위입니다.

반대로 대용량 영상 Streaming이나 높은 Network Throughput이 중요한 장비라면 다른 Ethernet 구조를 검토해야 합니다.

즉, 이 프로젝트는 W5500의 실제 성능이 어떤 애플리케이션에 적합한지 판단할 수 있는 참고 자료라는 의미도 있습니다.

최종 정리

이 프로젝트의 핵심은 ESP32-S3에 W5500을 붙여, Wi-Fi에서 사용하던 HTTP, SSH, SNMP 같은 네트워크 서비스를 유선 Ethernet으로 확장한 것입니다.

여기서는 W5500 Hardware TCP/IP Socket을 직접 사용하는 것이 아니라, ESP32-S3의 lwIP가 TCP/IP를 처리하고 W5500은 SPI Ethernet Interface 역할을 합니다.

그리고 실제 약 7~8 Mbit/s 수준의 성능 측정을 통해, ESP32-S3 + W5500 조합이 Web UI, 원격 관리, 장비 모니터링 같은 산업용 Gateway 용도에 충분히 활용될 수 있다는 것을 보여주는 사례입니다.

❓ FAQ

이 프로젝트는 W5500의 하드웨어 TCP/IP 스택을 쓰나?

아니다. 여기서 W5500은 네트워크 인터페이스(MAC+PHY)이고 TCP/UDP는 ESP32-S3의 lwIP가 처리한다. 하드웨어 소켓 모드는 다른 프로젝트들이 쓰는 별개 통합 방식이다.

클래식 ESP32 + RMII + LAN8720을 쓰면 되지 않나?

그쪽이 빠르고(100 Mbit급) 프로젝트도 그렇게 말한다. 하지만 USB·AI 가속·PSRAM 때문에 선택되는 S3에는 RMII 컨트롤러 자체가 없다. 그 칩에서 유선을 가능하게 하는 게 W5500이다.

~8 Mbit/s면 충분한가?

웹 UI, SSH 세션, SNMP 폴링, 펌웨어 크기 전송에는 넉넉하다. 200 MB byte-exact 다운로드가 지속 무결성을 보여준다. 대용량 스트리밍용 선택지는 아니다.

한계는 W5500인가 SPI인가?

거의 같은 지점에서 만난다: ~24 MHz까지는 SPI 병목, 30 MHz 부근에서 W5500 내부 한계 ~8.3 Mbit/s에서 포화. ~33 MHz를 넘으면 개선 전에 SPI 읽기가 먼저 깨진다.

Documents

• ProtoCore repository: github.com/dstroy0/ProtoCore
• EthernetW5500 example: examples/Peripherals/EthernetW5500
• ProtoCore docs: dstroy0.github.io/ProtoCore
• W5500 product page: https://wiznet.io/products/ethernet-chips/w5500
• arduino-esp32 ETH (3.x): github.com/espressif/arduino-esp32
• NetEgress example: https://github.com/dstroy0/ProtoCore/tree/main/examples/L7-Application/NetEgress