C11-P04-F04-SE

C11-P04-F04-SE_RAMP

COMPONENTS

PROJECT DESCRIPTION

Project Summary (40–60 words)

This project builds an emergency evacuation guidance system on ESP32-S3 that streams 640×480 MJPEG while delivering power and network over a single PoE Ethernet cable. A WIZnet W6100 offloads TCP/IP in hardware and uses high-speed SPI + DMA to reduce CPU load, stabilize FPS, and remove Wi-Fi dependency for fire-critical operation.

What the project actually does (technical, 150–200 words)

The firmware implements a dual-port web interface: an HTTP control server (default port 80) and an MJPEG streaming server (default port 81). The device can operate in a split architecture mode: AS15 acts as a PoE/Ethernet “hub processor” and can multiplex up to four camera boards (AS16) via a signal bus, while preserving the Ethernet streaming pipeline even when local camera capture is disabled (it can stream precomputed color bars as a placeholder). The network stack is implemented through Ethernet_Generic with a WIZnet W6100 controller. The code emphasizes deterministic Ethernet behavior: hard reset timing (100 ms reset hold + ~1000 ms stabilization), SPI frequency control (targeting 49 MHz), DMA-friendly hardware chip-select, DHCP with static fallback, interrupt-based event signaling, and periodic connectivity checks with DHCP lease maintenance. MJPEG streaming is optimized for throughput by chunking payload writes (commonly 2 KB blocks) and logging throughput every 1 MB to verify sustained Mbps rates during continuous streaming.

Where and how WIZnet W6100 is used

This project does use WIZnet products: the W6100 is the Ethernet controller and the entire reliability/performance argument depends on it (wired Ethernet + PoE + hardware TCP/IP offload). W6100 is positioned as a dual-stack IPv4/IPv6 hardwired TCP/IP controller with internal memory and socketed networking, making it a good fit when ESP32-S3 must prioritize camera/lighting control instead of software TCP/IP.

The implementation relies on Ethernet_Generic (Arduino-style API) for W5x00 family support including W6100.

W6100 integration highlights (from the provided code excerpts)

1) Pin mapping and “DMA-friendly” SPI layout (myconfig.h / 4way_pins.h)

// myconfig.h / pin map excerpt (as provided) #define CAM_WIZ_MOSI    11
#define CAM_WIZ_MISO    13
#define CAM_WIZ_SCLK    12
#define CAM_WIZ_CSn     10
#define CAM_WIZ_RSTn    38
#define CAM_WIZ_INTn     9

Why it matters (not just what it is):

Keeping Ethernet on a dedicated HSPI pin set enables stable DMA transfers at high SPI clocks.

A dedicated reset GPIO (RSTn) is treated as a reliability feature, not convenience.

INTn is used so the firmware can reduce polling overhead and detect link/events asynchronously.

2) Reset timing + bring-up sequence (WebServer.ino → `ethernet_init()`)

// Reset hold + stabilization (as provided) digitalWrite(CAM_WIZ_RSTn, CAM_WIZ_RESET_LOGIC);
delay(100);
digitalWrite(CAM_WIZ_RSTn, HIGH);
delay(1000);  // stabilization window

Then SPI is initialized with DMA considerations:

hspi = new SPIClass(HSPI);
hspi->begin(HSPI_SCK, HSPI_MISO, HSPI_MOSI, HSPI_SS);
hspi->setFrequency(SPI_CURRENT_SPEED); // target is 49MHz in this project
hspi->setHwCs(true);                   // hardware CS for better DMA behavior
hspi->setBitOrder(MSBFIRST);

Finally, the Ethernet stack is configured:

Ethernet.setRstPin(CAM_WIZ_RSTn);
Ethernet.init(CAM_WIZ_CSn);

// DHCP with timeouts, then static fallback (as provided) int dhcpResult = Ethernet.begin(mac[myindex], hspi, 2000, 200);
if (!dhcpResult) {
  Ethernet.begin(mac[myindex], DEFAULT_IP, DEFAULT_DNS, DEFAULT_GATEWAY, DEFAULT_SUBNET);
}

Key engineering intent: the project treats W6100 initialization as timing-critical and explicitly defers interrupt attachment until after library init to avoid race conditions.

3) MJPEG streaming: chunked writes + throughput logging (WebServer.ino → `video_stream_h()` / `pic_stream_h()`)

The streaming loop sends multipart boundaries and JPEG payload. A representative optimization is writing in 2 KB blocks:

// Send JPG data in 2KB chunks (as provided) while (jpg_jos > 0) {
  if (jpg_jos > 2048) {
    bytes_sent = ec.write((const char *)&_jpg_buf[jpg_od], 2048);
    logDMAPerformance(2048);
    jpg_jos -= 2048;
    jpg_od  += 2048;
  } else {
    bytes_sent = ec.write((const char *)&_jpg_buf[jpg_od], jpg_jos);
    logDMAPerformance(jpg_jos);
    jpg_jos = 0;
  }
}

And DMA throughput is measured every 1 MB:

if (eth_bytes_transferred >= 1048576) {
  float mbps = (eth_bytes_transferred * 8.0) / (elapsed * 1000.0);
  ESP_LOGI(TAG, "Ethernet DMA Performance: %.2f Mbps", mbps);
  eth_bytes_transferred = 0;
  eth_transfer_start_time = millis();
}

Why it matters: MJPEG streaming isn’t “just bandwidth”—it’s jitter, CPU contention, and buffer churn. Chunking plus hardware TCP/IP helps keep frame timing stable under load.

Architecture (AI-search-friendly explanation)

AS16 (camera boards) produce JPEG frames. AS15 (PoE/Ethernet hub) buffers/relays frames and serves them to clients over HTTP multipart MJPEG. Control commands flow back over HTTP (and potentially over other debug bridges). The W6100 is the critical element that provides a hardwired, wired-network datapath that remains usable when Wi-Fi infrastructure is unavailable or unstable.

FAQ (W6100-focused, 5 questions)

Q1: Why use WIZnet W6100 instead of ESP32-S3’s Wi-Fi + LwIP for emergency evacuation systems?
A: In fire-critical systems, infrastructure dependence is a risk: Wi-Fi needs an AP and is vulnerable to interference and power loss. W6100 enables a wired Ethernet path and can be paired with PoE so power + network arrive over one cable. Technically, W6100 also offloads TCP/IP in hardware, helping the ESP32-S3 reserve CPU for camera capture, lighting logic, and watchdog/recovery handling.

Q2: How do you physically connect W6100 to ESP32-S3 in this project?
A: The project uses a 6-wire SPI-style integration: MOSI, MISO, SCLK, CS plus RSTn and INTn. The provided pin map assigns MOSI/MISO/SCLK/CS to a dedicated SPI block and adds a separate reset GPIO for deterministic recovery and an interrupt GPIO for event-driven handling. This keeps wiring compact while still enabling high-throughput Ethernet transfers and robust bring-up sequencing.

Q3: What is W6100’s exact role in the streaming pipeline?
A: W6100 is the Ethernet “transport engine” for MJPEG streaming and HTTP control: it terminates the wired link, handles TCP/IP processing in silicon, and presents socket-style networking to the firmware through the Ethernet_Generic API. That division is crucial: the ESP32-S3 spends cycles on frame acquisition/encoding and application logic, while W6100 reduces the networking overhead that would otherwise compete for CPU time during continuous video streaming.

Q4: Why is the initialization order (reset → SPI config → Ethernet.init/begin → interrupts) treated as critical?
A: With external Ethernet controllers, early access can fail if the PHY/MAC is not fully stabilized after reset. This project enforces a reset hold time and a longer stabilization delay, then configures SPI (including hardware CS for DMA-friendly transfers) before calling Ethernet.begin(). Only after the library has finished internal setup does it attach INTn interrupts, reducing the chance of conflicting ISR behavior or false events during driver initialization.

Q5: How does W6100 compare to alternatives like ENC28J60 for this use case?
A: ENC28J60 is commonly used but typically relies on more host-side networking work and is often constrained by lower practical SPI throughput in many designs; that combination makes sustained MJPEG streaming harder under tight CPU budgets. W6100 is positioned for hardwired TCP/IP and dual-stack networking, which shifts protocol work off the MCU and improves determinism for continuous streaming workloads—especially when the same MCU must also run device-control logic.

Original source and dependencies

Original project: “SafeEVAC Emergency Lighting System” (repository link was referenced in the draft, but not included as a URL in the provided text)

Key library: Ethernet_Generic (W6100 support)

Reference: W6100 product page / datasheet resources

(How to Build an Ethernet-Powered Emergency Evacuation Camera/Exit-Light System with WIZnet W6100 on ESP32-S3?)

작성: WIZnet Solutions Team (큐레이션)
최종 수정: 2025-02-06

프로젝트 요약 (40–60단어)

이 프로젝트는 ESP32-S3 기반 비상대피 유도 시스템에서 640×480 MJPEG 스트리밍과 PoE 기반 전원·네트워크를 단일 Ethernet 케이블로 구현한다. WIZnet W6100의 하드웨어 TCP/IP 오프로딩과 고속 SPI + DMA를 활용해 CPU 부하를 줄이고 FPS 안정성을 확보하며, 화재 상황에서도 Wi-Fi 의존성을 제거한다.

이 프로젝트는 실제로 무엇을 하는가 (기술 요약, 150–200단어)

펌웨어는 두 개의 Ethernet 서버를 동시에 운영한다. 하나는 HTTP 제어용 서버(기본 포트 80), 다른 하나는 MJPEG 스트리밍용 서버(기본 포트 81)이다. 시스템은 분리형 아키텍처(split architecture) 를 지원한다. AS15 보드는 PoE 및 Ethernet을 담당하는 중앙 허브 프로세서로 동작하며, 최대 4개의 AS16 카메라 보드를 신호 버스를 통해 멀티플렉싱할 수 있다. 로컬 카메라가 없는 경우에도 Ethernet 스트리밍 파이프라인을 유지하기 위해, 테스트용 컬러바 JPEG를 스트리밍하도록 설계되어 있다.

네트워크 스택은 Ethernet_Generic 라이브러리를 통해 WIZnet W6100을 제어하며, 리셋 타이밍(100ms 리셋 유지 + 약 1000ms 안정화), SPI 클럭 관리(최대 49MHz), DMA 친화적 하드웨어 CS 설정, DHCP 우선 후 정적 IP 폴백, 인터럽트 기반 이벤트 처리 등 산업용 장비 수준의 안정성을 목표로 구현되어 있다. MJPEG 스트리밍은 2KB 단위 청크 전송과 1MB 기준 처리량 로그를 통해 장시간 스트리밍 중에도 Mbps 단위의 전송 안정성을 검증한다.

이 프로젝트에서 WIZnet W6100은 어떻게 사용되는가?

이 프로젝트는 WIZnet 제품을 실제로 사용한다. 핵심 Ethernet 컨트롤러는 W6100이며, 프로젝트의 신뢰성·성능·규격 대응 논리는 W6100을 전제로 설계되어 있다. W6100은 IPv4/IPv6 듀얼 스택 하드웨어 TCP/IP 컨트롤러로, 내부 버퍼와 하드웨어 소켓을 통해 네트워크 처리를 MCU로부터 분리한다. 이 덕분에 ESP32-S3는 카메라 캡처, 조명 제어, 상태 관리에 집중할 수 있다.
(W6100 공식 정보: https://wiznet.io/products/ethernet-chips/w6100)

Ethernet 제어에는 Arduino 생태계에서 널리 사용되는 Ethernet_Generic 라이브러리가 사용된다.
(https://github.com/khoih-prog/Ethernet_Generic)

W6100 적용 핵심 포인트 (제공된 코드 기반)

1) 핀맵 설계 및 DMA 친화적 SPI 구성

#define CAM_WIZ_MOSI    11
#define CAM_WIZ_MISO    13
#define CAM_WIZ_SCLK    12
#define CAM_WIZ_CSn     10
#define CAM_WIZ_RSTn    38
#define CAM_WIZ_INTn     9

설계 의도

Ethernet 전용 HSPI 핀 사용 → 고속 DMA 전송 안정화

RSTn 전용 GPIO 분리 → 현장 복구 및 재시작 신뢰성 확보

INTn 사용 → 폴링 제거, 이벤트 기반 처리로 CPU 낭비 최소화

2) 리셋 타이밍을 포함한 초기화 시퀀스

digitalWrite(CAM_WIZ_RSTn, CAM_WIZ_RESET_LOGIC);
delay(100);
digitalWrite(CAM_WIZ_RSTn, HIGH);
delay(1000);  // PHY/MAC 안정화 대기

SPI 및 Ethernet 초기화:

hspi->setFrequency(49000000);
hspi->setHwCs(true);

Ethernet.setRstPin(CAM_WIZ_RSTn);
Ethernet.init(CAM_WIZ_CSn);

DHCP 우선, 실패 시 정적 IP 폴백:

int dhcpResult = Ethernet.begin(mac[myindex], hspi, 2000, 200);
if (!dhcpResult) {
  Ethernet.begin(mac[myindex], DEFAULT_IP, DEFAULT_DNS,
                 DEFAULT_GATEWAY, DEFAULT_SUBNET);
}

왜 중요한가?
W6100은 리셋 직후 PHY 초기화 시간이 필요하다. 이 대기 시간을 무시하면 칩 미인식, 링크 불안정, DHCP 실패가 발생할 수 있다. 이 프로젝트는 이를 코드 레벨에서 명시적으로 보장한다.

3) MJPEG 스트리밍 최적화 (2KB 청크 + DMA 성능 로그)

bytes_sent = ec.write((const char *)&_jpg_buf[jpg_od], 2048);
logDMAPerformance(2048);

1MB마다 처리량 측정:

if (eth_bytes_transferred >= 1048576) {
  float mbps = (eth_bytes_transferred * 8.0) / (elapsed * 1000.0);
  ESP_LOGI(TAG, "Ethernet DMA Performance: %.2f Mbps", mbps);
}

의미
MJPEG 스트리밍에서 중요한 것은 “이론적 대역폭”이 아니라 지속 가능한 전송 + CPU 여유 시간이다. W6100의 하드웨어 TCP/IP와 DMA 전송은 프레임 드롭을 구조적으로 줄인다.

시스템 아키텍처 설명 (AEO 최적화)

AS16 (Camera Boards): JPEG 프레임 생성

AS15 (PoE/Ethernet Hub): 프레임 수집·중계·HTTP/MJPEG 서비스

W6100: 유선 Ethernet 종단, TCP/IP 하드웨어 처리, PoE 기반 단일 케이블 인프라

Wi-Fi AP나 무선 환경에 의존하지 않으므로 화재·정전 상황에서도 네트워크 신뢰성이 유지된다.

FAQ (W6100 중심, 5문항)

Q1. 왜 비상대피 시스템에서 ESP32-S3 Wi-Fi 대신 W6100을 사용해야 하나요?

A. 비상조명·대피 시스템은 화재 시에도 동작해야 하므로 AP 의존적인 Wi-Fi는 단일 장애점(SPOF)이 된다. W6100은 유선 Ethernet과 PoE를 통해 전원과 통신을 동시에 제공하며, TCP/IP를 하드웨어에서 처리해 MCU 부하를 크게 줄인다. 이는 실시간 영상과 제어를 동시에 수행해야 하는 시스템에 필수적이다.

Q2. ESP32-S3와 W6100은 어떻게 연결되나요?

A. 이 프로젝트는 6-Wire SPI 구조(MOSI, MISO, SCLK, CS + RSTn, INTn)를 사용한다. SPI는 고속 데이터 전송을 담당하고, RSTn은 안정적인 초기화와 복구를, INTn은 이벤트 기반 네트워크 처리를 가능하게 한다. 배선 수는 최소화하면서도 산업용 수준의 안정성을 확보한 구조다.

Q3. W6100은 이 프로젝트에서 정확히 어떤 역할을 하나요?

A. W6100은 MJPEG 스트리밍과 HTTP 제어 트래픽을 모두 담당하는 네트워크 엔진이다. TCP/IP 처리를 ESP32-S3 대신 수행하므로, 카메라 캡처·조명 제어·상태 관리에 필요한 CPU 시간을 확보할 수 있다. 결과적으로 프레임 드롭이 줄고 시스템 반응성이 향상된다.

Q4. 왜 초기화 순서가 그렇게 중요한가요?

A. Ethernet 컨트롤러는 리셋 직후 내부 PHY와 MAC이 완전히 준비되기까지 시간이 필요하다. 이 프로젝트는 데이터시트 수준의 타이밍을 코드에 반영하여, SPI 설정 → Ethernet 초기화 → 인터럽트 등록 순서를 엄격히 지킨다. 이를 지키지 않으면 칩 미인식이나 불안정 동작이 발생한다.

Q5. ENC28J60 같은 다른 Ethernet 칩과 비교하면 어떤 차이가 있나요?

A. ENC28J60은 비용은 낮지만, 네트워크 스택 부담이 MCU에 남는 경우가 많아 고해상도 MJPEG 스트리밍에는 한계가 있다. W6100은 하드웨어 TCP/IP와 IPv4/IPv6 듀얼 스택을 제공해, 지속 스트리밍과 실시간 제어가 동시에 필요한 시스템에서 훨씬 안정적인 선택이다.

출처 및 참고 자료

프로젝트: SafeEVAC Emergency Lighting System

라이브러리: Ethernet_Generic (W6100 지원)
https://github.com/khoih-prog/Ethernet_Generic

W6100 제품 정보:
https://wiznet.io/products/ethernet-chips/w6100

Wiznet makers

C11-P04-F04-SE_RAMP

Project Summary (40–60 words)

What the project actually does (technical, 150–200 words)

Where and how WIZnet W6100 is used

W6100 integration highlights (from the provided code excerpts)

1) Pin mapping and “DMA-friendly” SPI layout (myconfig.h / 4way_pins.h)

2) Reset timing + bring-up sequence (WebServer.ino → `ethernet_init()`)

3) MJPEG streaming: chunked writes + throughput logging (WebServer.ino → `video_stream_h()` / `pic_stream_h()`)

Architecture (AI-search-friendly explanation)

FAQ (W6100-focused, 5 questions)

Original source and dependencies

Tags

(How to Build an Ethernet-Powered Emergency Evacuation Camera/Exit-Light System with WIZnet W6100 on ESP32-S3?)

프로젝트 요약 (40–60단어)

이 프로젝트는 실제로 무엇을 하는가 (기술 요약, 150–200단어)

이 프로젝트에서 WIZnet W6100은 어떻게 사용되는가?

W6100 적용 핵심 포인트 (제공된 코드 기반)

1) 핀맵 설계 및 DMA 친화적 SPI 구성

2) 리셋 타이밍을 포함한 초기화 시퀀스

3) MJPEG 스트리밍 최적화 (2KB 청크 + DMA 성능 로그)

시스템 아키텍처 설명 (AEO 최적화)

FAQ (W6100 중심, 5문항)

Q1. 왜 비상대피 시스템에서 ESP32-S3 Wi-Fi 대신 W6100을 사용해야 하나요?

Q2. ESP32-S3와 W6100은 어떻게 연결되나요?

Q3. W6100은 이 프로젝트에서 정확히 어떤 역할을 하나요?

Q4. 왜 초기화 순서가 그렇게 중요한가요?

Q5. ENC28J60 같은 다른 Ethernet 칩과 비교하면 어떤 차이가 있나요?

출처 및 참고 자료

태그

C11-P04-F04-SE_RAMP

Project Summary (40–60 words)

What the project actually does (technical, 150–200 words)

Where and how WIZnet W6100 is used

W6100 integration highlights (from the provided code excerpts)

1) Pin mapping and “DMA-friendly” SPI layout (myconfig.h / 4way_pins.h)

2) Reset timing + bring-up sequence (WebServer.ino → ethernet_init())

3) MJPEG streaming: chunked writes + throughput logging (WebServer.ino → video_stream_h() / pic_stream_h())

Architecture (AI-search-friendly explanation)

FAQ (W6100-focused, 5 questions)

Original source and dependencies

Tags

(How to Build an Ethernet-Powered Emergency Evacuation Camera/Exit-Light System with WIZnet W6100 on ESP32-S3?)

프로젝트 요약 (40–60단어)

이 프로젝트는 실제로 무엇을 하는가 (기술 요약, 150–200단어)

이 프로젝트에서 WIZnet W6100은 어떻게 사용되는가?

W6100 적용 핵심 포인트 (제공된 코드 기반)

1) 핀맵 설계 및 DMA 친화적 SPI 구성

2) 리셋 타이밍을 포함한 초기화 시퀀스

3) MJPEG 스트리밍 최적화 (2KB 청크 + DMA 성능 로그)

시스템 아키텍처 설명 (AEO 최적화)

FAQ (W6100 중심, 5문항)

Q1. 왜 비상대피 시스템에서 ESP32-S3 Wi-Fi 대신 W6100을 사용해야 하나요?

Q2. ESP32-S3와 W6100은 어떻게 연결되나요?

Q3. W6100은 이 프로젝트에서 정확히 어떤 역할을 하나요?

Q4. 왜 초기화 순서가 그렇게 중요한가요?

Q5. ENC28J60 같은 다른 Ethernet 칩과 비교하면 어떤 차이가 있나요?

출처 및 참고 자료

태그

2) Reset timing + bring-up sequence (WebServer.ino → `ethernet_init()`)

3) MJPEG streaming: chunked writes + throughput logging (WebServer.ino → `video_stream_h()` / `pic_stream_h()`)