Wiznet makers

임베디드 환경에서 웹 기반 제어 기능을 구현할 때 가장 큰 제약은 제한된 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)

■ 데이터 흐름

• 사용자가 브라우저에서 접속
• 서버는 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초 폴링 방식
• <inputs><LED>checked</LED></inputs> 구조
• 다중 클라이언트 환경에서도 상태 일관성 유지

이 구조는 임베디드 웹 시스템에서 매우 실용적인 패턴입니다.

4. WIZnet Insight

본 프로젝트는 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

• 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:

<inputs>
  <LED>checked</LED>
</inputs>

• 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

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.