Wiznet makers

Overview

zp492 is a GitHub maker account with a small public repository set and no public name, country, company, or email listed on the profile. This project is a STM32F103 wired IoT terminal that adds a WIZnet W5500 SPI port, runs FreeRTOS tasks, and sends sensor telemetry to OneNET through a custom MQTT 3.1.1 client.

Generated technical diagram: the article focuses on a STM32F103 application path from FreeRTOS tasks through W5500 hardware sockets to OneNET MQTT.

The repository is useful because the W5500 integration is not just a wiring note. The code includes w5500_port.c for SPI callbacks and chip initialization, transport.c for WIZnet socket transport, mqtt_client.c for MQTT packet encoding and parsing, mqtt_wrapper.c for connection and publish logic, and onenet.c for China Mobile OneNET topic and payload formatting.

The README also describes OTA remote upgrade, but the inspected source does not include a complete HTTP download and bootloader update path. For that reason, this article treats OTA as documented or planned scope and focuses on the confirmed W5500 and MQTT implementation.

System Configuration

The hardware target is an STM32F103ZET6 development board with a W5500 Ethernet module, a DHT11 temperature and humidity sensor, LCD, LEDs, keys, and external SRAM support. The README mentions STM32F103C8T6 and DHT22, but the code and pinout document identify the larger STM32F103ZE class board and DHT11 on PG11.

The W5500 is connected through SPI2. The pinout document maps PB12 to chip select, PB13 to SCK, PB14 to MISO, PB15 to MOSI, PD6 to reset, and PA2 to the W5500 interrupt input. The interrupt pin is documented as currently unused, so link monitoring is done by polling PHY status.

The software side is built for Keil MDK and includes STM32F1 HAL, FreeRTOS, WIZnet ioLibrary style driver files, a custom MQTT client, and a OneNET adapter. FreeRTOS creates sensor, MQTT, LED, and W5500 monitor tasks. Sensor data is sent through a queue to the MQTT task, while a semaphore gates MQTT connection attempts until the Ethernet link is ready.

System Architecture and Data Flow

The data path starts at the DHT11 sensor and the FreeRTOS sensor task. The MQTT task consumes queued sensor readings, formats OneNET JSON datapoints, and sends MQTT packets over WIZnet Socket 1. The W5500 monitor task polls PHY link state every 500 ms and updates the semaphore and LED state when the cable is inserted or removed.

Generated technical diagram: sensor data moves from the DHT11 task into the MQTT task, then through W5500 Socket 1 to OneNET topics and command payloads.

The OneNET adapter configures the broker endpoint as 183.230.40.96:1883, uses the device ID as the MQTT client ID, and publishes to $sys/{pid}/{did}/dp/post/json. It also subscribes to $sys/{pid}/{did}/# so cloud commands can reach the firmware. The command callback currently parses simple JSON strings to control LED0 and LED1.

W5500 Port and Socket Stack

The W5500 port layer is the most important addition in this repository. w5500_port.c registers SPI byte callbacks, SPI burst callbacks, chip-select callbacks, and FreeRTOS critical-section callbacks with the WIZnet driver. It also performs hardware reset, derives a MAC address from the STM32 unique ID, assigns static IPv4 settings, configures PHY auto-negotiation, and raises SPI2 speed to 18 MHz after initialization.

Generated technical diagram: STM32 SPI2 callbacks, w5500_port.c, WIZnet ioLibrary calls, and the MQTT wrapper stay in separate layers.

The transport layer deliberately keeps MQTT separate from the W5500 driver. transport_connect() opens a TCP socket, calls connect(), then polls SO_STATUS until SOCK_ESTABLISHED or timeout. transport_send() wraps WIZnet send(), and transport_recv() polls SO_RECVBUF before calling recv(). The MQTT layer can therefore focus on packet framing, connection state, keepalive, publish, subscribe, and command parsing.

Role of the WIZnet Chip

The W5500 provides the wired TCP/IP path for the terminal. In this firmware, STM32F103 does not run a software TCP/IP stack for MQTT. Instead, the firmware uses the WIZnet socket API and lets the W5500 handle TCP state, packet buffering, retransmission, and Ethernet PHY behavior in hardware.

That matters for a FreeRTOS sensor node because the MCU can keep its application structure simple. One task reads sensors, one task owns MQTT state, one task watches link status, and the W5500 socket API acts as the network boundary. The code also uses separate socket roles: the commit message notes Socket 0 for TCP testing and Socket 1 for MQTT, leaving other sockets available for future services.

This is also a good W5500 porting reference. The implementation shows how to bind WIZnet callbacks to STM32 HAL SPI, how to protect SPI transactions in a FreeRTOS environment, how to allocate W5500 socket buffers, and how to expose a small transport API to a protocol implementation above it.

Current Scope and Limits

The confirmed implementation covers W5500 bring-up, static network configuration, PHY link polling, custom MQTT 3.1.1 packet handling, OneNET authentication fields, datapoint JSON publishing, subscription setup, keepalive, reconnect logic, sensor queue handoff, LCD display, and LED command handling.

Generated technical diagram: the confirmed runtime loop covers link monitoring, sensor telemetry, MQTT publish/subscribe, and LED command parsing; OTA remains documented but not confirmed.

The main limit is OTA. The README describes a bootloader, flash partitioning, HTTP download, validation, and automatic switching, and the system utility comments mention vector-table offset and bootloader scenarios. However, a complete OTA downloader and bootloader implementation were not found in the inspected repository. That makes the repository stronger as a W5500 plus MQTT reference than as a finished OTA reference.

There are also normal bring-up limits. The repo has no hardware photo, schematic, or demo video, and the network configuration is static. Users who reuse the project should adjust IP settings, OneNET credentials, MQTT topics, sensor type, and security handling before deployment.

Where It Fits

This project fits wired IoT terminals, classroom FreeRTOS networking labs, industrial sensor prototypes, and cloud-connected sensor nodes where deterministic Ethernet is preferred over Wi-Fi. It is especially relevant when the reader wants to study how a custom protocol layer can sit on top of WIZnet hardware sockets instead of relying on a large third-party MQTT library.

It also has extension value for future WIZnet examples. The W5500 port layer and transport abstraction could be reused with a different cloud service, a different MQTT broker, or another STM32 board, while the MQTT wrapper can be adapted to add TLS offload alternatives, DHCP, NTP, retained status messages, or a real OTA downloader.

Related WIZnet Maker Projects

• STM32_MQTT_Project is the closest related Maker post because it also combines STM32, W5500, and MQTT. The difference is that this project adds a clearer W5500 port layer, FreeRTOS task structure, and OneNET-specific topic adapter.
• W5500-STM32-cJSON is related through STM32, W5500, and JSON payload handling. That project focuses on cJSON use, while this one focuses on a custom MQTT packet stack and transport wrapper.
• How to Build an Interrupt-Driven W5500 UDP Server on STM32F4 with FreeRTOS and ioLibrary is related as a FreeRTOS and WIZnet ioLibrary reference. It uses STM32F4 and UDP server behavior, while this project uses STM32F103, TCP, MQTT, and cloud telemetry.

FAQ

Q. What does this project use the W5500 for? It uses the W5500 as the wired Ethernet and TCP/IP controller for the STM32F103 terminal. The firmware uses WIZnet socket calls for TCP transport and places the custom MQTT client above that transport layer.

Q. Is the MQTT stack a standard library? No. The repository includes custom MQTT 3.1.1 packet encoding, remaining-length encoding, CONNECT, PUBLISH, SUBSCRIBE, PING, and parsing logic, then wraps it in a FreeRTOS-aware MQTT task.

Q. Does the project prove OTA is complete? Not from the inspected source. OTA is described in the README and related comments, but the full HTTP download and bootloader update implementation was not found.

Q. Why is W5500 useful here instead of using a software TCP/IP stack? The W5500 handles TCP/IP and Ethernet PHY behavior in hardware, so STM32F103 can run application tasks and MQTT state logic without carrying a larger network stack in MCU firmware.

Q. Can this be reused with another broker? Yes. The transport and MQTT layers are separated from the OneNET adapter. A user would need to replace the broker address, credentials, topics, and payload builder.

The source repository, W5500 product page, WIZnet ioLibrary, and key implementation files are attached in the Documents panel.

한국어 (Korean)

개요

zp492는 GitHub에 소수의 공개 저장소를 올린 메이커 계정이며, 프로필에는 공개 이름, 국가, 회사, 이메일이 표시되어 있지 않습니다. 이 프로젝트는 STM32F103 기반 유선 IoT 터미널로, WIZnet W5500 SPI 포트를 추가하고 FreeRTOS 태스크 위에서 자체 MQTT 3.1.1 클라이언트를 실행해 OneNET으로 센서 데이터를 전송합니다.

생성 기술 다이어그램: 이 글은 FreeRTOS 태스크에서 W5500 하드웨어 소켓을 거쳐 OneNET MQTT로 이어지는 STM32F103 애플리케이션 경로에 초점을 둡니다.

이 저장소의 장점은 W5500 사용이 단순 배선 설명에 그치지 않는다는 점입니다. w5500_port.c는 SPI 콜백과 칩 초기화를 담당하고, transport.c는 WIZnet socket 전송 계층을 제공하며, mqtt_client.c는 MQTT 패킷 인코딩과 파싱을 구현합니다. mqtt_wrapper.c는 연결과 publish 흐름을 맡고, onenet.c는 OneNET 토픽과 payload 형식을 구성합니다.

README에는 OTA 원격 업그레이드도 설명되어 있지만, 검사한 소스에서는 HTTP 다운로드와 bootloader 업데이트 전체 경로가 확인되지 않았습니다. 그래서 이 글은 OTA를 문서화된 계획 범위로만 다루고, 확인 가능한 W5500 및 MQTT 구현을 중심으로 정리합니다.

시스템 구성

하드웨어 대상은 STM32F103ZET6 개발 보드, W5500 Ethernet 모듈, DHT11 온습도 센서, LCD, LED, 키, 외부 SRAM 지원 회로입니다. README에는 STM32F103C8T6와 DHT22가 보이지만, 코드와 핀맵 문서는 더 큰 STM32F103ZE 계열 보드와 PG11의 DHT11을 기준으로 작성되어 있습니다.

W5500은 SPI2로 연결됩니다. 핀맵 문서는 PB12를 chip select, PB13을 SCK, PB14를 MISO, PB15를 MOSI, PD6을 reset, PA2를 W5500 interrupt 입력으로 지정합니다. interrupt 핀은 현재 사용하지 않는 것으로 문서화되어 있어, 링크 상태는 PHY polling으로 감시합니다.

소프트웨어는 Keil MDK 프로젝트이며 STM32F1 HAL, FreeRTOS, WIZnet ioLibrary 계열 드라이버 파일, 자체 MQTT 클라이언트, OneNET 어댑터를 포함합니다. FreeRTOS는 sensor, MQTT, LED, W5500 monitor 태스크를 만들고, sensor 데이터는 queue로 MQTT 태스크에 전달됩니다. Ethernet 링크가 준비될 때까지 MQTT 연결을 막기 위해 semaphore도 사용합니다.

시스템 아키텍처와 데이터 흐름

데이터 경로는 DHT11 센서와 FreeRTOS sensor 태스크에서 시작됩니다. MQTT 태스크는 queue에 들어온 센서 값을 읽고, OneNET JSON datapoint를 만든 뒤 WIZnet Socket 1을 통해 MQTT 패킷을 전송합니다. W5500 monitor 태스크는 500 ms마다 PHY link 상태를 polling하고, 케이블 연결 상태에 따라 semaphore와 LED 상태를 갱신합니다.

생성 기술 다이어그램: 센서 데이터는 DHT11 태스크에서 MQTT 태스크로 이동하고, W5500 Socket 1을 통해 OneNET 토픽 및 명령 payload와 연결됩니다.

OneNET 어댑터는 broker endpoint를 183.230.40.96:1883으로 설정하고, device ID를 MQTT client ID로 사용하며, $sys/{pid}/{did}/dp/post/json 토픽으로 publish합니다. 또한 $sys/{pid}/{did}/#를 subscribe하여 cloud command를 받을 수 있습니다. command callback은 현재 간단한 JSON 문자열을 파싱해 LED0과 LED1을 제어합니다.

W5500 포트와 소켓 스택

W5500 포트 계층은 이 저장소의 가장 중요한 추가 부분입니다. w5500_port.c는 SPI byte callback, SPI burst callback, chip-select callback, FreeRTOS critical-section callback을 WIZnet driver에 등록합니다. 또한 hardware reset, STM32 unique ID 기반 MAC 주소 생성, static IPv4 설정, PHY auto-negotiation 설정, 초기화 후 SPI2 18 MHz 전환을 수행합니다.

생성 기술 다이어그램: STM32 SPI2 callback, w5500_port.c, WIZnet ioLibrary 호출, MQTT wrapper가 분리된 계층으로 구성됩니다.

transport 계층은 MQTT를 W5500 driver와 분리합니다. transport_connect()는 TCP socket을 열고 connect()를 호출한 뒤 SO_STATUS가 SOCK_ESTABLISHED가 될 때까지 polling합니다. transport_send()는 WIZnet send()를 감싸고, transport_recv()는 SO_RECVBUF를 확인한 뒤 recv()를 호출합니다. 그래서 MQTT 계층은 packet framing, connection state, keepalive, publish, subscribe, command parsing에 집중할 수 있습니다.

WIZnet 칩의 역할

W5500은 이 터미널의 유선 TCP/IP 경로를 제공합니다. 이 펌웨어에서 STM32F103은 MQTT를 위해 software TCP/IP stack을 실행하지 않습니다. 대신 WIZnet socket API를 사용하고, TCP 상태, packet buffering, retransmission, Ethernet PHY 동작은 W5500 하드웨어가 담당합니다.

이 구조는 FreeRTOS sensor node에 적합합니다. 한 태스크는 센서를 읽고, 한 태스크는 MQTT 상태를 관리하고, 한 태스크는 링크 상태를 감시하며, W5500 socket API는 네트워크 경계 역할을 합니다. commit message 기준으로 Socket 0은 TCP 테스트, Socket 1은 MQTT에 사용되며, 나머지 socket은 향후 서비스에 사용할 수 있습니다.

또한 이 코드는 W5500 포팅 참고자료로도 유용합니다. STM32 HAL SPI에 WIZnet callback을 연결하는 방법, FreeRTOS 환경에서 SPI transaction을 보호하는 방법, W5500 socket buffer를 배분하는 방법, protocol layer 위로 작은 transport API를 노출하는 방법을 보여줍니다.

현재 범위와 한계

확인된 구현 범위는 W5500 bring-up, static network configuration, PHY link polling, custom MQTT 3.1.1 packet handling, OneNET 인증 필드, datapoint JSON publish, subscribe setup, keepalive, reconnect logic, sensor queue handoff, LCD display, LED command handling입니다.

생성 기술 다이어그램: 확인된 런타임 루프는 링크 감시, 센서 telemetry, MQTT publish/subscribe, LED command parsing이며, OTA는 문서화된 범위로만 남아 있습니다.

주요 한계는 OTA입니다. README는 bootloader, flash partitioning, HTTP download, validation, automatic switching을 설명하고, system utility 주석도 vector-table offset과 bootloader 시나리오를 언급합니다. 그러나 검사한 저장소에서 완성된 OTA downloader와 bootloader 구현은 확인되지 않았습니다. 따라서 이 저장소는 완성형 OTA 예제라기보다 W5500과 MQTT 구현 참고자료로 보는 편이 정확합니다.

일반적인 bring-up 한계도 있습니다. 저장소에는 실제 하드웨어 사진, schematic, demo video가 없고, 네트워크 설정은 static IP 기준입니다. 재사용하려면 IP 설정, OneNET credential, MQTT topic, sensor type, security handling을 각 환경에 맞게 수정해야 합니다.

적용 위치

이 프로젝트는 유선 IoT 터미널, FreeRTOS 네트워킹 교육, 산업용 센서 프로토타입, Wi-Fi보다 예측 가능한 Ethernet을 선호하는 cloud-connected sensor node에 잘 맞습니다. 특히 큰 외부 MQTT 라이브러리에 의존하지 않고 WIZnet hardware socket 위에 custom protocol layer를 얹는 구조를 공부하려는 독자에게 적합합니다.

향후 WIZnet 예제로 확장할 가치도 있습니다. W5500 port layer와 transport abstraction은 다른 cloud service, 다른 MQTT broker, 다른 STM32 board에 재사용할 수 있고, MQTT wrapper는 DHCP, NTP, retained status message, 실제 OTA downloader 같은 기능을 추가하는 방향으로 확장할 수 있습니다.

관련 WIZnet Maker 프로젝트

• STM32_MQTT_Project는 STM32, W5500, MQTT를 함께 사용한다는 점에서 가장 가까운 관련 글입니다. 차이점은 이번 프로젝트가 W5500 port layer, FreeRTOS task 구조, OneNET 전용 topic adapter를 더 명확히 보여준다는 점입니다.
• W5500-STM32-cJSON은 STM32, W5500, JSON payload 처리 관점에서 관련이 있습니다. 해당 프로젝트는 cJSON 사용에 초점을 두고, 이 프로젝트는 custom MQTT packet stack과 transport wrapper에 초점을 둡니다.
• How to Build an Interrupt-Driven W5500 UDP Server on STM32F4 with FreeRTOS and ioLibrary는 FreeRTOS와 WIZnet ioLibrary 참고자료로 연결됩니다. 해당 글은 STM32F4와 UDP server 동작을 다루고, 이 프로젝트는 STM32F103, TCP, MQTT, cloud telemetry를 다룹니다.

FAQ

이 프로젝트는 W5500을 어디에 사용하나요? STM32F103 터미널의 유선 Ethernet 및 TCP/IP controller로 사용합니다. 펌웨어는 TCP transport에 WIZnet socket call을 사용하고, 그 위에 custom MQTT client를 올립니다.

MQTT 스택은 표준 라이브러리인가요? 아닙니다. 저장소에는 MQTT 3.1.1 packet encoding, remaining-length encoding, CONNECT, PUBLISH, SUBSCRIBE, PING, parsing logic이 자체 구현되어 있고, 이를 FreeRTOS MQTT task로 감쌉니다.

OTA가 완성되어 있다고 볼 수 있나요? 검사한 소스만 기준으로는 아닙니다. OTA는 README와 일부 주석에 설명되어 있지만, 전체 HTTP download 및 bootloader update 구현은 확인되지 않았습니다.

software TCP/IP stack 대신 W5500을 쓰는 이유는 무엇인가요? W5500이 TCP/IP와 Ethernet PHY 동작을 하드웨어에서 처리하므로, STM32F103은 더 작은 firmware 구조로 application task와 MQTT state logic에 집중할 수 있습니다.

다른 broker로 재사용할 수 있나요? 가능합니다. transport와 MQTT layer는 OneNET adapter와 분리되어 있습니다. broker 주소, credential, topic, payload builder를 교체하면 다른 MQTT 환경에 맞출 수 있습니다.

원본 저장소, W5500 제품 페이지, WIZnet ioLibrary, 주요 구현 파일은 Documents 패널에 첨부되어 있습니다.