---
title: "ProtoCore"
url: "https://maker.wiznet.io/TheoIm/projects/protocore/"
markdown_url: "https://maker.wiznet.io/TheoIm/projects/protocore/md"
type: "UCC: User Created Content"
author: "dstroy0"
author_url: "https://github.com/dstroy0/ProtoCore"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "dstroy0"
original_url: "https://github.com/dstroy0/ProtoCore"
published: "2026-07-31"
language: "en"
hardware: ["WIZnet W5500"]
likes: 0
views: 204
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# ProtoCore

> ProtoCore runs multiple network services on ESP32-S3 via W5500, reaching ~8.2 Mbit/s over SPI with verified large-file transfers.

Original author: dstroy0 (source: https://github.com/dstroy0/ProtoCore)

## Components

- **WIZnet W5500** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5500))

WIZnet parts: W5500 ([Datasheet](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/datasheet?utm_source=maker&utm_medium=project&utm_campaign=w5500), [product hub](https://maker.wiznet.io/products/w5500/))

## Article

## 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 configurationSSH / Telnet → Remote maintenanceSNMP → 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 configurationSSH / Telnet → Remote maintenanceSNMP → Device status monitoringThis 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/IPW5500 = 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?

![](https://maker.wiznet.io/upload/ckeditor5/387798757%5F1787071099%2Epng)

**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 UISSH remote maintenanceSNMP monitoringConfiguration 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:

```plaintext
                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/IPW5500 = 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. 전체 구조는 어떻게 되어 있나

![](https://maker.wiznet.io/upload/ckeditor5/387798757%5F1787071076%2Epng)

**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 UISSH 원격 유지보수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](https://github.com/dstroy0/ProtoCore)

- EthernetW5500 example: [examples/Peripherals/EthernetW5500](https://github.com/dstroy0/ProtoCore/tree/main/examples/Peripherals/EthernetW5500)

- ProtoCore docs: [dstroy0.github.io/ProtoCore](https://dstroy0.github.io/ProtoCore/)

- W5500 product page: <https://wiznet.io/products/ethernet-chips/w5500>

- arduino-esp32 ETH (3.x): [github.com/espressif/arduino-esp32](https://github.com/espressif/arduino-esp32)

- NetEgress example:<https://github.com/dstroy0/ProtoCore/tree/main/examples/L7-Application/NetEgress>

#W5500 #ESP32-S3 #EthernetHTTP #SSH #Telnet #SNMP

---

Source: https://maker.wiznet.io/TheoIm/projects/protocore/