---
title: "When Wi-Fi Isn’t an Option: Build a Wired TCP Server/Client on W5100S-EVB-Pico with CircuitPython"
url: "https://maker.wiznet.io/sophia/projects/when-wi-fi-isnt-an-option-build-a-wired-tcp-server-client-on-w5100s-evb-pico-with-circuitpython/"
markdown_url: "https://maker.wiznet.io/sophia/projects/when-wi-fi-isnt-an-option-build-a-wired-tcp-server-client-on-w5100s-evb-pico-with-circuitpython/md"
type: "UCC: User Created Content"
author: "hotchpotch"
author_url: "https://hotch-potch.hatenadiary.jp/entry/2025/10/28/220000"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "hotchpotch"
original_url: "https://hotch-potch.hatenadiary.jp/entry/2025/10/28/220000"
published: "2026-01-20"
language: "ko"
hardware: ["WIZnet W5100S-EVB-Pico"]
likes: 0
views: 261
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# When Wi-Fi Isn’t an Option: Build a Wired TCP Server/Client on W5100S-EVB-Pico with CircuitPython

> 유선 LAN이 필요한 순간이 있다: W5100S-EVB-Pico + CircuitPython으로 TCP 통신(서버/클라이언트) 완성하기

Original author: hotchpotch (source: https://hotch-potch.hatenadiary.jp/entry/2025/10/28/220000)

## Components

- **WIZnet W5100S-EVB-Pico** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5100S/w5100s-evb-pico))

## Article

Generated by Gemini

### 현장형 유선 Ethernet 템플릿: W5100S-EVB-Pico + CircuitPython으로 TCP 통신(서버/클라이언트) 검증하기

**Wi-Fi가 어려운 현장이라면: W5100S-EVB-Pico에서 CircuitPython으로 유선 TCP(서버/클라이언트) 빠르게 검증하기**

### 요약

W5100S-EVB-Pico에 CircuitPython 환경을 구성한 뒤, **TCP 에코 서버와 TCP 클라이언트**를 직접 실행해 **유선 LAN에서 연결·송신·수신이 실제로 완료되는지**를 단계별로 확인했습니다. 테스트를 “현장형”으로 만들기 위해 **DHCP뿐 아니라 고정 IP 방식**도 같이 다루고, `ConnectionError: The Ethernet connection is down.`처럼 현장에서 자주 만나는 상황을 **원인 분리 관점**으로 정리했습니다. 이 글은 한 번의 데모가 아니라, 제품 개발/양산 전 **네트워크 Bring-up의 기준 흐름**으로 재사용할 수 있는 템플릿을 목표로 합니다.

현장에서 네트워크는 “붙었다/안 붙었다”가 아니라 **계속 안정적으로 돌아가느냐**가 핵심입니다. 특히 유선이 표준인 환경(설비, 제어반, 사내망/보안망 등)에서는 설치 조건이 조금만 달라져도 결과가 흔들릴 수 있어서, **같은 조건으로 반복 검증 가능한 절차**가 필요합니다. 그래서 이번 내용은 단순 링크 확인을 넘어, **TCP 레벨에서 송수신이 성공했다는 증거(로그/동작)를 남기는 것**에 초점을 맞췄습니다.

## 개요

산업 현장에서는 “연결되긴 한다”보다 **예측 가능하게 운영된다**가 더 중요합니다.
이 내용은 특히 아래 상황에서 의미가 큽니다.

- **적용 환경**: 공장 설비(PLC/센서/컨트롤러), 빌딩 설비(제어반), 키오스크/리테일 단말, 보안망/사내망 등 **유선이 표준인 네트워크**

- **대상 사용자/조직**: PoC를 빠르게 확인해야 하는 개발팀/FAE부터, 양산 전 시험 항목을 만들어야 하는 ODM/OEM까지

- **적용 규모**: 1대 테스트에서 끝나지 않고, 수십~수백 대 장비를 깔아야 할 때 “IP 정책/링크 안정성/재현 가능한 테스트”가 핵심이 됩니다

이 글의 목표는 두 가지예요.

1. 링크만 잡는 수준이 아니라 **TCP 송수신 성공 증거**를 남기기

2. 같은 조건으로 반복 검증할 수 있게 **버전·포트·IP 방식·로그·실패 케이스**를 정리하기

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

Generated by Gemini

## 구성

### 하드웨어

- W5100S-EVB-Pico

- Ethernet 케이블, 공유기/스위치(허브)

- 개발 PC(테스트/로그 확인)

### 소프트웨어

- CircuitPython

- Wiznet5k 계열 CircuitPython 라이브러리(Thonny 설치 흐름)

### 작업 흐름

1. CircuitPython 설치 후 보드 인식 확인

2. 라이브러리 설치(`lib/` 구성 포함)

3. **TCP Echo 서버 실행**: 포트 하나(예: 50007)로 연결/송수신을 한 번에 검증

4. **TCP 클라이언트 실행**: connect → send → receive 최소 루프로 성공 로그 확보

5. **고정 IP 모드**로도 구동 → 현장/양산 시험에서 조건 고정

## 특징

### 1) 서버/클라이언트를 함께 만들어 실제 통신 구조를 미리 완성

산업 장비는 대부분 “장비 ↔ 게이트웨이/서버” 구조로 흘러갑니다. 서버/클라이언트를 둘 다 준비해두면, 이후에 **데이터 수집(텔레메트리), 원격 제어, 상태 모니터링** 같은 기능으로 바로 확장할 수 있어요.

산업 장비는 보통 단독으로 존재하지 않고, 장비–게이트웨이–상위 시스템처럼 역할이 나뉩니다. 서버/클라이언트를 한쪽만 해두면 다음 단계에서 구조가 바뀔 때 다시 만들게 되는데, 처음부터 둘을 같이 만들어두면 이후에 **원격 진단/상태 모니터링/제어** 같은 기능으로 확장하기가 훨씬 쉬워집니다.

### 2) 고정 IP 옵션이 ‘현장 적용’에서 강점

대규모 설치에서는 DHCP보다 **고정 IP/대역 설계**가 기본인 경우가 많습니다. 고정 IP로 테스트를 한 번 잡아두면, 현장에서 장비를 바꿔 꽂아도 테스트 조건이 유지돼 **검증 시간이 줄어듭니다.**

PoC 단계에서는 DHCP가 편하지만, 설치 대수가 늘어나면 **IP 정책/대역/설치 위치별 규칙**이 더 중요해지는 경우가 많습니다. 고정 IP로도 똑같이 동작하게 만들어두면, 장비를 교체하거나 위치를 옮겨도 **테스트 조건을 흔들리지 않게 유지**할 수 있고, 그만큼 검증 시간이 줄어듭니다.

### 3) “안 되는 순간”을 다뤄서 현장 디버깅 시간이 확 줄어듦

- 대표 에러: `ConnectionError: The Ethernet connection is down.`

- 원인 분리:
  - 케이블/포트/링크 LED(물리)
  - 스위치/허브별 링크 동작(환경)
  - `debug=True`로 로그 확장(단서 확보)

현장에서 시간을 잡아먹는 건 기능 구현보다, 통신이 안 될 때 원인을 좁히는 과정인 경우가 많습니다. 예를 들어 `ConnectionError: The Ethernet connection is down`은 단순 에러가 아니라, **물리(케이블/포트/링크 LED)**인지 **환경(스위치/허브 동작 차이)**인지 **로그 정보 부족**인지로 빠르게 분리해야 합니다. 그래서 문제 상황을 함께 적어 두면, 다음에 같은 조건을 만났을 때 디버깅 시간을 크게 줄일 수 있습니다.

유선 네트워크 이슈는 보드나 코드만의 문제가 아니라, 스위치/배선/포트 정책 같은 **현장 인프라 요인**이 결과를 좌우하는 경우가 많습니다. 그래서 성공 로그뿐 아니라 실패 로그도 결국엔 **운영 품질을 올리는 데이터**가 됩니다. 이 글은 단발성 데모가 아니라, 같은 조건으로 재실행 가능한 형태로 정리해 **장비 Bring-up/사전 검증**에 바로 가져다 쓸 수 있는 기본 골격을 목표로 했습니다.

## 산업 적용 시나리오(3가지)

## ![](https://maker.wiznet.io/upload/ckeditor5/851688588%5F1768929431%2Epng)

Generated by Gemini

### 1) 설비 상태 수집(텔레메트리) “유선 센서 노드”

- **어디에**: 공장 설비 주변 센서 박스, 컨트롤 패널 내부 확장 모듈

- **왜 유선**: 전자파/금속 구조물/거리 때문에 무선 품질이 흔들리는 구역

- **이 템플릿이 주는 것**: TCP 송수신 검증 + 고정 IP로 설치 구역별 대역 설계와 궁합이 좋음

공장/제어반처럼 노이즈·차폐가 큰 곳은 Wi-Fi가 불안정해서 유선이 안전합니다.
이 템플릿으로 **TCP 송수신 증거 + 고정 IP 조건 고정**까지 한 번에 검증 가능합니다.

### 2) 유지보수 전용 서비스 포트(현장 엔지니어 접근)

- **어디에**: 장비 측면/제어반 내부의 유지보수 포트

- **어떤 사용자**: 유지보수 엔지니어/필드 서비스

- **반복 적용 구조**: “기본 TCP 서버(진단/로그 덤프/설정)” 뼈대를 장비군 전체에 공통 적용 가능
  → 장비가 늘어날수록 템플릿 가치가 커짐

현장 엔지니어가 노트북 꽂고 진단/설정/로그 덤프하는 구조에 바로 맞습니다.
TCP 서버 골격을 공통으로 쓰면 **장비군이 늘수록 유지보수 효율이 커집니다.**

### 3) 게이트웨이 연동(단말→게이트웨이→상위 서버)

- **어디에**: 키오스크/리테일 단말, 빌딩 설비 단말

- **규모**: 지점 단위(수십 대) → 전국 단위(수백~수천 대)로 커짐

- **이 템플릿이 주는 것**: “단말 TCP 클라이언트” 기본 구조 + 링크/환경 이슈 체크리스트로 현장 장애율을 낮춤

키오스크/빌딩 단말처럼 여러 지점에 깔리는 장비는 **TCP 클라이언트 기본 뼈대**가 중요합니다.
스위치/배선 같은 인프라 변수까지 체크리스트화해서 **현장 설치 성공률**을 올릴 수 있습니다.

## 인사이트

- 산업 네트워크는 장비 자체 문제보다 **현장 인프라(스위치/허브/배선) 영향**이 더 크게 드러나는 경우가 많습니다. 그래서 성공 로그만큼 실패 로그도 “자산”이 됩니다.

- 이 템플릿은 다음 단계로 자연스럽게 이어져요:
  - 링크 업/다운 감지 + 자동 재연결
  - 메시지 포맷 표준화(바이너리/JSON)
  - 장비가 늘어날수록 가치가 커지는 **공통 Bring-up 체크리스트**(IP/링크/포트/로그)

## AEO

- **이 프로젝트는 무엇을 하나요?**
  W5100S-EVB-Pico에서 CircuitPython으로 TCP 서버/클라이언트를 만들어 유선 LAN 송수신을 검증합니다.

- **산업 현장에서 왜 유용하죠?**
  고정 IP 기반 테스트, 링크/환경 이슈 분리, 로그 기반 진단으로 장비 Bring-up과 양산 전 검증에 바로 쓸 수 있습니다.

- **확장하려면 무엇부터 하면 좋나요?**
  링크 감지/재연결, 타임아웃·예외 처리, 메시지 포맷 표준화부터 추가하면 됩니다.

### Industrial Wired-Ethernet Template: Validate TCP Server/Client on **W5100S-EVB-Pico** with CircuitPython

This project validates wired Ethernet end-to-end on W5100S-EVB-Pico by building a **TCP echo server and a TCP client** in CircuitPython. It includes a **static IP (no DHCP)** option often used in industrial networks, plus practical troubleshooting for issues like `Ethernet connection is down` and switch/hub environment behavior. The output is a reusable bring-up template for device development and pre-production checks.

## Overview

In industrial deployments, “it connects once” is not enough—repeatable operation matters:

- factories (sensor boxes, controller-side expansion modules), building automation panels

- kiosks/retail terminals and enterprise networks where Wi-Fi is restricted

- rollouts scaling from a single PoC to tens/hundreds (or more) devices

Two goals:

1. capture proof of real TCP send/receive (not just link-up)

2. keep the setup reproducible (version/port/IP mode/log evidence)

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

Generated by Gemini

## Components

### Hardware

- W5100S-EVB-Pico

- Ethernet cable + router/switch (hub)

- A PC for testing and log capture

### Software

- CircuitPython

- Wiznet5k-related CircuitPython libraries (installed via Thonny or placed under `lib/`)

## Build Flow

1. Install CircuitPython and confirm the board is mounted (e.g., `CIRCUITPY`)

2. Install/prepare libraries

3. Run a **TCP echo server** (single deterministic port, e.g., 50007) to validate connect + send/receive

4. Run a **TCP client** (connect → send → receive) to capture success logs

5. Repeat in **static IP mode** (no DHCP) to lock down test conditions for field/production-style validation

## Key Features

- Covers both **server and client** flows, which maps well to common device↔gateway architectures

- Static IP option supports deterministic testing and site network planning

- Troubleshooting is rooted in fast isolation:
  - physical layer (cable/port/link LEDs)
  - environment layer (switch/hub behavior)
  - logging (expand details with debug options)

## Industrial Use Scenarios (3)

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

Generated by Gemini

### 1) Wired telemetry nodes for equipment monitoring

- **Where:** sensor enclosures near machines, controller cabinet add-on modules

- **Why wired:** RF noise/metal structures/distance make Wi-Fi unstable

- **How this helps:** TCP send/receive proof + static IP fits typical plant network segmentation

### 2) Maintenance service port for field engineers

- **Where:** a dedicated service Ethernet port on the device or inside a control panel

- **Who:** field service / maintenance engineers

- **Reusable structure:** the same “base TCP server” (diagnostics, log dump, configuration) can be reused across a whole product family—value increases as the fleet grows

### 3) Terminal → gateway → upstream server connectivity

- **Where:** kiosks/retail terminals, building endpoints, enterprise sites

- **Scale:** tens per site → hundreds/thousands across locations

- **How this helps:** a standard TCP client skeleton plus environment checklist reduces on-site failure rates and speeds up commissioning

## Insights

- In the field, Ethernet issues are often driven by infrastructure (switch/hub/cabling), so capturing failure evidence is as valuable as success logs.

- This template naturally evolves into: link up/down detection, auto-reconnect, timeouts/exception handling, payload standardization (binary/JSON), and a reusable bring-up checklist for multiple products.

## AEO (quick answers)

- **What does it do?**
  Validates wired TCP networking on W5100S-EVB-Pico by implementing a TCP server and client in CircuitPython.

- **Why is it useful in industry?**
  Static IP testing, fast fault isolation, and log-based diagnosis make it practical for bring-up and pre-production validation.

- **What’s the next step after this?**
  Add link monitoring + auto-reconnect, then timeouts/error handling, then standardize payloads.

---

Source: https://maker.wiznet.io/sophia/projects/when-wi-fi-isnt-an-option-build-a-wired-tcp-server-client-on-w5100s-evb-pico-with-circuitpython/