How to Build an Industrial Ethernet Socket Stack with W5500 on STM32F103?

Summary

This project uses an STM32F103C8T6 with a W5500 Ethernet controller to build a small wired networking platform that can run UDP, TCP server, TCP client, MQTT, HTTP, DHCP, and DNS functions. In this design, the W5500 is not just a PHY attachment; it is the network endpoint that exposes socket-level services over SPI so the MCU can focus on device logic, protocol handling, and application scheduling.

What the Project Does

The source describes a multi-protocol embedded node built around STM32F103 and W5500, with the linked repository organized as a device/board project rather than a single demo. The CSDN article states that the platform implements UDP, TCP server, TCP client, MQTT, HTTP, DHCP, and DNS, while the repository README shows a register-mapped device model with configurable IP, gateway, mask, DNS, per-channel ports, remote IP/domain settings, and multiple channel types including UDP, TCP server, TCP client, and MQTT. That combination makes it fit Industrial IoT, education, and maker use equally well: the same hardware can act as a teachable socket platform, a small field device, or a configurable Ethernet gateway node.

At the data-flow level, the STM32 initializes the board, starts FreeRTOS, configures the W5500 over SPI, then uses socket-oriented APIs to move payloads between Ethernet and the local application. In the article’s TCP client example, the node sets local network parameters, opens a TCP socket, connects to a remote server, receives data, and echoes it back. In the repository, the network layer also pulls in DHCP, DNS, HTTP utilities, and an MQTT client, which shows that the architecture is intended to scale past a single echo test into a configurable multi-service device.

Where WIZnet Fits

The exact WIZnet part here is the W5500. Its role is the Ethernet controller and hardwired TCP/IP engine connected to the STM32 through SPI, with integrated MAC/PHY and socket-based networking support. WIZnet’s own documentation describes the W5500 as a hardwired TCP/IP stack controller for external MCUs over SPI up to 80 MHz, and its datasheet highlights 32 KB of internal memory and support for eight hardware sockets. Those characteristics explain why it is a practical fit for an STM32F103-class design: it reduces firmware burden on a small MCU, avoids dragging a full software TCP/IP stack into RAM and flash, and gives a predictable socket model that is easier to teach and maintain in Industrial IoT firmware.

In this project, the W5500 is positioned as the transport boundary between field Ethernet and the application logic. The MCU still owns product behavior, register mapping, protocol selection, and task scheduling, but the W5500 owns packet transport, link handling, and socket state machinery. That split is especially useful when you need stable wired networking on modest hardware, deterministic behavior compared with Wi-Fi, and simpler integration for learners who need working TCP/UDP services without first mastering a full embedded IP stack.

Implementation Notes

This project does use WIZnet products, and the available source shows real W5500 integration.

Snippet 1 — Application/BoardSocket/Source/net.c
The network layer includes W5500 and ioLibrary headers directly:

#include "w5500.h" #include "socket.h" #include "wizchip_conf.h" #include "dhcp.h" #include "dns.h" #include "httpUtil.h" #include "MQTTClient.h"

Why it matters: this is the architectural center of the design. It shows that the W5500 is not being treated as a raw MAC/PHY peripheral; the firmware is built around WIZnet’s socket abstraction and then layers DHCP, DNS, HTTP, and MQTT services on top of it.

Snippet 2 — Application/BoardSocket/Source/net.c and the article’s STM32 example
The runtime registration and socket path are explicit:

reg_wizchip_cs_cbfunc(cs_sel, cs_desel);
reg_wizchip_spi_cbfunc(spi_read, spi_write);
LOG_INFO("socket %d\r\n", socket(1, Sn_MR_TCP, 0, Sn_MR_ND));
LOG_INFO("connect %d\r\n", connect(1, remote_ip, 5000));

Why it matters: these calls bind the MCU’s board-specific SPI and chip-select routines to the ioLibrary, then open a real hardware-backed TCP socket on the W5500. In other words, the transport stack boundary is clear: board code supplies SPI access, W5500 supplies socket services, and the application consumes those services.

The hardware mapping in the article is also concrete: MOSI on PB15, MISO on PB14, SCK on PB13, CS on PB12, and RESET on PB11, all through SPI2 on the STM32F103. The same example configures SPI2 and toggles RESET/CS in firmware, which is the minimum board support package needed before any higher-level protocol can work.

Practical Tips / Pitfalls

Verify SPI wiring and reset timing first. The article explicitly recommends direct register access and ping testing before porting the full library, which is the right order for bring-up.

Keep CS and RESET on dedicated GPIOs with clean control paths. In the example, PB12 is CS and PB11 is RESET; unstable handling here will look like random network failures.

Confirm chip identity early. The sample checks getVERSIONR() against 0x04, which is a useful sanity check before blaming DHCP, TCP, or MQTT layers.

Start with static IP during board bring-up, then enable DHCP later. The article’s early tests use fixed MAC/IP/gateway/mask values, which removes one variable while validating link and socket behavior.

Plan socket usage deliberately. The W5500 supports eight hardware sockets, but the repository’s device model already assigns per-channel ports and channel roles, so careless feature growth can turn into buffer and state-management problems.

Use the interrupt pin when moving beyond polling demos. The repository includes an external interrupt handler for W5500 events; that is the better path once latency and CPU efficiency matter.

FAQ

Why use the W5500 here instead of a pure software stack on STM32F103?
Because this project needs multiple Ethernet services on a relatively small MCU. The W5500 provides a hardwired TCP/IP stack, socket interface, integrated MAC/PHY, and internal packet memory, which reduces the firmware and RAM burden compared with pulling a full software TCP/IP stack into the STM32F103. That is a good trade when the product is a field node or teaching platform rather than a general-purpose Linux-class endpoint.

How does the W5500 connect to the STM32F103 in this project?
Over SPI2. The article maps PB15 to MOSI, PB14 to MISO, PB13 to SCK, PB12 to chip select, and PB11 to reset. The firmware then registers SPI read/write and chip-select callbacks with WIZnet’s ioLibrary so socket operations can ride on top of those board-level functions.

What role does the W5500 play in this specific system?
It is the wired transport engine for the whole board. The repository’s network layer includes socket, DHCP, DNS, HTTP, and MQTT components around the W5500, while the device model exposes configurable network channels and parameters. That means the W5500 is the networking core that turns the board into a configurable Ethernet device rather than a one-off demo peripheral.

Can beginners follow this project?
Yes, but it is not a first-ever embedded exercise. It is approachable for education and maker use if the learner already understands basic STM32 GPIO/SPI setup and can read simple socket logic. The article is helpful because it starts with low-level register verification before moving to ioLibrary integration, which is exactly the right learning sequence.

How does this compare with ENC28J60 or a Wi-Fi module?
Compared with ENC28J60, the W5500 gives you socket-oriented hardware TCP/IP offload instead of a lower-level Ethernet controller that leaves more of the protocol burden to firmware. Compared with Wi-Fi modules, the W5500 gives deterministic wired Ethernet behavior, simpler EMI and provisioning concerns, and a better fit for cabinet, factory, or lab networks where cable reliability matters more than wireless convenience.

Source

Original article: CSDN blog post “w5500 一篇就够了.” License listed on the page: CC 4.0 BY-SA. The article also links the implementation repository hub-yu/ModbusDevice and references WIZnet’s official ioLibrary_Driver.

Tags

W5500, WIZnet, STM32F103, Ethernet, SPI, TCP Client, Industrial IoT, Embedded Networking, ioLibrary, MQTT, Modbus Device, Maker Education

STM32F103에서 W5500으로 산업용 이더넷 소켓 스택을 어떻게 구축할 수 있을까?

Summary

이 프로젝트는 STM32F103C8T6와 W5500 이더넷 컨트롤러를 사용해 UDP, TCP 서버, TCP 클라이언트, MQTT, HTTP, DHCP, DNS 기능을 구동할 수 있는 소형 유선 네트워크 플랫폼을 구성한다. 이 구조에서 W5500은 단순한 PHY 보조 칩이 아니라, MCU가 장치 로직·프로토콜 처리·애플리케이션 스케줄링에 집중할 수 있도록 SPI 기반 소켓 서비스를 제공하는 네트워크 종단 역할을 맡는다.

What the Project Does

이 소스는 STM32F103과 W5500을 중심으로 구성된 멀티프로토콜 임베디드 노드를 설명한다. 연결된 저장소 역시 단일 데모가 아니라 장치/보드 프로젝트 구조로 정리되어 있다. CSDN 글에서는 이 플랫폼이 UDP, TCP 서버, TCP 클라이언트, MQTT, HTTP, DHCP, DNS를 구현한다고 설명하며, 저장소 README에는 IP, 게이트웨이, 서브넷 마스크, DNS, 채널별 포트, 원격 IP/도메인 설정, UDP/TCP 서버/TCP 클라이언트/MQTT 같은 여러 채널 타입이 포함된 레지스터 기반 장치 모델이 보인다. 이 조합은 Industrial IoT, 교육, 메이커 용도에 모두 잘 맞는다. 동일한 하드웨어를 교육용 소켓 학습 플랫폼으로도, 소형 현장 장치로도, 구성 가능한 이더넷 게이트웨이 노드로도 사용할 수 있기 때문이다.

데이터 흐름 관점에서 보면 STM32는 보드를 초기화하고 FreeRTOS를 시작한 뒤, SPI를 통해 W5500을 설정하고, 소켓 지향 API를 이용해 이더넷과 로컬 애플리케이션 사이로 페이로드를 주고받는다. 글의 TCP 클라이언트 예제에서는 노드가 로컬 네트워크 파라미터를 설정하고, TCP 소켓을 열고, 원격 서버에 연결한 뒤, 수신 데이터를 받아 다시 에코한다. 저장소에는 DHCP, DNS, HTTP 유틸리티, MQTT 클라이언트까지 포함되어 있으므로, 이 아키텍처는 단순 에코 테스트를 넘어서 구성 가능한 멀티서비스 장치로 확장될 수 있음을 보여준다.

Where WIZnet Fits

여기서 사용된 정확한 WIZnet 부품은 W5500이다. W5500의 역할은 STM32와 SPI로 연결되는 이더넷 컨트롤러이자 하드와이어드 TCP/IP 엔진이며, 내부에 MAC/PHY와 소켓 기반 네트워킹 기능을 포함한다. WIZnet 공식 문서에 따르면 W5500은 외부 MCU용 하드와이어드 TCP/IP 스택 컨트롤러이며 SPI는 최대 80 MHz까지 지원한다. 데이터시트에는 32 KB 내부 메모리와 8개의 하드웨어 소켓도 명시되어 있다. 이런 특성 때문에 W5500은 STM32F103급 설계에 잘 맞는다. 작은 MCU에서 전체 소프트웨어 TCP/IP 스택을 RAM과 Flash에 올릴 필요를 줄여주고, 교육과 유지보수에 유리한 예측 가능한 소켓 모델을 제공하기 때문이다.

이 프로젝트에서 W5500은 필드 이더넷과 애플리케이션 로직 사이의 전송 경계로 배치된다. MCU는 여전히 제품 동작, 레지스터 매핑, 프로토콜 선택, 태스크 스케줄링을 담당하지만, W5500은 패킷 전송, 링크 처리, 소켓 상태 기계를 담당한다. 이런 역할 분리는 비교적 제한된 하드웨어에서 안정적인 유선 네트워킹이 필요할 때, Wi-Fi보다 더 예측 가능한 동작이 필요할 때, 그리고 학습자가 임베디드 IP 스택 전체를 먼저 익히지 않아도 TCP/UDP 서비스를 구현해야 할 때 특히 유용하다.

Implementation Notes

이 프로젝트는 실제로 WIZnet 제품을 사용하며, 확인 가능한 소스에도 W5500 통합이 분명히 나타난다.

Snippet 1 — Application/BoardSocket/Source/net.c
네트워크 계층은 W5500 및 ioLibrary 헤더를 직접 포함한다.

#include "w5500.h" #include "socket.h" #include "wizchip_conf.h" #include "dhcp.h" #include "dns.h" #include "httpUtil.h" #include "MQTTClient.h"

이 코드가 중요한 이유는 아키텍처 중심이 여기에 있기 때문이다. 즉, 펌웨어가 W5500을 단순한 MAC/PHY 주변장치처럼 다루는 것이 아니라, WIZnet 소켓 추상화를 중심에 두고 그 위에 DHCP, DNS, HTTP, MQTT 서비스를 쌓고 있음을 보여준다.

Snippet 2 — Application/BoardSocket/Source/net.c 및 글의 STM32 예제
런타임 등록과 소켓 경로도 분명하게 드러난다.

reg_wizchip_cs_cbfunc(cs_sel, cs_desel);
reg_wizchip_spi_cbfunc(spi_read, spi_write);
LOG_INFO("socket %d\r\n", socket(1, Sn_MR_TCP, 0, Sn_MR_ND));
LOG_INFO("connect %d\r\n", connect(1, remote_ip, 5000));

이 코드가 중요한 이유는 MCU의 보드별 SPI 및 칩 셀렉트 루틴을 ioLibrary에 연결한 뒤, W5500 위에서 실제 하드웨어 기반 TCP 소켓을 여는 과정을 보여주기 때문이다. 즉, 전송 계층 경계가 분명하다. 보드 코드는 SPI 접근을 제공하고, W5500은 소켓 서비스를 제공하며, 애플리케이션은 그 소켓 서비스를 사용한다.

글의 하드웨어 매핑도 구체적이다. MOSI는 PB15, MISO는 PB14, SCK는 PB13, CS는 PB12, RESET은 PB11이며, 모두 STM32F103의 SPI2에 연결된다. 예제 펌웨어는 SPI2를 초기화하고 RESET/CS를 제어한다. 이는 상위 프로토콜이 동작하기 전에 반드시 준비되어야 하는 최소 보드 지원 계층이다.

Practical Tips / Pitfalls

먼저 SPI 배선과 리셋 타이밍부터 검증하는 것이 좋다. 글에서도 전체 라이브러리 포팅 전에 직접 레지스터 접근과 ping 테스트를 먼저 하라고 권장하는데, 실제로 이 순서가 가장 안전하다.

CS와 RESET은 전용 GPIO로 두고 제어 경로를 단순하게 유지하는 편이 좋다. 예제에서는 PB12가 CS, PB11이 RESET인데, 여기서 흔들리면 네트워크 문제처럼 보이는 불규칙 오류가 발생한다.

칩 식별 확인을 초기에 넣는 것이 좋다. 예제는 getVERSIONR() 값을 0x04와 비교하는데, DHCP나 TCP, MQTT를 의심하기 전에 하드웨어 인식부터 확인하는 데 유용하다.

보드 초기 구동 단계에서는 정적 IP를 먼저 쓰고, 이후 DHCP를 붙이는 편이 낫다. 글의 초기 테스트도 고정 MAC/IP/게이트웨이/마스크를 사용하며, 이렇게 해야 링크와 소켓 동작을 먼저 검증할 수 있다.

소켓 사용 계획을 미리 정리해야 한다. W5500은 8개의 하드웨어 소켓을 제공하지만, 저장소의 장치 모델은 이미 채널별 포트와 채널 역할을 나누고 있어 기능이 늘어나면 버퍼와 상태 관리가 복잡해질 수 있다.

폴링 기반 데모를 넘어서려면 인터럽트 핀 사용을 고려하는 것이 좋다. 저장소에는 W5500 이벤트를 처리하는 외부 인터럽트 핸들러도 포함되어 있으며, 지연 시간과 CPU 효율이 중요해질수록 이 방식이 더 적절하다.

FAQ

왜 이 프로젝트에서 순수 소프트웨어 스택 대신 W5500을 써야 할까?
이 프로젝트는 비교적 작은 MCU에서 여러 이더넷 서비스를 동시에 처리해야 한다. W5500은 하드와이어드 TCP/IP 스택, 소켓 인터페이스, 내장 MAC/PHY, 내부 패킷 메모리를 제공하므로 STM32F103에 전체 소프트웨어 TCP/IP 스택을 올리는 것보다 펌웨어와 RAM 부담을 줄일 수 있다. 범용 리눅스급 엔드포인트가 아니라 현장 노드나 교육 플랫폼을 만드는 목적이라면 이 선택이 기술적으로 타당하다.

이 프로젝트에서 W5500은 STM32F103과 어떻게 연결되는가?
SPI2로 연결된다. 글에서는 PB15를 MOSI, PB14를 MISO, PB13을 SCK, PB12를 CS, PB11을 RESET으로 매핑한다. 이후 펌웨어는 SPI 읽기/쓰기와 칩 셀렉트 콜백을 WIZnet ioLibrary에 등록하고, 그 위에서 소켓 연산을 수행한다.

이 시스템에서 W5500의 구체적인 역할은 무엇인가?
보드 전체의 유선 전송 엔진 역할이다. 저장소의 네트워크 계층은 W5500을 중심으로 socket, DHCP, DNS, HTTP, MQTT 컴포넌트를 묶고 있고, 장치 모델은 구성 가능한 네트워크 채널과 파라미터를 제공한다. 즉, W5500은 이 보드를 단순 데모 주변장치가 아니라 구성 가능한 이더넷 장치로 바꾸는 핵심 네트워크 블록이다.

초보자도 이 프로젝트를 따라갈 수 있을까?
가능하지만 완전 입문용이라고 보기는 어렵다. 기본적인 STM32 GPIO/SPI 설정을 이해하고 단순한 소켓 흐름을 읽을 수 있다면 교육용이나 메이커 용도로 충분히 접근 가능하다. 특히 이 글은 저수준 레지스터 검증부터 시작해 ioLibrary 통합으로 올라가므로 학습 순서가 적절하다.

ENC28J60이나 Wi-Fi 모듈과 비교하면 어떤 차이가 있을까?
ENC28J60과 비교하면 W5500은 더 낮은 레벨의 이더넷 컨트롤러가 아니라 소켓 지향 하드웨어 TCP/IP 오프로딩을 제공한다. 따라서 프로토콜 부담이 MCU 쪽에 덜 간다. Wi-Fi 모듈과 비교하면 W5500은 유선 이더넷 기반이라 동작 예측성이 높고, EMI나 무선 설정 문제를 줄일 수 있으며, 캐비닛 내부·공장·실험실처럼 케이블 안정성이 더 중요한 환경에 잘 맞는다.

Source

원문 출처: CSDN 블로그 게시물 “w5500 一篇就够了.”
페이지에 표시된 라이선스: CC 4.0 BY-SA.
글에서는 구현 저장소 hub-yu/ModbusDevice와 WIZnet 공식 ioLibrary_Driver도 함께 참조한다.