---
title: "esp32-w5500-ethercat-slave"
url: "https://maker.wiznet.io/Lihan__/projects/esp32-w5500-ethercat-slave/"
markdown_url: "https://maker.wiznet.io/Lihan__/projects/esp32-w5500-ethercat-slave/md"
type: "UCC: User Created Content"
author: "SaiSriHarshaPedda"
author_url: "https://github.com/SaiSriHarshaPedda/esp32-w5500-ethercat-slave"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "SaiSriHarshaPedda"
original_url: "https://github.com/SaiSriHarshaPedda/esp32-w5500-ethercat-slave"
published: "2026-06-15"
language: "en"
likes: 0
views: 276
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# esp32-w5500-ethercat-slave

> A from-scratch software EtherCAT slave running on an ESP32-WROOM-32 with a WIZnet W5500 Ethernet controller over SPI.

Original author: SaiSriHarshaPedda (source: https://github.com/SaiSriHarshaPedda/esp32-w5500-ethercat-slave)

## Article

## A Software EtherCAT Slave on a $5 ESP32 — Spoken Fluently to a Real Beckhoff TwinCAT 3 Master, Over a W5500 in MACRAW

`#EtherCAT` `#IndustrialFieldbus` `#TwinCAT3` `#SoftwareESC` `#MACRAW` `#ESP32` `#FactoryAutomation` `#FMMU` `#ProofOfConcept` `#PromiscuousCapture`

> 📚 Hobby / educational proof-of-concept — independent implementation, verified against a real Beckhoff TwinCAT 3 master ✅ Verified: device enumerates in TwinCAT as `ESP32-DO8`, climbs INIT → PreOp → SafeOp → OP, Working Counter valid, 8 GPIO outputs driven live from the master

---

### 01 — What is this project?

EtherCAT is the high-speed fieldbus that runs a huge share of the world's factory automation — robot cells, CNC machines, motion control. But getting *onto* an EtherCAT network as a slave device normally means buying a dedicated **EtherCAT Slave Controller (ESC)** chip like the Beckhoff ET1100 or Microchip LAN9252. That hardware, and the documentation behind it, is a wall between a curious engineer and the protocol.

This project knocks a hole in that wall. It implements an **EtherCAT slave entirely in software** on a plain ESP32-WROOM-32, using a **WIZnet W5500** as the raw Ethernet front end. The firmware emulates an ESC from scratch — datagram parsing, the register file, Working Counter arithmetic, the AL state machine, SII EEPROM emulation, and FMMU process-data mapping — and it's not a simulation: it was **built up in four layers, each one verified against a real Beckhoff TwinCAT 3 master before the next was added.**

The reference application is deliberately simple so the protocol is the star: tick a checkbox in TwinCAT, and a physical GPIO on the ESP32 goes high. Eight digital outputs, mapped through real FMMU logical addressing, driven live from an industrial PLC master over a commodity Ethernet chip.

### 02 — Why software EtherCAT (and where it stops)?

#### 🔷 The honesty is the feature

This curation usually celebrates capability. Here, the *limitations section* is what earns trust. The author is explicit: the W5500 is a **store-and-forward** chip, so this slave is a **stable but slow node (~5–10 ms cycle times)**. It **cannot** do Distributed Clocks (DC) or sub-millisecond cycles — that genuinely requires a hardware ESC like the LAN9252. The Vendor ID is a placeholder (`0x0000DEAD`), valid for the lab, not for production interoperability. Nothing is oversold. For a learning artifact about a notoriously opaque protocol, that candor is exactly what makes it useful.

#### 🔷 A learning ladder for an opaque protocol

The architecture doc walks the ESC emulation as four verified layers: W5500 MACRAW transport → datagram parser + Working Counter + AL FSM → SII/EEPROM identity handshake → FMMU logical-to-physical mapping. Each layer is the smallest thing that TwinCAT will accept before moving on. That's a roadmap anyone can follow to actually understand EtherCAT, not just use it.

#### 🔷 A portable protocol core

The cleanest design decision: the EtherCAT logic (`ecat.c`, `sii.c`, the ESI file) is independent of transport. The author notes that porting to a real LAN9252 for DC-capable timing changes only the W5500 transport layer — the protocol brain carries over. The W5500 is what makes the *learning* version cheap and accessible.

### 03 — System architecture

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

### 04 — Why W5500? ⭐

#### 🔷 Mode: MACRAW, promiscuous — verified in code

This is the heart of why the W5500 fits. An EtherCAT slave must see **every frame on the wire**, not just frames addressed to its IP — because EtherCAT doesn't use IP at all; the master sweeps datagrams past every node. The W5500's **MACRAW socket mode (**`**Sn_MR_MACRAW**`**, **`**0x04**`**)** does exactly that: raw Layer-2 Ethernet frames, no TCP/IP stack in the way. The firmware opens socket 0 in MACRAW with the **MAC filter bit cleared (promiscuous)**, so the ESP32 captures all of the master's EtherCAT traffic:

c

```c
/* MACRAW mode.  MF (bit 7) cleared => promiscuous: capture ALL frames. */ w5500_wr8(W5500_BSB_S0_REG, W5500_Sn_MR, W5500_MR_MACRAW); socket_cmd(W5500_CMD_OPEN); /* verifies Sn_SR == 0x42 (SOCK_MACRAW) before proceeding */
```

This is the rare project where the W5500 is used **not** for its famous hardware TCP/IP offload (TOE), but for the opposite: getting completely *out of the way* and handing the CPU raw frames. The same chip that's usually prized for doing the network stack *for* you is here prized for **not** doing it — pure L2 access is exactly what a fieldbus needs.

#### 🔷 Why a $5 SPI chip beats a dedicated ESC for learning

A real ESC (ET1100/LAN9252) is a specialized, harder-to-source part with its own steep documentation. The W5500 is cheap, ubiquitous, 3.3 V, and speaks SPI to any MCU. By choosing MACRAW + promiscuous capture, the author turned a commodity Ethernet chip into the physical layer of an industrial fieldbus node — the entry barrier collapses from "buy and learn an ESC" to "wire up a W5500 you probably already own."

#### 🔷 The honest trade-off, stated by the hardware itself

The W5500 is store-and-forward: a frame is fully received into the buffer before the CPU sees it, then fully sent back. That's why DC and sub-ms cycles are off the table — and why the author is upfront about ~5–10 ms operation. The chip's nature *defines* the project's scope, and the project documents it precisely rather than hiding it.

#### 🔷 Verified evidence ✅

- Boot log confirms the chip: `VERSIONR = 0x04`, socket reaches `Sn_SR = 0x42` (SOCK_MACRAW)

- TwinCAT enumerates the device by name (`ESP32-DO8`) via the standard SII/EEPROM identity handshake

- AL state machine climbs all the way to **OP** (`AL state -> 0x08`)

- `WcState = 0` in TwinCAT confirms the Working Counter is being incremented correctly

- Writing an output bit in TwinCAT drives the matching physical GPIO high — closed-loop, master-to-pin

### 05 — Key components

#### 🌐 WIZnet W5500 — MACRAW (promiscuous) raw-Ethernet front end

Socket 0 opened in `Sn_MR_MACRAW` with MAC filter disabled; 16 KB RX/TX buffer assigned to the single socket. Native ESP-IDF SPI master driver (no Arduino), VSPI pins, manual CS so each `[addr-hi][addr-lo][control][data]` frame is atomic. Handles the MACRAW RX quirk where the 2-byte big-endian length header includes itself.

#### 🧠 ESP32-WROOM-32 (original, not S3)

`net_task` pinned to **CPU1** in a busy-poll loop to keep frame turnaround tight and the EtherCAT link stable; CPU0 left for system housekeeping.

#### ⚙️ Software ESC core (`ecat.c`, 338 lines)

Datagram parser for all four EtherCAT addressing modes (auto-increment `AP*`, configured `FP*`, broadcast `B*`, logical `L*`), correct Working Counter rules, AL finite state machine, and FMMU logical→physical mapping into process RAM that drives the GPIOs.

#### 💾 SII EEPROM emulation (`sii.c`)

Emulates the ESC EEPROM register interface with CRC8 so the master reads device identity through the exact standard handshake — including a custom 16×14 device icon embedded in the ESI.

#### 📄 ESI device description (`esi/ESP32_DO8.xml`)

Installed on the TwinCAT side so the slave appears as a named device with its 8-output I/O map.

### 06 — Application scenarios

#### 01. Hands-on EtherCAT education

The intended use: a cheap, fully-documented, layer-by-layer way to actually learn how an EtherCAT slave talks to a master — without buying ESC silicon.

#### 02. Rapid fieldbus prototyping

Need a throwaway EtherCAT I/O node on the bench to test a master configuration or an ESI file? An ESP32 + W5500 stands in for a real slave at relaxed cycle times.

#### 03. Bridge to production via LAN9252

Because the protocol core is transport-independent, this is a natural first step before committing to a DC-capable LAN9252 design — the `ecat.c`/`sii.c`/ESI work carries straight over.

#### 04. Teaching MACRAW itself

A clean, real-world reference for using the W5500 in promiscuous MACRAW mode — useful to anyone building packet sniffers, custom L2 protocols, or fieldbus front ends on the same chip.

### Conclusion

> **An industrial EtherCAT slave, emulated in firmware on a hobby-grade ESP32, made possible because the W5500 will — when asked — stop being a TCP/IP chip and just hand you raw Ethernet frames.**

- ✅ Full software ESC: datagram parser, Working Counter, AL FSM, SII EEPROM, FMMU

- ✅ Verified against a real Beckhoff TwinCAT 3 master — climbs to OP, drives live I/O

- ✅ W5500 in MACRAW promiscuous mode (`Sn_MR=0x04`, `Sn_SR=0x42`) confirmed in code and boot log

- ✅ Transport-independent protocol core — portable to a LAN9252 for DC-capable timing

- ✅ Honest, precise limitations (store-and-forward → ~5–10 ms, no DC) that make it trustworthy as a learning artifact

- ✅ Complete docs: wiring map, layer-by-layer architecture, TwinCAT setup walkthrough

From hardware TCP/IP offload to **raw Layer-2 industrial fieldbus access** — the W5500 turns up wherever Ethernet needs to happen, even inside an EtherCAT node where its usual headline feature is deliberately switched off. The most surprising use of a TOE chip is the one that doesn't use TOE at all.

### Q&A

**Q. Which W5500 socket mode does this use, and why not TOE?** MACRAW (`Sn_MR_MACRAW`, value `0x04`), with the MAC filter disabled for promiscuous capture — verified directly in `w5500.c`. EtherCAT runs on raw Layer-2 Ethernet with no IP, and the master's datagrams sweep past every node, so the slave must capture *all* frames. The W5500's hardware TCP/IP (TOE) would actively get in the way; MACRAW is the only correct choice here.

**Q. Is it real or simulated?** Real, on hardware. The boot log reads back the W5500 `VERSIONR` and MACRAW socket status, and the device enumerates and reaches OP under an actual TwinCAT 3 master driving physical GPIOs. It is, by the author's own framing, a proof-of-concept — not a certified product.

**Q. Why can't it do hard real-time EtherCAT?** Because the W5500 is store-and-forward: frames are buffered in full before the CPU sees them and before they're sent back, which precludes Distributed Clocks and sub-millisecond cycles. That's an inherent property of the chip, and the project is explicit about it (~5–10 ms cycle times). For DC-capable timing the author points to a LAN9252 port, reusing the same protocol code.

**Q. Is the code complete and buildable?** Yes. ESP-IDF project (developed on v6.0.1) with `CMakeLists.txt`, `sdkconfig.defaults`, full `main/` sources (W5500 driver, ESC core, SII emulation), the ESI file, plus `WIRING.md` and `ARCHITECTURE.md`. Build/flash/monitor steps and the complete TwinCAT setup are documented.

---

---

## 5천 원짜리 ESP32 위에 구현한 소프트웨어 EtherCAT 슬레이브 — W5500의 MACRAW로 진짜 Beckhoff TwinCAT 3 마스터와 대화하다

`#EtherCAT` `#산업용필드버스` `#TwinCAT3` `#소프트웨어ESC` `#MACRAW` `#ESP32` `#공장자동화` `#FMMU` `#개념검증` `#프로미스큐어스캡처`

> 📚 취미/교육용 개념검증(PoC) — 독립 구현, 실제 Beckhoff TwinCAT 3 마스터로 검증 ✅ 검증됨: TwinCAT에서 `ESP32-DO8`로 인식, INIT→PreOp→SafeOp→OP 단계 진입, Working Counter 정상, 마스터에서 GPIO 8채널 실시간 구동

---

### 01 — 어떤 프로젝트인가?

EtherCAT은 전 세계 공장 자동화의 상당 부분 — 로봇 셀, CNC 공작기계, 모션 제어 — 을 돌리는 고속 필드버스다. 그런데 슬레이브 장치로 EtherCAT 네트워크에 *올라타려면* 보통 Beckhoff ET1100이나 Microchip LAN9252 같은 전용 **EtherCAT 슬레이브 컨트롤러(ESC)** 칩을 사야 한다. 그 하드웨어와 그 뒤에 숨은 방대한 문서가, 호기심 많은 엔지니어와 이 프로토콜 사이를 가로막는 벽이다.

이 프로젝트는 그 벽에 구멍을 낸다. 평범한 ESP32-WROOM-32 위에서 **EtherCAT 슬레이브를 순수 소프트웨어로 구현**하고, **WIZnet W5500**을 생(raw) 이더넷 프런트엔드로 쓴다. 펌웨어가 ESC를 밑바닥부터 에뮬레이션한다 — 데이터그램 파싱, 레지스터 파일, Working Counter 연산, AL 상태머신, SII EEPROM 에뮬레이션, FMMU 프로세스 데이터 매핑까지. 그리고 시뮬레이션이 아니다: **네 개의 계층으로 쌓아 올리되, 각 계층을 실제 Beckhoff TwinCAT 3 마스터로 검증한 뒤에야 다음 계층을 올렸다.**

레퍼런스 애플리케이션은 일부러 단순하게 만들어 프로토콜이 주인공이 되게 했다: TwinCAT에서 체크박스 하나를 켜면 ESP32의 물리 GPIO 핀이 High로 올라간다. 진짜 FMMU 논리 주소지정을 거친 디지털 출력 8채널을, 산업용 PLC 마스터가 범용 이더넷 칩 너머로 실시간 구동한다.

### 02 — 왜 소프트웨어 EtherCAT인가 (그리고 어디서 멈추는가)?

#### 🔷 솔직함이 곧 강점이다

이 큐레이션은 보통 "할 수 있는 것"을 칭송한다. 그런데 이 프로젝트는 *한계 섹션*이 신뢰를 만든다. 저자는 분명히 못 박는다: W5500은 **store-and-forward** 칩이라 이 슬레이브는 **안정적이지만 느린 노드(약 5~10 ms 사이클)**라고. Distributed Clocks(DC)나 sub-ms 사이클은 **불가능**하며, 그건 LAN9252 같은 하드웨어 ESC가 있어야 한다. Vendor ID는 플레이스홀더(`0x0000DEAD`)로 실험실용일 뿐 양산 상호운용에는 못 쓴다. 무엇 하나 과장하지 않는다. 악명 높게 불투명한 프로토콜을 배우는 학습 자료로서, 이 솔직함이야말로 이 프로젝트를 쓸모 있게 만든다.

#### 🔷 불투명한 프로토콜을 위한 학습 사다리

아키텍처 문서는 ESC 에뮬레이션을 검증된 4계층으로 풀어낸다: W5500 MACRAW 전송 → 데이터그램 파서 + Working Counter + AL FSM → SII/EEPROM 신원 핸드셰이크 → FMMU 논리-물리 매핑. 각 계층은 TwinCAT이 받아들이는 "다음으로 넘어가기 위한 최소 단위"다. EtherCAT을 그냥 *쓰는* 게 아니라 *이해하려는* 누구나 따라갈 수 있는 로드맵이다.

#### 🔷 이식 가능한 프로토콜 코어

가장 깔끔한 설계 판단: EtherCAT 로직(`ecat.c`, `sii.c`, ESI 파일)이 전송 계층과 독립적이라는 점이다. 저자는 DC 가능한 타이밍을 위해 실제 LAN9252로 포팅할 때 바뀌는 건 W5500 전송 계층뿐이고 프로토콜 두뇌는 그대로 넘어간다고 짚는다. W5500은 *학습용* 버전을 싸고 접근 가능하게 만드는 역할이다.

### 03 — 시스템 아키텍처

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

### 04 — 왜 W5500인가? ⭐

#### 🔷 모드: MACRAW, 프로미스큐어스 — 코드로 검증됨

W5500이 들어맞는 이유의 핵심이 여기다. EtherCAT 슬레이브는 자기 IP로 온 프레임만이 아니라 **회선의 모든 프레임**을 봐야 한다 — EtherCAT은 애초에 IP를 쓰지 않고, 마스터가 데이터그램을 모든 노드에 훑고 지나가기 때문이다. W5500의 **MACRAW 소켓 모드(`Sn_MR_MACRAW`, `0x04`)**가 바로 그 일을 한다: TCP/IP 스택이 끼어들지 않는 생 L2 이더넷 프레임. 펌웨어는 소켓 0을 MACRAW로 열되 **MAC 필터 비트를 끈(프로미스큐어스)** 상태로 두어, ESP32가 마스터의 모든 EtherCAT 트래픽을 캡처한다:

c

```c
/* MACRAW mode.  MF(bit 7) clear => promiscuous: 모든 프레임 캡처 */ w5500_wr8(W5500_BSB_S0_REG, W5500_Sn_MR, W5500_MR_MACRAW); socket_cmd(W5500_CMD_OPEN); /* 진행 전에 Sn_SR == 0x42(SOCK_MACRAW) 확인 */
```

이 프로젝트는 W5500을 그 유명한 하드웨어 TCP/IP 오프로드(TOE)로 쓰는 게 **아니라**, 정반대로 — 완전히 *비켜서서* CPU에 생 프레임을 넘기는 용도로 쓰는 드문 사례다. 보통은 네트워크 스택을 *대신 처리해줘서* 칭송받는 바로 그 칩이, 여기서는 **그 일을 안 해주기 때문에** 가치가 있다. 순수 L2 접근 — 그것이 필드버스가 필요로 하는 전부다.

#### 🔷 왜 학습용으로는 5천 원짜리 SPI 칩이 전용 ESC를 이기는가

실제 ESC(ET1100/LAN9252)는 구하기 어렵고 자체 문서도 가파른 특수 부품이다. W5500은 싸고, 어디에나 있고, 3.3 V이며, 어떤 MCU와도 SPI로 대화한다. MACRAW + 프로미스큐어스 캡처를 선택함으로써, 저자는 범용 이더넷 칩을 산업용 필드버스 노드의 물리 계층으로 바꿔놓았다. 진입 장벽이 "ESC를 사서 익혀라"에서 "이미 갖고 있을 W5500을 연결하라"로 무너진다.

#### 🔷 하드웨어 스스로가 말하는 솔직한 트레이드오프

W5500은 store-and-forward다: 프레임을 버퍼에 완전히 받은 뒤에야 CPU가 보고, 완전히 받은 뒤에야 회신한다. 그래서 DC와 sub-ms 사이클은 불가능하고, 저자가 약 5~10 ms 동작이라고 미리 밝히는 이유도 그것이다. 칩의 본성이 프로젝트의 범위를 *정의*하며, 프로젝트는 그것을 숨기지 않고 정확히 문서화한다.

#### 🔷 검증된 증거 ✅

- 부팅 로그가 칩을 확인: `VERSIONR = 0x04`, 소켓이 `Sn_SR = 0x42`(SOCK_MACRAW) 도달

- TwinCAT이 표준 SII/EEPROM 신원 핸드셰이크로 장치를 이름(`ESP32-DO8`)으로 인식

- AL 상태머신이 **OP**까지 진입 (`AL state -> 0x08`)

- TwinCAT의 `WcState = 0`이 Working Counter가 정상 증가함을 확인

- TwinCAT에서 출력 비트를 쓰면 해당 물리 GPIO가 High로 — 마스터에서 핀까지 폐루프

### 05 — 핵심 구성요소

#### 🌐 WIZnet W5500 — MACRAW(프로미스큐어스) 생 이더넷 프런트엔드

소켓 0을 `Sn_MR_MACRAW`로 열고 MAC 필터 비활성화, 단일 소켓에 16 KB RX/TX 버퍼 할당. 네이티브 ESP-IDF SPI 마스터 드라이버(Arduino 미사용), VSPI 핀, 수동 CS로 `[주소상위][주소하위][제어][데이터]` 프레임을 원자적으로 전송. 2바이트 빅엔디언 길이 헤더가 자기 자신을 포함하는 MACRAW RX 특유의 함정도 처리.

#### 🧠 ESP32-WROOM-32 (S3 아님, 오리지널)

`net_task`를 **CPU1**에 고정해 busy-poll 루프로 돌려 프레임 왕복을 촘촘히 유지하고 EtherCAT 링크를 안정화; CPU0는 시스템 작업용.

#### ⚙️ 소프트웨어 ESC 코어 (`ecat.c`, 338줄)

EtherCAT 4가지 주소지정 모드(자동증가 `AP*`, 설정 `FP*`, 브로드캐스트 `B*`, 논리 `L*`) 데이터그램 파서, 올바른 Working Counter 규칙, AL 유한상태머신, 프로세스 RAM으로의 FMMU 논리→물리 매핑(이게 GPIO를 구동).

#### 💾 SII EEPROM 에뮬레이션 (`sii.c`)

ESC EEPROM 레지스터 인터페이스를 CRC8과 함께 에뮬레이션해 마스터가 정확히 표준 핸드셰이크로 장치 신원을 읽게 함 — ESI에 임베드한 커스텀 16×14 장치 아이콘 포함.

#### 📄 ESI 장치 기술서 (`esi/ESP32_DO8.xml`)

TwinCAT 측에 설치해 슬레이브가 8출력 I/O 맵을 가진 이름 있는 장치로 나타나게 함.

### 06 — 응용 시나리오

#### 01. 실습형 EtherCAT 교육

의도된 용도: ESC 실리콘을 사지 않고도, EtherCAT 슬레이브가 마스터와 어떻게 대화하는지 계층별로 실제로 배우는 싸고 완전히 문서화된 방법.

#### 02. 빠른 필드버스 프로토타이핑

마스터 설정이나 ESI 파일을 테스트하려고 벤치에 버려도 되는 EtherCAT I/O 노드가 필요할 때, ESP32 + W5500이 완화된 사이클 타임에서 실제 슬레이브를 대신한다.

#### 03. LAN9252를 향한 양산 디딤돌

프로토콜 코어가 전송 독립적이라, DC 가능한 LAN9252 설계로 넘어가기 전 자연스러운 첫걸음이다 — `ecat.c`/`sii.c`/ESI 작업이 그대로 넘어간다.

#### 04. MACRAW 그 자체의 교본

W5500을 프로미스큐어스 MACRAW 모드로 쓰는 깔끔한 실전 레퍼런스 — 같은 칩으로 패킷 스니퍼, 커스텀 L2 프로토콜, 필드버스 프런트엔드를 만드는 누구에게나 유용.

### 결론

> **취미용 ESP32 위에 펌웨어로 에뮬레이션한 산업용 EtherCAT 슬레이브 — W5500이 부탁받으면 TCP/IP 칩이기를 멈추고 그냥 생 이더넷 프레임을 건네주기 때문에 가능했다.**

- ✅ 완전한 소프트웨어 ESC: 데이터그램 파서, Working Counter, AL FSM, SII EEPROM, FMMU

- ✅ 실제 Beckhoff TwinCAT 3 마스터로 검증 — OP까지 진입, 실시간 I/O 구동

- ✅ W5500 MACRAW 프로미스큐어스 모드(`Sn_MR=0x04`, `Sn_SR=0x42`) 코드·부팅 로그로 확인

- ✅ 전송 독립적 프로토콜 코어 — DC 가능 타이밍을 위해 LAN9252로 이식 가능

- ✅ 솔직하고 정확한 한계 명시(store-and-forward → 약 5~10 ms, DC 불가)가 학습 자료로서의 신뢰를 만듦

- ✅ 완비된 문서: 배선도, 계층별 아키텍처, TwinCAT 설정 가이드

하드웨어 TCP/IP 오프로드에서 **생 L2 산업용 필드버스 접근**까지 — W5500은 이더넷이 필요한 곳이라면 어디든, 심지어 자기 간판 기능을 일부러 끈 EtherCAT 노드 안에서도 모습을 드러낸다. TOE 칩의 가장 의외의 활용은, TOE를 전혀 쓰지 않는 활용이다.

### Q&A

**Q. W5500의 어떤 소켓 모드를 쓰며, 왜 TOE가 아닌가요?** MACRAW(`Sn_MR_MACRAW`, 값 `0x04`), MAC 필터를 끈 프로미스큐어스 캡처입니다 — `w5500.c`에서 직접 확인됩니다. EtherCAT은 IP 없는 생 L2 이더넷으로 동작하고 마스터의 데이터그램이 모든 노드를 훑고 지나가므로, 슬레이브는 *모든* 프레임을 캡처해야 합니다. W5500의 하드웨어 TCP/IP(TOE)는 오히려 방해가 되며, 여기서는 MACRAW가 유일하게 올바른 선택입니다.

**Q. 실제인가요, 시뮬레이션인가요?** 하드웨어 상의 실제입니다. 부팅 로그가 W5500 `VERSIONR`과 MACRAW 소켓 상태를 읽어 확인하고, 실제 TwinCAT 3 마스터 아래에서 장치가 인식되어 OP에 도달하며 물리 GPIO를 구동합니다. 저자 스스로의 표현대로 개념검증이며 인증 제품은 아닙니다.

**Q. 왜 하드 리얼타임 EtherCAT은 안 되나요?** W5500이 store-and-forward이기 때문입니다: 프레임을 CPU가 보기 전에, 그리고 회신하기 전에 버퍼에 완전히 받아야 하므로 Distributed Clocks와 sub-ms 사이클이 불가능합니다. 이는 칩 고유의 특성이고, 프로젝트는 이를 명확히(약 5~10 ms 사이클) 밝힙니다. DC 가능 타이밍은 동일 프로토콜 코드를 재사용하는 LAN9252 포팅으로 안내합니다.

**Q. 코드는 완전하고 빌드 가능한가요?** 네. ESP-IDF 프로젝트(v6.0.1에서 개발)로 `CMakeLists.txt`, `sdkconfig.defaults`, 완전한 `main/` 소스(W5500 드라이버, ESC 코어, SII 에뮬레이션), ESI 파일, 그리고 `WIRING.md`·`ARCHITECTURE.md`를 갖췄습니다. 빌드/플래시/모니터 절차와 전체 TwinCAT 설정이 문서화되어 있습니다.

---

Source: https://maker.wiznet.io/Lihan__/projects/esp32-w5500-ethercat-slave/