How to Build an HTTP Client with WIZnet W5500 on STM32F10x?

Summary

This STM32F10x project builds a wired HTTP client with the WIZnet W5500 Ethernet controller. The STM32 configures W5500 through SPI, resolves httpbin.org with DNS, opens a TCP socket, sends HTTP GET and POST requests, and prints the server response through UART. W5500 acts as the Ethernet MAC/PHY and hardware TCP/IP socket engine for commercial embedded devices that need simple wired server communication.

What the Project Does

The project demonstrates a complete outbound HTTP client flow on STM32F10x with W5500. It uses httpbin as the test server, first explaining HTTP request methods and then focusing on GET, POST, and DNS resolution. The test sequence includes resolving httpbin.org, sending GET /ip, sending a POST body such as LED1=1&LED2=1, and sending a parameterized GET request such as GET /get?LED1=1&LED2=0 HTTP/1.1.

The startup path is structured like a deployable embedded network client. The firmware initializes delay, NVIC priority grouping, UART, LED, timer, SPI1, W5500 reset and interrupt pins, then calls wizchip_initialize() to register SPI callbacks, reset W5500, check the W5500 version register, and wait for PHY link. After that, it applies static TCP network settings, opens W5500 socket 0 in TCP mode, runs DNS, and performs HTTP requests through the resolved server IP address.

The test output confirms a 100 Mbps full-duplex PHY link, static network configuration, DNS translation of httpbin.org, and successful HTTP responses for GET and POST traffic. The logged static configuration uses MAC 00:08:DC:11:11:11, IP 192.168.1.199, subnet 255.255.255.0, gateway 192.168.1.1, and DNS 8.8.8.8.

Where WIZnet Fits

The exact WIZnet product is W5500. In this architecture, W5500 is the wired Ethernet controller and TCP/IP offload device between the STM32F10x firmware and the external HTTP server. The STM32 constructs HTTP request strings and controls the application sequence, while W5500 provides the Ethernet MAC/PHY, TCP socket state, transmit and receive buffers, and SPI-accessible socket API.

W5500 is technically appropriate here because it is a hardwired TCP/IP stack internet controller with SPI access up to 80 MHz, an embedded 10/100 Ethernet MAC and PHY, support for TCP, UDP, IPv4, ARP, ICMP, IGMP, and PPPoE, 8 independent sockets, and 32 KB of internal Tx/Rx buffer memory. WIZnet also documents ioLibrary as an MCU-independent library for WIZnet W5x00 and W6x00 chips with services such as DHCP, DNS, MQTT, SNTP, TFTP, and HTTP Server.

For commercial embedded products, this separation is useful. The MCU firmware can keep the application layer explicit: resolve a hostname, connect to a server, send a request, read a response, close the socket, and retry on failure. The network interface remains deterministic from the MCU side because TCP connection state and packet buffering are handled by W5500 rather than a large software network stack running on the STM32.

Implementation Notes

File: wiz_platform.c
What it configures: W5500 chip-select, SPI byte access, burst SPI access, reset, and timer-driven DNS support.
Why it matters: WIZnet ioLibrary is platform-independent, so the STM32-specific SPI access functions must be registered before socket, DNS, and HTTP client routines can use W5500.

void wizchip_spi_cb_reg(void)
{
    reg_wizchip_cs_cbfunc(wizchip_select, wizchip_deselect);
    reg_wizchip_spi_cbfunc(wizchip_read_byte, wizchip_write_byte);
    reg_wizchip_spiburst_cbfunc(wizchip_read_buff, wizchip_write_buff);
}

The same platform layer configures TIM2 as a 1 ms interrupt source and calls DNS_time_handler() every 1000 ms, which is required for DNS timeout and retry behavior.

File: Test_httpclient.c
What it configures: HTTP request construction and TCP request/response handling through a W5500 socket.
Why it matters: The application prepares plain HTTP request strings, then sends them through a W5500 TCP socket after DNS has resolved the target server.

uint32_t http_get_IP(uint8_t *pkt)
{
    *pkt = 0;
    strcat((char *)pkt, GET_IP_REG);
    strcat((char *)pkt, Host_REG);
    strcat((char *)pkt, (char*)org_server_name);
    strcat((char *)pkt, Host_rn_REG);
    strcat((char *)pkt, Host_rn_REG);
    return strlen((char *)pkt);
}

The HTTP transaction routine monitors the W5500 socket state with getSn_SR(sn), calls connect() when the socket reaches SOCK_INIT, sends the request once in SOCK_ESTABLISHED, reads pending response data with recv(), then disconnects and closes the socket.

case SOCK_ESTABLISHED:
    if (send_flag == 0)
    {
        send(sn, buf, len);
        send_flag = 1;
    }
    len = getSn_RX_RSR(sn);

This code exists because an HTTP client is built on top of TCP. W5500 manages the TCP socket state and RX buffer, while the STM32 firmware decides when to connect, send, print the response, close the socket, and return success or timeout.

Practical Tips / Pitfalls

• Confirm W5500 SPI access before debugging HTTP. The referenced repository recommends checking SPI read/write and whether the W5500 version register can be read correctly. 
• Wait for PHY link before DNS or HTTP. The example checks link state and prints speed and duplex before running the client flow.
• Keep DNS, gateway, and subnet values consistent with the real LAN. A valid static IP alone is not enough for outbound HTTP.
• Reserve socket 0 deliberately. This project uses socket 0 as the TCP client socket, while DNS also needs socket resources during name resolution.
• Add production retry policy. The demo times out after repeated receive waits; a commercial product should define retry count, backoff, and fault reporting.
• Do not treat HTTP success as link success only. A board can have PHY link and still fail due to DNS, gateway, firewall, server, or request-format errors.
• Log request and response text during bring-up, but disable or limit verbose UART output in production firmware.

FAQ

Q: Why use WIZnet W5500 for an STM32F10x HTTP client?
A: W5500 provides the wired Ethernet MAC/PHY, hardwired TCP/IP engine, socket state machine, and internal packet buffers. This lets STM32F10x firmware focus on DNS, HTTP request construction, response parsing, and product logic instead of maintaining the low-level TCP/IP stack.

Q: How does W5500 connect to the STM32F10x platform?
A: The project uses SPI1. The article configures PA5 as SCK, PA6 as MISO, PA7 as MOSI, PA4 as W5500 chip select, PC5 as W5500 reset, and PC4 as W5500 interrupt input.

Q: What role does W5500 play in this HTTP client project?
A: W5500 provides the TCP transport path for HTTP. The STM32 creates strings such as GET /ip and POST /post HTTP/1.1, but W5500 handles the TCP socket connection, transmit buffer, receive buffer, and socket close sequence.

Q: Can beginners follow this project?
A: It is practical for developers who already understand STM32 peripheral initialization, SPI, UART logging, IPv4 addressing, DNS, and basic HTTP formatting. For commercial use, the important next steps are timeout handling, reconnection policy, credential handling, and separating debug logs from production behavior.

Q: How does W5500 compare with an LwIP-based HTTP client on STM32?
A: With W5500, the TCP/IP stack and socket buffering are handled in the Ethernet controller, so the STM32 mainly drives SPI and the application state machine. With LwIP, the MCU typically owns more of the TCP/IP memory, timers, packet buffers, and integration work; that can be flexible, but it increases firmware complexity on small STM32F10x designs.

Source

Original article: CSDN, “测试W5500的第7步_使用ioLibrary库创建HTTP客户端,” first published on 2025-05-26 and marked as CC BY-SA 4.0.

Source repository referenced by the article: WIZnet HK, STM32F10x_W5500_Examples, licensed under Mulan PSL v2. The repository describes 8.HTTP_Client as an HTTP request initiation example and provides STM32F10x W5500 protocol examples.

WIZnet product reference: W5500 documentation and ioLibrary Driver documentation.

Tags

#W5500 #WIZnet #STM32F10x #STM32F103 #HTTPClient #DNS #TCP #Ethernet #SPI #ioLibrary #EmbeddedC #Commercial #NetworkStack

STM32F10x에서 WIZnet W5500으로 HTTP 클라이언트를 구축하는 방법은?

요약

이 STM32F10x 프로젝트는 WIZnet W5500 이더넷 컨트롤러를 사용해 유선 HTTP 클라이언트를 구현합니다. STM32는 SPI로 W5500을 설정하고, DNS로 httpbin.org를 해석한 뒤, TCP 소켓을 열어 HTTP GET 및 POST 요청을 전송하고 서버 응답을 UART로 출력합니다. W5500은 상용 임베디드 장치에서 간단한 유선 서버 통신을 구현하기 위한 Ethernet MAC/PHY 및 하드웨어 TCP/IP 소켓 엔진 역할을 합니다.

프로젝트가 하는 일

이 프로젝트는 STM32F10x와 W5500을 사용해 완전한 아웃바운드 HTTP 클라이언트 흐름을 구현합니다. 테스트 서버로는 httpbin.org를 사용하며, HTTP 요청 메서드를 설명한 뒤 GET, POST, DNS 해석에 집중합니다. 테스트 흐름에는 httpbin.org DNS 해석, GET /ip 요청, LED1=1&LED2=1 형태의 POST 본문 전송, GET /get?LED1=1&LED2=0 HTTP/1.1 형태의 파라미터 포함 GET 요청이 포함됩니다.

시작 흐름은 실제 배포 가능한 임베디드 네트워크 클라이언트 구조에 가깝습니다. 펌웨어는 지연 함수, NVIC 우선순위 그룹, UART, LED, 타이머, SPI1, W5500 리셋 및 인터럽트 핀을 초기화합니다. 이후 wizchip_initialize()를 호출해 SPI 콜백을 등록하고, W5500을 리셋하며, W5500 버전 레지스터를 확인하고, PHY 링크가 연결될 때까지 대기합니다. 그 다음 고정 TCP 네트워크 설정을 적용하고, W5500 소켓 0을 TCP 모드로 열고, DNS를 실행한 뒤 해석된 서버 IP 주소를 통해 HTTP 요청을 수행합니다.

테스트 출력은 100 Mbps 풀 듀플렉스 PHY 링크, 고정 네트워크 설정, httpbin.org DNS 해석, GET 및 POST 트래픽에 대한 HTTP 응답 성공을 확인합니다. 로그에 표시된 고정 네트워크 설정은 MAC 00:08:DC:11:11:11, IP 192.168.1.199, 서브넷 255.255.255.0, 게이트웨이 192.168.1.1, DNS 8.8.8.8입니다.

WIZnet이 들어가는 위치

이 프로젝트에서 사용되는 WIZnet 제품은 W5500입니다. 이 구조에서 W5500은 STM32F10x 펌웨어와 외부 HTTP 서버 사이에 위치하는 유선 이더넷 컨트롤러이자 TCP/IP 오프로딩 장치입니다. STM32는 HTTP 요청 문자열을 만들고 애플리케이션 순서를 제어하며, W5500은 Ethernet MAC/PHY, TCP 소켓 상태, 송수신 버퍼, SPI로 접근 가능한 소켓 API를 제공합니다.

W5500은 이 프로젝트에 적합합니다. W5500은 하드웨어 TCP/IP 스택 기반 인터넷 컨트롤러이며, 최대 80 MHz SPI 접근, 내장 10/100 Ethernet MAC 및 PHY, TCP, UDP, IPv4, ARP, ICMP, IGMP, PPPoE 지원, 8개 독립 소켓, 32 KB 내부 Tx/Rx 버퍼를 제공합니다. WIZnet ioLibrary는 W5x00 및 W6x00 칩을 위한 MCU 독립형 라이브러리이며 DHCP, DNS, MQTT, SNTP, TFTP, HTTP Server 같은 서비스를 제공합니다.

상용 임베디드 제품에서는 이런 분리가 유용합니다. MCU 펌웨어는 호스트 이름 해석, 서버 연결, 요청 전송, 응답 읽기, 소켓 종료, 실패 시 재시도 같은 애플리케이션 계층을 명확하게 구성할 수 있습니다. TCP 연결 상태와 패킷 버퍼링은 STM32에서 실행되는 큰 소프트웨어 네트워크 스택이 아니라 W5500이 담당하므로, MCU 입장에서 네트워크 인터페이스가 더 예측 가능한 구조가 됩니다.

구현 참고 사항

파일: wiz_platform.c
설정 내용: W5500 칩 셀렉트, SPI 바이트 접근, 버스트 SPI 접근, 리셋, 타이머 기반 DNS 지원
중요한 이유: WIZnet ioLibrary는 플랫폼 독립 구조이므로, 소켓, DNS, HTTP 클라이언트 루틴이 W5500을 사용하려면 STM32 전용 SPI 접근 함수가 먼저 등록되어야 합니다.

void wizchip_spi_cb_reg(void)
{
    reg_wizchip_cs_cbfunc(wizchip_select, wizchip_deselect);
    reg_wizchip_spi_cbfunc(wizchip_read_byte, wizchip_write_byte);
    reg_wizchip_spiburst_cbfunc(wizchip_read_buff, wizchip_write_buff);
}

같은 플랫폼 계층은 TIM2를 1 ms 인터럽트 소스로 설정하고, 1000 ms마다 DNS_time_handler()를 호출합니다. 이 처리는 DNS 타임아웃과 재시도 동작에 필요합니다.

파일: Test_httpclient.c
설정 내용: HTTP 요청 생성 및 W5500 소켓을 통한 TCP 요청/응답 처리
중요한 이유: 애플리케이션은 일반 HTTP 요청 문자열을 만들고, DNS가 대상 서버를 해석한 뒤 W5500 TCP 소켓을 통해 전송합니다.

uint32_t http_get_IP(uint8_t *pkt)
{
    *pkt = 0;
    strcat((char *)pkt, GET_IP_REG);
    strcat((char *)pkt, Host_REG);
    strcat((char *)pkt, (char*)org_server_name);
    strcat((char *)pkt, Host_rn_REG);
    strcat((char *)pkt, Host_rn_REG);
    return strlen((char *)pkt);
}

HTTP 트랜잭션 루틴은 getSn_SR(sn)으로 W5500 소켓 상태를 확인합니다. 소켓이 SOCK_INIT 상태가 되면 connect()를 호출하고, SOCK_ESTABLISHED 상태에서는 요청을 한 번 전송합니다. 이후 recv()로 응답 데이터를 읽고, 소켓을 disconnect 및 close 처리합니다.

case SOCK_ESTABLISHED:
    if (send_flag == 0)
    {
        send(sn, buf, len);
        send_flag = 1;
    }
    len = getSn_RX_RSR(sn);

이 코드는 HTTP 클라이언트가 TCP 위에서 동작하기 때문에 필요합니다. W5500은 TCP 소켓 상태와 RX 버퍼를 관리하고, STM32 펌웨어는 언제 연결하고, 전송하고, 응답을 출력하고, 소켓을 닫고, 성공 또는 타임아웃을 반환할지 결정합니다.

실무 팁 / 주의점

• HTTP를 디버깅하기 전에 W5500 SPI 접근을 확인해야 합니다. SPI 읽기/쓰기와 W5500 버전 레지스터 읽기가 정상이어야 합니다.
• DNS나 HTTP를 실행하기 전에 PHY 링크 연결을 기다려야 합니다. 예제는 링크 상태를 확인하고 속도와 듀플렉스 정보를 출력한 뒤 클라이언트 흐름을 실행합니다.
• DNS, 게이트웨이, 서브넷 값은 실제 LAN 환경과 일치해야 합니다. 유효한 고정 IP만으로는 외부 HTTP 통신이 보장되지 않습니다.
• 소켓 0 사용을 의도적으로 관리해야 합니다. 이 프로젝트는 소켓 0을 TCP 클라이언트 소켓으로 사용하지만, DNS 해석 중에도 소켓 자원이 필요합니다.
• 상용 제품에는 재시도 정책이 필요합니다. 데모는 반복 수신 대기 후 타임아웃 처리하지만, 실제 제품은 재시도 횟수, 백오프, 장애 보고 방식을 정의해야 합니다.
• HTTP 성공을 단순한 링크 성공으로 보면 안 됩니다. PHY 링크가 있어도 DNS, 게이트웨이, 방화벽, 서버, 요청 형식 문제로 실패할 수 있습니다.
• bring-up 단계에서는 요청과 응답 텍스트 로그가 유용하지만, 양산 펌웨어에서는 UART 출력량을 제한하거나 비활성화하는 것이 좋습니다.

FAQ

Q: STM32F10x HTTP 클라이언트에 왜 WIZnet W5500을 사용하나요?
A: W5500은 유선 Ethernet MAC/PHY, 하드웨어 TCP/IP 엔진, 소켓 상태 머신, 내부 패킷 버퍼를 제공합니다. STM32F10x 펌웨어는 저수준 TCP/IP 스택 유지보수보다 DNS, HTTP 요청 생성, 응답 파싱, 제품 로직에 집중할 수 있습니다.

Q: W5500은 STM32F10x 플랫폼에 어떻게 연결되나요?
A: 이 프로젝트는 SPI1을 사용합니다. PA5는 SCK, PA6은 MISO, PA7은 MOSI, PA4는 W5500 칩 셀렉트, PC5는 W5500 리셋, PC4는 W5500 인터럽트 입력으로 설정됩니다.

Q: 이 HTTP 클라이언트 프로젝트에서 W5500은 어떤 역할을 하나요?
A: W5500은 HTTP를 위한 TCP 전송 경로를 제공합니다. STM32는 GET /ip, POST /post HTTP/1.1 같은 문자열을 만들고, W5500은 TCP 소켓 연결, 송신 버퍼, 수신 버퍼, 소켓 종료 시퀀스를 처리합니다.

Q: 초보자도 따라할 수 있나요?
A: STM32 주변장치 초기화, SPI, UART 로그, IPv4 주소 체계, DNS, 기본 HTTP 형식을 이해하는 개발자라면 따라갈 수 있습니다. 상용 제품으로 확장하려면 타임아웃 처리, 재연결 정책, 인증 정보 처리, 디버그 로그와 제품 동작 분리가 필요합니다.

Q: W5500 방식은 STM32에서 LwIP 기반 HTTP 클라이언트를 구현하는 방식과 어떻게 다른가요?
A: W5500을 사용하면 TCP/IP 스택과 소켓 버퍼링이 이더넷 컨트롤러 내부에서 처리되므로 STM32는 주로 SPI와 애플리케이션 상태 머신을 구동합니다. LwIP를 사용하면 MCU가 TCP/IP 메모리, 타이머, 패킷 버퍼, 통합 작업을 더 많이 담당하므로 유연성은 있지만 작은 STM32F10x 설계에서는 펌웨어 복잡도가 증가할 수 있습니다.

출처

Original article: CSDN, “测试W5500的第7步_使用ioLibrary库创建HTTP客户端,” 2025-05-26 게시, CC BY-SA 4.0로 표시됨.
https://blog.csdn.net/weixin_42550185/article/details/148231455?spm=1001.2014.3001.5502

Source repository referenced by the article: WIZnet HK, STM32F10x_W5500_Examples, Mulan PSL v2 라이선스. 저장소는 8.HTTP_Client를 HTTP 요청 예제로 설명하며 STM32F10x W5500 프로토콜 예제 세트를 제공합니다.
https://gitee.com/wiznet-hk/STM32F10x_W5500_Examples

WIZnet product reference: W5500 documentation and ioLibrary Driver documentation.
https://docs.wiznet.io/Product/Chip/Ethernet/W5500

태그

#W5500 #WIZnet #STM32F10x #STM32F103 #HTTPClient #DNS #TCP #Ethernet #SPI #ioLibrary #EmbeddedC #Commercial #NetworkStack