How to Build a Multi-Protocol Ethernet Stack with W5500 on STM32F103?

Summary

This project uses an STM32F103C8T6 with a W5500 Ethernet controller to build a wired embedded node that supports UDP, TCP server, TCP client, MQTT, HTTP, DHCP, and DNS. In this design, the W5500 is the network endpoint that exposes socket-oriented Ethernet services over SPI, while the STM32 handles application logic, scheduling, and protocol orchestration. The linked article is clearly about W5500, even though your search URL includes w6300; the page title, code, and configuration all point to W5500.

What the Project Does

The article describes a complete STM32F103 + W5500 project rather than a single echo demo. It explicitly says the platform implements UDP, TCP server, TCP client, MQTT, HTTP, DHCP, and DNS, and links to a GitHub repository named hub-yu/ModbusDevice for the full project.

From a network-stack perspective, the flow is practical and educational. The article starts with direct register access to verify hardware first, then moves to WIZnet’s official ioLibrary port, and finally shows a TCP client example on STM32F103C8T6. That progression is useful for education because it teaches the stack in layers: SPI access, chip reset and register verification, WIZnet driver integration, then socket-based networking.

The visible code shows the system writing MAC, gateway, subnet mask, and IP directly into W5500 registers, then later transitioning to ioLibrary-based socket APIs. That means the project is not treating W5500 as a black box. It teaches both the low-level register model and the higher-level socket model, which is exactly the right structure for learning embedded Ethernet.

Where WIZnet Fits

The exact WIZnet product here is the W5500. Its role is the SPI-connected Ethernet controller and hardwired TCP/IP engine underneath the STM32 application. WIZnet’s official datasheet states that W5500 supports eight independent hardware sockets and uses SPI up to 80 MHz, which explains why it fits a small MCU platform like STM32F103 well.

In this project, the W5500 sits between the Ethernet cable and the MCU firmware. The MCU supplies SPI transport, chip-select handling, reset control, and application logic, while the W5500 handles Ethernet-side transport functions through its socket model. That is the main architectural value here: the STM32 can learn and use network services without carrying a full software Ethernet stack itself.

For education, this is a strong fit because the project makes the interface boundary explicit. Students can see the hardware validation path, the callback registration path in ioLibrary, and the final socket-based application path, all in one flow.

Implementation Notes

This project does use WIZnet products, and the article shows real W5500 code inline.

A short verified snippet from the article’s hardware-check phase writes directly to W5500 network registers:

wiz_write_buf(0x000900, mac, 6);
wiz_write_buf(0x000100, gateway, 4);
wiz_write_buf(0x000500, mask, 4);
wiz_write_buf(0x000F00, ip, 4);

Why it matters: this proves the project is doing real W5500 register-level configuration, not just describing the chip conceptually. It also shows the teaching intent clearly: validate the chip and network identity before moving to library integration.

A second verified implementation step appears in the ioLibrary porting section. The article explicitly shows wizchip_conf.h being set to:

#define _WIZCHIP_ W5500
#define _WIZCHIP_IO_MODE_ _WIZCHIP_IO_MODE_SPI_

Why it matters: this is the architectural handoff from direct register access to WIZnet’s official driver stack. It confirms the project is built around the W5500-specific ioLibrary path rather than a generic Ethernet abstraction.

The STM32F103 hardware mapping is also explicit in the article’s TCP client example: MOSI on PB15, MISO on PB14, SCK on PB13, CS on PB12, and RESET on PB11, with INT unused. That makes the platform boundary concrete for learners.

Practical Tips / Pitfalls

Verify hardware first with direct register read/write and ping before porting the full ioLibrary. The article uses exactly that sequence.

Keep CS and RESET on dedicated GPIOs. In this project they are PB12 and PB11, and they are central to reliable bring-up.

Do not skip chip selection in wizchip_conf.h; the article explicitly sets _WIZCHIP_ to W5500, not another WIZnet device.

Start with static IP during bring-up. The article writes fixed gateway, mask, and IP values directly before introducing higher-level services.

Learn the register layer before the socket layer. This project is strongest as an education example because it shows both.

FAQ

Why use W5500 for this project?
Because the project needs a small MCU to run multiple Ethernet services without implementing the full transport stack in software. W5500 provides a hardware socket model, and the official datasheet specifies eight hardware sockets plus SPI connectivity suited to MCU integration.

How does it connect to the platform?
Through SPI on STM32F103C8T6. The article maps MOSI to PB15, MISO to PB14, SCK to PB13, CS to PB12, and RESET to PB11.

What role does it play in this specific project?
It is the actual Ethernet engine underneath the application. The project writes network identity into W5500 registers, ports ioLibrary to the target board, and then uses W5500 socket APIs for TCP-based communication.

Can beginners follow this project?
Yes, especially for education, because the article teaches in the right order: hardware verification first, driver port second, socket example third. It is better suited to learners with basic STM32 GPIO and SPI knowledge than to absolute beginners.

How does this compare with Wi-Fi or a pure software stack?
A Wi-Fi path may be easier for wireless deployment, but this project is about stable wired Ethernet and explicit socket control. Compared with a pure software Ethernet stack, W5500 moves transport work into hardware, which is a better fit for STM32F103-class systems. The article presents this as a complete wired protocol platform, and WIZnet’s datasheet supports that hardware-offload model.

Source

Original article: CSDN post “w5500 一篇就够了”, published September 5, 2025, under CC 4.0 BY-SA. The article links the hub-yu/ModbusDevice repository and WIZnet’s official ioLibrary_Driver.

Tags

W5500, WIZnet, STM32F103, Ethernet, SPI, TCP Client, UDP, MQTT, HTTP, DHCP, DNS, Education

STM32F103에서 W5500으로 멀티프로토콜 이더넷 스택을 어떻게 구축할 수 있을까?

Summary

이 프로젝트는 STM32F103C8T6와 W5500 이더넷 컨트롤러를 사용해 UDP, TCP 서버, TCP 클라이언트, MQTT, HTTP, DHCP, DNS를 지원하는 유선 임베디드 노드를 구성한다. 이 구조에서 W5500은 SPI 위에서 소켓 지향 이더넷 서비스를 제공하는 네트워크 엔드포인트 역할을 하고, STM32는 애플리케이션 로직, 스케줄링, 프로토콜 오케스트레이션을 담당한다. 참고로 검색 URL에는 w6300이 포함되어 있지만, 실제 페이지 제목과 코드, 설정 내용은 모두 W5500을 가리킨다.

What the Project Does

이 글은 단순한 에코 예제가 아니라 STM32F103 + W5500 기반의 완성도 있는 프로젝트를 설명한다. 글에서는 UDP, TCP 서버, TCP 클라이언트, MQTT, HTTP, DHCP, DNS를 구현한다고 명시하며, 전체 프로젝트용 GitHub 저장소 hub-yu/ModbusDevice도 함께 연결하고 있다.

네트워크 스택 관점에서 이 프로젝트의 가장 교육적인 부분은 진행 순서다. 먼저 직접 레지스터 접근으로 하드웨어를 검증하고, 그다음 WIZnet 공식 ioLibrary를 포팅한 뒤, 마지막으로 STM32F103C8T6에서 TCP 클라이언트 예제를 실행한다. 이 흐름은 교육용으로 매우 적절하다. SPI 접근, 칩 리셋과 레지스터 검증, WIZnet 드라이버 통합, 그리고 최종적으로 소켓 기반 네트워킹까지 계층적으로 배울 수 있기 때문이다.

가시적인 코드 역시 W5500을 블랙박스로 다루지 않는다. 시스템은 MAC 주소, 게이트웨이, 서브넷 마스크, IP 주소를 직접 W5500 레지스터에 기록한 뒤, 이후 ioLibrary 기반 소켓 API로 넘어간다. 즉, 이 프로젝트는 W5500의 저수준 레지스터 모델과 상위 소켓 모델을 모두 보여주며, 임베디드 이더넷 학습에 매우 적합한 구조를 갖는다.

Where WIZnet Fits

여기서 사용된 정확한 WIZnet 제품은 W5500이다. 역할은 STM32 애플리케이션 아래에서 동작하는 SPI 연결 이더넷 컨트롤러이자 하드와이어드 TCP/IP 엔진이다. WIZnet 공식 데이터시트에 따르면 W5500은 8개의 독립 하드웨어 소켓을 지원하며, 최대 80 MHz SPI를 사용할 수 있다. 이런 특성 때문에 STM32F103 같은 소형 MCU와 잘 맞는다.

이 프로젝트에서 W5500은 이더넷 케이블과 MCU 펌웨어 사이에 위치한다. MCU는 SPI 전송, 칩 셀렉트, 리셋 제어, 애플리케이션 로직을 담당하고, W5500은 이더넷 측 전송 기능을 소켓 모델로 제공한다. 이 구조의 핵심 가치는 STM32가 전체 소프트웨어 이더넷 스택을 직접 구현하지 않고도 네트워크 서비스를 사용할 수 있다는 데 있다.

교육용 관점에서도 매우 적절하다. 학생은 하드웨어 검증 경로, ioLibrary 콜백 등록 경로, 최종 소켓 기반 애플리케이션 경로를 하나의 흐름 안에서 모두 볼 수 있다.

Implementation Notes

이 프로젝트는 실제로 WIZnet 제품을 사용하며, 글에는 실제 W5500 코드 조각이 포함되어 있다.

하드웨어 검증 단계에서 글은 W5500 네트워크 레지스터에 직접 쓰는 코드를 보여준다.

wiz_write_buf(0x000900, mac, 6);
wiz_write_buf(0x000100, gateway, 4);
wiz_write_buf(0x000500, mask, 4);
wiz_write_buf(0x000F00, ip, 4);

이 코드가 중요한 이유는, 프로젝트가 단순히 W5500을 개념적으로 설명하는 것이 아니라 실제로 레지스터 수준 설정을 수행하고 있음을 보여주기 때문이다. 또한 네트워크 정체성을 먼저 설정한 뒤 라이브러리 통합으로 넘어간다는 교육 의도도 분명하다.

두 번째 중요한 구현 단계는 ioLibrary 포팅 부분이다. 글은 wizchip_conf.h를 다음과 같이 설정한다고 명시한다.

#define _WIZCHIP_ W5500
#define _WIZCHIP_IO_MODE_ _WIZCHIP_IO_MODE_SPI_

이 설정이 중요한 이유는, 여기서 직접 레지스터 접근에서 WIZnet 공식 드라이버 스택으로 아키텍처가 넘어가기 때문이다. 또한 이 프로젝트가 범용 이더넷 추상화가 아니라 W5500 전용 ioLibrary 경로 위에 구축되어 있음을 확인시켜 준다.

STM32F103 하드웨어 매핑도 글에서 분명히 제시된다. TCP 클라이언트 예제 기준으로 MOSI는 PB15, MISO는 PB14, SCK는 PB13, CS는 PB12, RESET은 PB11이며, INT는 사용하지 않는다. 이 정보는 학습자에게 플랫폼 경계를 매우 구체적으로 보여준다.

Practical Tips / Pitfalls

먼저 직접 레지스터 읽기/쓰기와 ping 테스트로 하드웨어를 검증한 뒤, 그다음 ioLibrary를 포팅하는 편이 좋다. 글도 정확히 이 순서를 따른다.

CS와 RESET은 전용 GPIO로 분리하는 것이 좋다. 이 프로젝트에서는 PB12와 PB11이 핵심이며, 초기 구동 안정성에 직접 영향을 준다.

wizchip_conf.h에서 칩 선택을 정확히 해야 한다. 이 글은 _WIZCHIP_을 W5500으로 분명히 지정하며, 다른 WIZnet 칩과 혼용하지 않는다.

초기 구동 단계에서는 고정 IP로 시작하는 편이 좋다. 이 글도 먼저 고정된 gateway, mask, IP를 직접 기록한 뒤 상위 서비스를 올린다.

소켓 계층으로 가기 전에 레지스터 계층을 먼저 이해하는 것이 좋다. 이 프로젝트는 교육 예제로서 특히 이 점이 강하다. 두 계층을 모두 보여주기 때문이다.

FAQ

왜 이 프로젝트에 W5500을 사용하는가?
이 프로젝트는 작은 MCU에서 여러 이더넷 서비스를 처리해야 하며, 전체 전송 스택을 소프트웨어로 직접 구현하지 않으려는 목적을 갖는다. W5500은 하드웨어 소켓 모델을 제공하며, 공식 데이터시트 기준으로 8개의 하드웨어 소켓과 MCU 친화적인 SPI 인터페이스를 제공하기 때문에 적합하다.

플랫폼과는 어떻게 연결되는가?
STM32F103C8T6와 SPI로 연결된다. 글에서는 MOSI를 PB15, MISO를 PB14, SCK를 PB13, CS를 PB12, RESET을 PB11로 매핑한다.

이 프로젝트에서 W5500의 구체적인 역할은 무엇인가?
애플리케이션 아래에서 실제 이더넷 엔진 역할을 한다. 프로젝트는 먼저 W5500 레지스터에 네트워크 정보를 기록하고, 이후 ioLibrary를 타깃 보드에 포팅한 다음, W5500 소켓 API를 이용해 TCP 기반 통신을 수행한다.

초보자도 따라갈 수 있는가?
가능하다. 특히 교육용으로 적합하다. 글은 하드웨어 검증, 드라이버 포팅, 소켓 예제 실행이라는 올바른 순서로 설명한다. 다만 완전 초보보다는 기본적인 STM32 GPIO와 SPI를 알고 있는 학습자에게 더 잘 맞는다.

Wi-Fi나 순수 소프트웨어 스택과 비교하면 어떤 차이가 있는가?
Wi-Fi는 무선 배포에는 편리하지만, 이 프로젝트는 안정적인 유선 이더넷과 명시적인 소켓 제어를 목표로 한다. 순수 소프트웨어 이더넷 스택과 비교하면 W5500은 전송 작업을 하드웨어로 넘기므로 STM32F103 같은 MCU에 더 잘 맞는다. 글은 이를 완성형 유선 프로토콜 플랫폼으로 제시하고 있으며, WIZnet 데이터시트도 이런 하드웨어 오프로딩 모델을 뒷받침한다.

Source

원문 출처: CSDN 글 “w5500 一篇就够了”, 2025년 9월 5일 게시, CC 4.0 BY-SA.
글에서는 hub-yu/ModbusDevice 저장소와 WIZnet 공식 ioLibrary_Driver도 함께 참조한다.

Tags

W5500, WIZnet, STM32F103, Ethernet, SPI, TCP Client, UDP, MQTT, HTTP, DHCP, DNS, Education