Wiznet makers

프로젝트가 하는 일

이 프로젝트는 Modbus TCP 네트워크(이더넷) 와 Modbus RTU 장치(RS-485) 를 연결하는 산업용 게이트웨이 펌웨어입니다.

TCP(이더넷)에서 들어온 Modbus 요청을 RTU 프레임(CRC 포함) 으로 변환해 RS-485로 전달

RS-485 응답을 받아 TCP 응답(MBAP 헤더 포함) 으로 재구성해 네트워크로 반환

USB 시리얼을 통해 네트워크/UART 설정을 변경하고, 설정은 플래시에 저장 후 재부팅으로 적용

이미지 출처 : AI 생성

WIZnet(W55RP20/W5500)의 기술적 역할

이 설계의 핵심은 W55RP20에 포함된 W5500 하드웨어 TCP/IP(하드웨어 소켓) 를 이용해, MCU가 “네트워크 스택 구현”보다 Modbus 변환/타임아웃/큐잉 같은 게이트웨이 본업에 집중하도록 하는 점입니다.

TCP 서버(포트 502) 를 안정적으로 유지

소켓 기반 송수신으로 구현 복잡도와 MCU 부담을 줄여 예측 가능한 지연/안정성에 기여

게이트웨이처럼 “네트워크 + 시리얼 동시 처리”가 중요한 시스템에 적합

시스템 구성(태스크/코어 관점)

설명 기준으로 FreeRTOS 멀티코어 분리가 특징입니다.

Core 0: USB 통신 및 설정 관리(프로비저닝/명령 처리)

Core 1: Modbus TCP 서버 + RTU 통신(게이트웨이 데이터 경로)

이 구조의 장점은, 트래픽이 몰릴 때도 설정 채널(USB) 과 변환 경로(TCP↔RTU) 가 서로 발목 잡는 것을 줄인다는 점입니다.

이미지 출처 : AI 생성

동작 흐름(코드 상세 없이)

부팅 시

플래시에서 설정 로드

이더넷(W5500) 초기화

UART/RS-485 초기화

태스크 생성 및 변환 루프 진입

TCP → RTU 변환

TCP 소켓에서 Modbus TCP 프레임 수신

MBAP 헤더 제거 → RTU PDU 구성 → CRC-16 추가

큐에 넣고 RS-485로 송신

RTU → TCP 변환

RS-485에서 응답 수신(타임아웃 적용)

CRC 제거/검증 → MBAP 헤더 재구성(트랜잭션 매칭) → TCP 전송

이미지 출처 : AI 생성

주요 파라미터(설명 기반)

데이터 버퍼: 1024 bytes

큐 크기: 3 messages

RTU 타임아웃: 2000 ms

기본 보드레이트: 9600 bps

스택 크기 예: TCP 서버 8192B, RTU 1024B (구현에 따라 조정)

FAQ (WIZnet 중심)

1) 왜 W55RP20(W5500)로 Modbus 게이트웨이를 만들면 유리한가요?

게이트웨이는 TCP 소켓 유지, RS-485 타이밍, CRC 처리, 설정 저장을 동시에 해야 합니다. W55RP20의 W5500 하드웨어 TCP/IP는 소켓 처리를 오프로딩해 MCU 자원을 덜 쓰게 하고, RTU 타임아웃/지연 변동에 민감한 산업용 변환 작업을 더 안정적으로 운영하는 데 도움이 됩니다.

2) 이 프로젝트에서 W5500은 정확히 무엇을 하나요?

W5500은 “Modbus 변환”을 직접 하지 않고, TCP 통신(포트 502) 소켓 송수신을 담당합니다. 변환 로직(MBAP 처리, CRC 생성/검증)은 RP2040에서 수행하고, 결과 프레임을 소켓으로 보내는 구조가 일반적입니다. 역할 분리가 명확해 디버깅과 안정화에도 유리합니다.

3) USB 설정 기능을 별도로 둔 이유는 뭔가요?

현장에서는 IP/게이트웨이/보드레이트 같은 설정 변경이 빈번합니다. USB 설정 채널을 별도 태스크/코어로 분리하면, Modbus 트래픽이 많아도 설정 응답성이 유지되고, 반대로 설정 변경 과정이 데이터 변환 타이밍에 영향을 덜 주게 됩니다. 이는 “운영 편의성 + 실시간성”을 동시에 잡는 패턴입니다.

4) 초보자가 따라 하려면 어떤 부분이 가장 어렵나요?

가장 까다로운 부분은 RTU 측입니다. RS-485는 반이중이며 현장 노이즈/응답 지연이 존재하므로, 프레임 경계/타임아웃/재시도 정책이 중요합니다. 또한 TCP의 트랜잭션 ID가 RTU 응답과 정확히 매칭되도록 설계해야 게이트웨이가 “엉뚱한 응답”을 반환하지 않습니다. 이 부분이 시스템 신뢰성을 좌우합니다.

5) LwIP(소프트 스택)나 Wi-Fi(ESP32)와 비교하면 어떤 차이가 있나요?

LwIP 기반은 유연하지만 스택 튜닝과 메모리/CPU 부담이 늘 수 있고, Wi-Fi는 설치 편의성이 있지만 무선 환경 변동으로 지연/신뢰성이 흔들릴 수 있습니다. W55RP20(W5500)은 유선 이더넷 기반의 예측 가능한 통신과 하드웨어 소켓 기반 단순화가 장점이라, 산업용 Modbus 게이트웨이와 잘 맞습니다.

What the project does

This project is an industrial gateway firmware that connects a Modbus TCP network (Ethernet) to Modbus RTU devices (RS-485).

It converts Modbus requests received over TCP (Ethernet) into Modbus RTU frames (including CRC) and forwards them over RS-485.

It receives responses from RS-485, repackages them into Modbus TCP responses (including the MBAP header), and sends them back over the network.

It allows changing network/UART settings via USB serial, then saves the settings to flash and applies them after a reboot.

Image source: AI-generated

Technical role of WIZnet (W55RP20 / W5500)

The key point of this design is using the W5500 hardware TCP/IP stack (hardware sockets) inside the W55RP20, so the MCU can focus on core gateway tasks—such as Modbus conversion, timeouts, and queue handling—rather than implementing a full software network stack.

Reliably maintains a TCP server (port 502)

Reduces implementation complexity and MCU load through socket-based I/O, contributing to predictable latency and stability

Well-suited for gateways where simultaneous network + serial processing is critical

System architecture (tasks / cores)

Based on the description, the project uses a FreeRTOS multicore split:

Core 0: USB communication and configuration management (provisioning/command handling)

Core 1: Modbus TCP server + RTU communication (gateway data path)

The advantage of this structure is that even under heavy traffic, the configuration channel (USB) and the conversion path (TCP ↔ RTU) are less likely to block each other.

Image source: AI-generated

Operation flow (without code-level details)

On boot

Load settings from flash

Initialize Ethernet (W5500)

Initialize UART / RS-485

Create tasks and enter the conversion loop

TCP → RTU conversion

Receive a Modbus TCP frame from the TCP socket

Remove MBAP header → build RTU PDU → add CRC-16

Push into a queue and transmit over RS-485

RTU → TCP conversion

Receive a response from RS-485 (with timeout applied)

Remove/verify CRC → rebuild MBAP header (transaction matching) → send over TCP

Image source: AI-generated

Key parameters (based on the description)

Data buffer: 1024 bytes

Queue size: 3 messages

RTU timeout: 2000 ms

Default baud rate: 9600 bps

Example stack sizes: TCP server 8192B, RTU 1024B (tunable depending on implementation)

FAQ (WIZnet-focused)

1) Why is it beneficial to build a Modbus gateway with W55RP20 (W5500)?

A gateway must handle TCP socket maintenance, RS-485 timing, CRC processing, and settings storage at the same time. The W55RP20’s W5500 hardware TCP/IP offloads socket handling, reducing MCU resource usage and helping the firmware run industrial conversions more reliably—especially when RTU timing is sensitive to timeout and latency variations.

2) What exactly does the W5500 do in this project?

The W5500 does not perform the Modbus conversion itself. It handles TCP communication (port 502) socket TX/RX. The conversion logic—MBAP handling and CRC generation/verification—runs on the RP2040, and the processed frames are transmitted via the W5500 socket interface. This clear separation of responsibilities also helps debugging and stabilization.

3) Why is the USB configuration function separated?

In the field, settings like IP/gateway/baud rate often change. Separating the USB configuration channel into a dedicated task/core keeps configuration responsiveness even under heavy Modbus traffic, while minimizing the impact of configuration operations on real-time conversion timing. It’s a practical pattern that balances operational convenience and deterministic behavior.

4) What is the hardest part for beginners to replicate?

The RTU side is the trickiest. RS-485 is half-duplex and subject to field noise and response delays, so frame boundaries, timeout handling, and retry policies matter. Also, the TCP transaction ID must be correctly matched to the RTU response—otherwise the gateway may return the wrong response, which directly impacts system reliability.

5) How does this compare with LwIP (software stack) or Wi-Fi (ESP32)?

LwIP is flexible but can require more stack tuning and may increase memory/CPU load. Wi-Fi modules can simplify installation, but wireless variability can hurt latency and reliability in industrial control. W55RP20 (W5500) offers predictable wired Ethernet behavior and a simplified design through hardware socket offload, making it a strong fit for industrial Modbus gateways.