---
title: "web_server_IO_Sd_fliip_Swich"
url: "https://maker.wiznet.io/scott/projects/web-server-io-sd-fliip-swich/"
markdown_url: "https://maker.wiznet.io/scott/projects/web-server-io-sd-fliip-swich/md"
type: "UCC: User Created Content"
author: "thomasz_05"
author_url: "https://www.hackster.io/thomaszamengo/web-server-io-sd-fliip-swich-3908af"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "thomasz_05"
original_url: "https://www.hackster.io/thomaszamengo/web-server-io-sd-fliip-swich-3908af"
published: "2026-02-20"
language: "en"
tags: ["W5500", "Webserver"]
hardware: ["Arduino Ethernet Shield"]
likes: 0
views: 594
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---
# web_server_IO_Sd_fliip_Swich
> A 6-Channel Arduino Ethernet I/O Control Server with SD-Based Web UI
Original author: thomasz_05 (source: https://www.hackster.io/thomaszamengo/web-server-io-sd-fliip-swich-3908af)
## Components
- **Arduino Ethernet Shield** x 1 ([docs](https://docs.arduino.cc/retired/shields/arduino-ethernet-shield-without-poe-module))
- Software: **Arduino IDE** ([docs](https://www.arduino.cc/en/software))
## Documents and links
- [F/W](https://github.com/thomasz05/Arduino/tree/main/web_server_IO_Sd_fliip_Swich) (code)
## Article
임베디드 환경에서 웹 기반 제어 기능을 구현할 때 가장 큰 제약은 제한된 SRAM과 Flash 용량입니다. 특히 HTML, JavaScript, 상태 처리 로직을 모두 MCU 내부에 포함시키는 방식은 유지보수성과 확장성 측면에서 비효율적입니다.
### ■ 해결하려는 문제
- MCU 자원 제약 하에서 웹 UI + 실시간 제어 구현
- 다중 브라우저 접속 시 상태 불일치 문제 해결
- 구조적으로 확장 가능한 I/O 제어 패턴 설계
### ■ 타겟 환경
- 동일 LAN 내 브라우저(PC/모바일)
- Arduino Uno 기반 소형 제어 시스템
- 교육용/프로토타이핑/간단한 산업용 제어 응용
---
## 2. 시스템 아키텍처
### ■ 구성 요소
- **Arduino Uno**
- **Arduino Ethernet Shield 2 (W5500 기반)**
- **SD 카드 (index.htm 저장)**
- **디지털 출력 6채널 (LED 예시: D3, D5, D6, D7, D8, D9)**
### ■ 데이터 흐름
*Data Flow (AI Image)*
- 사용자가 브라우저에서 접속
- 서버는 SD 카드에서 `index.htm`을 읽어 HTTP 응답
- 사용자가 토글 버튼 클릭 → HTTP GET 요청 (`?LED1=1`)
- 서버는 문자열 분석 후 GPIO 출력 변경
- 클라이언트는 1초 주기로 `/ajax_inputs` 요청
- 서버는 XML 형태로 현재 상태 반환
- 브라우저 UI가 체크 상태 갱신
### ■ 구조적 특징
- 제어 요청과 상태 요청을 분리
- 상태는 단일 배열로 관리
- Content-Type을 상황에 따라 분기(text/html, text/xml)
---
## 3. 기술 특징
### ■ SD 기반 정적 파일 서빙
HTML을 MCU 코드에 포함하지 않고 SD 카드에서 직접 스트리밍 전송합니다.
이 방식은 다음 이점을 제공합니다:
- SRAM 사용량 감소
- UI 변경 시 펌웨어 재업로드 불필요
- CSS/JS 확장 가능
### ■ HTTP GET 기반 경량 제어
- `LED1=1`, `LED2=0` 형태의 단순 파라미터 구조
- 별도의 복잡한 REST 설계 없이 구현 가능
- 요청 문자열 버퍼 기반 파싱
### ■ Ajax(XML) 상태 동기화
- 1초 폴링 방식
- `checked` 구조
- 다중 클라이언트 환경에서도 상태 일관성 유지
이 구조는 임베디드 웹 시스템에서 매우 실용적인 패턴입니다.
---
## 4. WIZnet Insight
*WIZnet Insight (AI Image)*
본 프로젝트는 **W5500 기반 Ethernet Shield 2**를 사용합니다.
W5500은 하드웨어 TCP/IP 스택을 내장한 이더넷 컨트롤러로, 다음과 같은 기술적 강점을 제공합니다:
- TCP/IP 프로토콜 하드웨어 오프로딩
- MCU의 네트워크 스택 처리 부담 감소
- 최대 8개 하드웨어 소켓 지원
- 안정적인 유선 이더넷 연결
특히 Ajax 기반 주기적 폴링 구조에서는 반복적인 TCP 세션 처리가 발생합니다. W5500의 하드웨어 오프로딩 구조는 이러한 반복 통신 환경에서 MCU 자원 사용을 최소화합니다.
결과적으로 Uno급 MCU에서도 웹 서버 + I/O 제어 + 상태 동기화를 안정적으로 수행할 수 있는 기반을 제공합니다.
---
## 5. 비즈니스 및 활용 가치
### ■ 교육 및 메이커 환경
- 웹 기반 I/O 제어 구조 학습
- 네트워크 기반 임베디드 시스템 실습
### ■ 소형 설비 제어
- 릴레이/SSR로 확장 시 원격 전원 제어 가능
- 간단한 공정 ON/OFF 제어
### ■ IoT 게이트웨이 프로토타입
- 센서 입력 추가 후 대시보드 구성 가능
- XML → JSON API 확장 가능
### ■ 내부 기술 인사이트
- “정적 리소스 분리” 설계 패턴 재사용 가능
- 하드웨어 TCP/IP 기반 네트워크 설계 검증 사례
---
## 6. 확장 전략
- LED → 릴레이 모듈로 확장
- 입력 채널 추가 후 양방향 모니터링
- JSON 기반 REST API 구조로 전환
- 인증 기능 추가 (Basic Auth 또는 게이트웨이 프록시 활용)
- HTTPS 적용 시 외부 TLS 오프로딩 장치 활용
---
## 7. FAQ
### Q1. 동시 접속자가 늘어나면 병목은 어디에서 발생합니까?
파일 I/O(SD 접근)와 반복적인 HTTP 세션 처리에서 발생할 수 있습니다. 폴링 주기를 조정하거나 상태 요청을 경량화하는 것이 필요합니다.
### Q2. XML 대신 JSON을 사용해도 됩니까?
가능합니다. Content-Type과 클라이언트 파싱 로직만 변경하면 구조는 동일합니다.
### Q3. 산업용으로 사용해도 됩니까?
직접 고전압을 제어하지 말고, 반드시 릴레이/SSR 및 절연 설계를 적용해야 합니다.
### Q4. 외부 인터넷에서 접근하려면 어떻게 해야 합니까?
직접 포트 포워딩은 권장되지 않습니다. VPN 또는 리버스 프록시 기반 구조가 안전합니다.
### Q5. HTTPS를 적용할 수 있습니까?
Uno급 MCU 단독으로는 현실적으로 제한이 큽니다. TLS 오프로딩 게이트웨이 구성이 현실적인 대안입니다.
---
## 결론
본 프로젝트는 단순한 LED 제어 예제를 넘어, 임베디드 웹 시스템 설계의 실용적인 패턴을 제시합니다.
- 정적 UI 분리
- 경량 제어 API
- 상태 전용 응답 구조
- 하드웨어 TCP/IP 오프로딩 활용
이 조합은 리소스가 제한된 MCU 환경에서도 안정적이고 확장 가능한 웹 제어 시스템을 구현할 수 있음을 보여줍니다.
---
---
In embedded environments, implementing a web-based control interface is often constrained by limited SRAM and Flash memory. Embedding full HTML and JavaScript directly into firmware reduces scalability and maintainability.
### ■ Problem Statement
- Deliver web UI + real-time I/O control under tight MCU resource limits
- Maintain consistent output state across multiple browser sessions
- Establish a reusable and scalable embedded web control architecture
### ■ Target Environment
- Browsers within the same LAN (PC/mobile)
- Arduino Uno-based control systems
- Educational, prototyping, and light industrial applications
---
## 2. System Architecture
### ■ Hardware Components
- **Arduino Uno**
- **Arduino Ethernet Shield 2 (W5500-based)**
- **SD card (stores index.htm)**
- **Six digital outputs (example: D3, D5, D6, D7, D8, D9)**
### ■ Data Flow
*Data Flow (AI Image)*
- A browser connects to the Arduino web server.
- The server reads `index.htm` from the SD card and sends it via HTTP.
- When a user toggles a switch, an HTTP GET request is sent (e.g., `?LED1=1`).
- The server parses the request and updates the corresponding GPIO.
- The browser polls `/ajax_inputs` every second.
- The server returns current states in XML format.
- The browser updates the UI to reflect the actual hardware state.
### ■ Architectural Characteristics
- Control requests and status requests are separated.
- Output states are managed in a single centralized array.
- HTTP responses switch Content-Type dynamically (text/html, text/xml).
- This separation improves clarity, scalability, and synchronization reliability.
---
## 3. Technical Characteristics
### ■ SD-Based Static File Serving
Instead of embedding HTML in firmware, the system streams `index.htm` directly from the SD card.
Advantages:
- Reduced SRAM usage
- No firmware update required for UI modifications
- Easy expansion with CSS/JavaScript
### ■ Lightweight HTTP GET Control
- Simple parameter structure (`LED1=1`, `LED2=0`)
- Minimal parsing logic
- Efficient for resource-constrained MCUs
### ■ Ajax (XML) Status Synchronization
- 1-second polling cycle
- XML response structure:
```xml
checked
```
- Ensures consistent state visibility across multiple clients
This pattern is highly practical in embedded web systems where WebSockets or heavy frameworks are not feasible.
---
## 4. WIZnet Insight
*WIZnet Insight (AI Image)*
This implementation utilizes the **W5500-based Ethernet Shield 2**, which integrates a hardware TCP/IP stack.
- Key technical strengths:
- Full hardware TCP/IP offloading
- Reduced MCU processing burden
- Up to 8 independent hardware sockets
- Reliable wired Ethernet connectivity
In Ajax-based polling systems, repeated TCP sessions are generated continuously. The W5500 handles TCP/IP processing in hardware, significantly reducing the load on the ATmega328P MCU.
This hardware offloading capability makes it feasible to implement web server + GPIO control + status synchronization simultaneously on a resource-limited platform like Arduino Uno.
---
## 5. Business and Practical Value
### ■ Educational and Maker Applications
- Demonstrates embedded web server architecture
- Provides hands-on learning for network-based control systems
### ■ Small-Scale Industrial Control
- Can be expanded to relay or SSR control
- Suitable for remote ON/OFF equipment management
### ■ IoT Gateway Prototyping
- Sensor inputs can be added for monitoring
- XML endpoint can be migrated to JSON API
### ■ Internal Engineering Insight
- Validates static resource separation pattern
- Demonstrates the effectiveness of hardware TCP/IP offloading in embedded systems
---
## 6. Expansion Strategy
- Replace LEDs with relay modules or SSR outputs
- Add digital/analog inputs for monitoring
- Convert XML to JSON for REST-style API
- Implement authentication (Basic Auth or gateway proxy)
- Use TLS offloading gateway for HTTPS deployment
---
## 7. FAQ
### Q1. Where is the primary bottleneck under multiple client connections?
SD card file I/O and repeated HTTP session handling can become bottlenecks. Adjusting polling intervals and optimizing response size improves performance.
### Q2. Can XML be replaced with JSON?
Yes. Only the Content-Type header and client parsing logic need modification. The architectural pattern remains unchanged.
### Q3. Is this suitable for industrial deployment?
Yes, with proper electrical isolation. Use relays or SSRs and ensure safe high-voltage handling.
### Q4. How can external internet access be enabled?
Direct port forwarding is not recommended. A VPN or reverse proxy architecture is more secure.
### Q5. Can HTTPS be implemented directly on Arduino Uno?
Practical limitations exist due to memory constraints. TLS offloading through an external gateway is the recommended solution.
---
## Conclusion
This project extends beyond a simple LED control example. It demonstrates a practical embedded web architecture pattern:
- Static UI separation via SD
- Lightweight HTTP-based control API
- Dedicated status endpoint
- Hardware TCP/IP offloading using W5500
Together, these elements enable stable and scalable web-based I/O control even on resource-constrained MCUs.
---
Source: https://maker.wiznet.io/scott/projects/web-server-io-sd-fliip-swich/