Wiznet makers

gavinchang

Published June 15, 2026 ©

97 UCC

25 WCC

68 VAR

0 Contests

4 Followers

0 Following

Original Link

How to Run LwIP with WIZnet W5500 MACRAW Mode on FreeRTOS MCU Platforms?

This maker-oriented project explores using WIZnet W5500 not in its usual hardware-socket mode, but as a MAC/PHY-style Ethernet interface for LwIP running on a F

COMPONENTS
PROJECT DESCRIPTION

How to Run LwIP with WIZnet W5500 MACRAW Mode on FreeRTOS MCU Platforms?

Summary

This maker-oriented project explores using WIZnet W5500 not in its usual hardware-socket mode, but as a MAC/PHY-style Ethernet interface for LwIP running on a FreeRTOS-based MCU. In the normal W5500 model, the chip handles TCP/IP in hardware and the MCU uses socket-style commands. In the MACRAW approach, W5500 exposes raw Ethernet frames while LwIP on the MCU handles IP, TCP, UDP, ARP, timers, buffers, and protocol behavior. The goal is more control over the network stack, at the cost of higher firmware complexity and tighter RAM, timing, and driver requirements. The accessible CSDN Wenku listing describes this exact direction: using W5500 MAC RAW mode with LwIP under FreeRTOS for a more controllable network solution.

What the Project Does

The project is about turning W5500 into a lower-level Ethernet interface instead of using it only as a hardwired TCP/IP socket engine. The CSDN Wenku listing frames the design as a way to move beyond the standard hardware protocol stack when a developer needs custom protocols, deeper performance tuning, or direct learning of TCP/IP stack behavior.

The normal W5500 workflow is simple: configure MAC/IP/gateway/subnet, open a TCP or UDP socket, move payload data through W5500 socket buffers, and let the chip handle TCP/IP details. That is the right path for most maker Ethernet devices, such as simple telemetry nodes, Modbus bridges, web configuration panels, or local control boxes.

The MACRAW + LwIP workflow changes the architecture. The MCU runs FreeRTOS tasks, LwIP owns the network stack, and W5500 becomes the Ethernet-frame ingress and egress path. Received Ethernet frames are pulled from W5500 and injected into the LwIP network interface. Outgoing LwIP frames are copied into W5500 transmit buffers and sent through the Ethernet PHY. This gives the firmware more control, but it also means the MCU must now handle memory pools, packet queues, ARP behavior, TCP timers, retransmission logic, and task scheduling.

Where WIZnet Fits

The exact WIZnet product is W5500. WIZnet documents W5500 as a hardwired TCP/IP Ethernet controller that connects to an external MCU through SPI up to 80 MHz, integrates 10/100 Ethernet MAC and PHY, supports TCP, UDP, ICMP, IPv4, ARP, IGMP, and PPPoE, provides 8 independent sockets, and includes 32 KB internal memory for Tx/Rx buffers.

In this project, W5500 still provides the physical wired Ethernet path, SPI-accessible registers, Ethernet MAC/PHY, and internal buffering. The difference is where the TCP/IP stack lives. In standard W5500 socket mode, W5500 owns the TCP/IP transport. In MACRAW mode, the MCU-side LwIP stack owns the IP and transport layers, while W5500 is used closer to a frame-level Ethernet controller.

That distinction matters for firmware design. W5500’s hardware TCP/IP mode minimizes MCU-side stack work and is usually better for small maker devices with limited RAM. MACRAW + LwIP is more appropriate when the developer needs custom packet handling, stack visibility, nonstandard protocol behavior, or a teaching platform for Ethernet and TCP/IP internals.

Implementation Notes

The exact CSDN Wenku answer page could not be fetched directly during verification, and no public source repository was available from the provided link. Because of that, project-specific source code cannot be quoted. The following is an architecture explanation with minimal conceptual code.

Conceptual integration example based on WIZnet ioLibrary

 
#define W5500_RAW_SOCKET 0

static uint8_t tx_size[8] = {16,0,0,0,0,0,0,0};
static uint8_t rx_size[8] = {16,0,0,0,0,0,0,0};

void w5500_lowlevel_init(void)
{
    reg_wizchip_cs_cbfunc(w5500_select, w5500_deselect);
    reg_wizchip_spi_cbfunc(w5500_spi_read, w5500_spi_write);

    wizchip_init(tx_size, rx_size);

    setSn_MR(W5500_RAW_SOCKET, Sn_MR_MACRAW);
    setSn_CR(W5500_RAW_SOCKET, Sn_CR_OPEN);

    while (getSn_SR(W5500_RAW_SOCKET) != SOCK_MACRAW) {
        /* wait for MACRAW socket state */
    }
}
 

This layer exists because W5500 is still controlled through SPI registers. The firmware must register chip-select and SPI callbacks, allocate W5500 internal socket buffers, open socket 0 in MACRAW mode, and verify that the socket state has entered raw Ethernet-frame mode. WIZnet’s ioLibrary is MCU-independent and includes driver support for W5500 plus Berkeley socket-style APIs and application protocols such as DHCP, DNS, MQTT, SNTP, TFTP, and HTTP Server.

Conceptual integration example based on WIZnet ioLibrary

 
void ethernetif_poll_input(struct netif *netif)
{
    uint16_t len = getSn_RX_RSR(W5500_RAW_SOCKET);

    if (len == 0) {
        return;
    }

    uint16_t frame_len = w5500_read_macraw_frame(frame_buf, sizeof(frame_buf));

    if (frame_len > 0) {
        struct pbuf *p = pbuf_alloc(PBUF_RAW, frame_len, PBUF_POOL);
        if (p != NULL) {
            pbuf_take(p, frame_buf, frame_len);
            if (netif->input(p, netif) != ERR_OK) {
                pbuf_free(p);
            }
        }
    }
}
 

This bridge exists because LwIP does not talk to W5500 automatically. The developer must provide a netif driver that transfers raw Ethernet frames between W5500 buffers and LwIP pbuf structures. In a FreeRTOS design, this polling function should usually become a network input task or interrupt-driven receive path with bounded queue depth and clear timeout behavior.

Practical Tips / Pitfalls

  • Use standard W5500 socket mode first. Confirm SPI, reset, PHY link, and basic TCP/UDP operation before attempting MACRAW + LwIP.
  • Keep socket 0 dedicated to MACRAW operation. Do not mix a half-designed LwIP path with normal W5500 hardware sockets during early bring-up.
  • Size LwIP memory pools deliberately. MACRAW mode moves TCP/IP buffering pressure from W5500 hardware behavior into MCU RAM.
  • Separate SPI transfer timing from LwIP timer handling. TCP retransmission, ARP aging, DHCP, and FreeRTOS scheduling must not starve each other.
  • Add counters for dropped frames, pbuf allocation failures, SPI errors, link changes, and LwIP input errors.
  • Start with UDP echo or ICMP ping before testing TCP throughput.
  • Treat this as an advanced maker architecture. It is useful for learning and custom stack behavior, but it is not the shortest path to Ethernet connectivity.

FAQ

Q: Why use WIZnet W5500 if LwIP is already running on the MCU?
A: W5500 still provides the wired Ethernet hardware path: SPI access, Ethernet MAC/PHY, link handling, and internal frame buffering. LwIP provides the software TCP/IP stack. This split is useful when the developer wants LwIP behavior but does not have an MCU with a native Ethernet MAC.

Q: How does W5500 connect to the MCU platform?
A: W5500 connects over SPI with SCLK, MOSI, MISO, chip select, reset, interrupt, 3.3 V power, and Ethernet magnetics or an RJ45 module path. WIZnet documents W5500 as an SPI-based Ethernet controller with embedded 10/100 MAC/PHY and internal Tx/Rx memory.

Q: What role does W5500 play in this MACRAW + LwIP project?
A: W5500 acts as the frame-level Ethernet device. It receives Ethernet frames from the cable, exposes them to the MCU through SPI, and transmits frames generated by LwIP. The MCU firmware supplies the LwIP network-interface driver that moves frames between W5500 and LwIP.

Q: Can beginners follow this project?
A: Beginners can follow it as a learning project, but it is harder than ordinary W5500 socket programming. Prerequisites include SPI debugging, W5500 register operation, FreeRTOS task design, LwIP netif integration, packet buffers, static IP or DHCP setup, and basic Ethernet frame structure.

Q: How does this compare with normal LwIP on an MCU Ethernet MAC?
A: With a native MCU Ethernet MAC, LwIP can usually connect through the vendor’s Ethernet DMA driver. With W5500 MACRAW mode, the MCU must move frames through SPI, so SPI bandwidth and transaction overhead become part of the network path. The advantage is that a low-cost MCU board without native Ethernet MAC can still run LwIP over a wired W5500 interface.

Source

Original source link: CSDN Wenku answer page provided by the user. The page could not be directly fetched during verification, and the license for that exact answer page could not be confirmed.

Related accessible CSDN Wenku listing: “告别硬件协议栈:手把手教你用W5500的MAC RAW模式移植LWIP到FreeRTOS,” describing W5500 MAC RAW mode with LwIP under FreeRTOS.

WIZnet product reference: W5500 documentation and product information.

WIZnet software reference: ioLibrary Driver repository, MIT license.

LwIP reference: official Savannah project summary for the lightweight TCP/IP stack.

Tags

#W5500 #WIZnet #LwIP #FreeRTOS #MACRAW #Ethernet #SPI #Maker #Firmware #Performance #NetworkStack #Registers #EmbeddedTCPIP #ioLibrary

 

FreeRTOS MCU 플랫폼에서 WIZnet W5500 MACRAW 모드로 LwIP를 실행하는 방법은?

요약

이 메이커 중심 프로젝트는 WIZnet W5500을 일반적인 하드웨어 소켓 모드가 아니라, FreeRTOS 기반 MCU에서 실행되는 LwIP를 위한 MAC/PHY 스타일 Ethernet 인터페이스로 사용하는 방식을 다룹니다. 일반적인 W5500 구조에서는 칩이 TCP/IP를 하드웨어로 처리하고 MCU는 socket-style 명령을 사용합니다. 반면 MACRAW 방식에서는 W5500이 raw Ethernet frame을 노출하고, MCU의 LwIP가 IP, TCP, UDP, ARP, timer, buffer, protocol behavior를 처리합니다. 목표는 네트워크 스택에 대한 더 높은 제어권을 얻는 것이지만, 그 대가로 펌웨어 복잡도, RAM 요구량, timing, driver 요구사항이 증가합니다. 접근 가능한 CSDN Wenku 목록은 FreeRTOS에서 W5500 MAC RAW mode와 LwIP를 결합해 더 제어 가능한 네트워크 솔루션을 만드는 방향을 설명합니다.

프로젝트가 하는 일

이 프로젝트는 W5500을 단순한 하드웨어 TCP/IP socket engine으로만 사용하는 대신, 더 낮은 수준의 Ethernet interface처럼 사용하는 방법을 다룹니다. CSDN Wenku 목록은 개발자가 custom protocol, 깊은 performance tuning, TCP/IP stack 동작 학습이 필요할 때 표준 하드웨어 프로토콜 스택을 넘어서는 방법으로 이 설계를 소개합니다.

일반적인 W5500 사용 흐름은 단순합니다. MAC/IP/gateway/subnet을 설정하고, TCP 또는 UDP socket을 열고, W5500 socket buffer를 통해 payload data를 이동시키며, TCP/IP 세부 동작은 칩에 맡깁니다. 이 방식은 간단한 telemetry node, Modbus bridge, web configuration panel, local control box 같은 대부분의 maker Ethernet 장치에 적합합니다.

MACRAW + LwIP 방식은 아키텍처를 바꿉니다. MCU는 FreeRTOS task를 실행하고, LwIP가 네트워크 스택을 소유하며, W5500은 Ethernet frame의 ingress 및 egress 경로가 됩니다. 수신된 Ethernet frame은 W5500에서 읽어 LwIP network interface로 주입됩니다. 송신 방향에서는 LwIP가 만든 frame을 W5500 transmit buffer로 복사한 뒤 Ethernet PHY를 통해 전송합니다. 이 구조는 펌웨어에 더 많은 제어권을 주지만, MCU가 memory pool, packet queue, ARP behavior, TCP timer, retransmission logic, task scheduling을 직접 관리해야 한다는 의미이기도 합니다.

WIZnet이 들어가는 위치

이 프로젝트에서 사용하는 정확한 WIZnet 제품은 W5500입니다. WIZnet 문서 기준으로 W5500은 SPI를 통해 외부 MCU에 연결되는 hardwired TCP/IP Ethernet controller이며, 최대 80 MHz SPI, 10/100 Ethernet MAC 및 PHY, TCP, UDP, ICMP, IPv4, ARP, IGMP, PPPoE, 8개 독립 socket, 32 KB 내부 Tx/Rx buffer memory를 제공합니다.

이 프로젝트에서도 W5500은 여전히 물리적인 유선 Ethernet 경로, SPI 접근 레지스터, Ethernet MAC/PHY, 내부 버퍼링을 제공합니다. 차이는 TCP/IP stack이 어디에 있느냐입니다. 표준 W5500 socket mode에서는 W5500이 TCP/IP transport를 소유합니다. MACRAW mode에서는 MCU 측 LwIP stack이 IP 및 transport layer를 소유하고, W5500은 frame-level Ethernet controller에 가까운 역할을 합니다.

이 차이는 펌웨어 설계에서 중요합니다. W5500의 hardware TCP/IP mode는 MCU 측 stack 작업을 최소화하므로 RAM이 제한된 작은 maker 장치에 보통 더 적합합니다. MACRAW + LwIP는 custom packet handling, stack visibility, nonstandard protocol behavior, Ethernet 및 TCP/IP 내부 구조 학습 플랫폼이 필요할 때 더 적합합니다.

구현 참고 사항

제공된 CSDN Wenku answer page는 검증 중 직접 가져올 수 없었고, 해당 링크에서 공개 소스 저장소도 확인할 수 없었습니다. 따라서 프로젝트별 소스 코드는 인용할 수 없습니다. 아래는 최소한의 개념 코드가 포함된 아키텍처 설명입니다.

Conceptual integration example based on WIZnet ioLibrary

 
#define W5500_RAW_SOCKET 0

static uint8_t tx_size[8] = {16,0,0,0,0,0,0,0};
static uint8_t rx_size[8] = {16,0,0,0,0,0,0,0};

void w5500_lowlevel_init(void)
{
    reg_wizchip_cs_cbfunc(w5500_select, w5500_deselect);
    reg_wizchip_spi_cbfunc(w5500_spi_read, w5500_spi_write);

    wizchip_init(tx_size, rx_size);

    setSn_MR(W5500_RAW_SOCKET, Sn_MR_MACRAW);
    setSn_CR(W5500_RAW_SOCKET, Sn_CR_OPEN);

    while (getSn_SR(W5500_RAW_SOCKET) != SOCK_MACRAW) {
        /* wait for MACRAW socket state */
    }
}
 

이 계층은 W5500이 여전히 SPI 레지스터를 통해 제어되기 때문에 필요합니다. 펌웨어는 chip-select 및 SPI callback을 등록하고, W5500 내부 socket buffer를 할당하며, socket 0을 MACRAW mode로 열고, socket state가 raw Ethernet-frame mode에 진입했는지 확인해야 합니다. WIZnet ioLibrary는 MCU 독립형 드라이버이며 W5500 지원, Berkeley socket-style API, DHCP, DNS, MQTT, SNTP, TFTP, HTTP Server 같은 애플리케이션 프로토콜을 포함합니다.

Conceptual integration example based on WIZnet ioLibrary

 
void ethernetif_poll_input(struct netif *netif)
{
    uint16_t len = getSn_RX_RSR(W5500_RAW_SOCKET);

    if (len == 0) {
        return;
    }

    uint16_t frame_len = w5500_read_macraw_frame(frame_buf, sizeof(frame_buf));

    if (frame_len > 0) {
        struct pbuf *p = pbuf_alloc(PBUF_RAW, frame_len, PBUF_POOL);
        if (p != NULL) {
            pbuf_take(p, frame_buf, frame_len);
            if (netif->input(p, netif) != ERR_OK) {
                pbuf_free(p);
            }
        }
    }
}
 

이 bridge는 LwIP가 W5500과 자동으로 통신하지 않기 때문에 필요합니다. 개발자는 W5500 buffer와 LwIP pbuf 구조 사이에서 raw Ethernet frame을 이동시키는 netif driver를 제공해야 합니다. FreeRTOS 설계에서는 이 polling function을 보통 network input task 또는 interrupt-driven receive path로 구성해야 하며, queue depth와 timeout behavior를 명확히 제한해야 합니다.

실무 팁 / 주의점

  • 먼저 표준 W5500 socket mode를 사용해야 합니다. MACRAW + LwIP를 시도하기 전에 SPI, reset, PHY link, 기본 TCP/UDP 동작을 검증하는 것이 좋습니다.
  • socket 0을 MACRAW 동작 전용으로 유지해야 합니다. 초기 bring-up 단계에서 LwIP 경로와 일반 W5500 hardware socket을 혼합하지 않는 것이 좋습니다.
  • LwIP memory pool 크기를 의도적으로 설정해야 합니다. MACRAW mode는 TCP/IP buffer 부담을 W5500 하드웨어 동작에서 MCU RAM 쪽으로 이동시킵니다.
  • SPI transfer timing과 LwIP timer handling을 분리해야 합니다. TCP retransmission, ARP aging, DHCP, FreeRTOS scheduling이 서로를 방해하지 않아야 합니다.
  • dropped frame, pbuf allocation failure, SPI error, link change, LwIP input error를 추적하는 counter를 추가해야 합니다.
  • TCP throughput을 테스트하기 전에 UDP echo 또는 ICMP ping부터 시작하는 것이 좋습니다.
  • 이 구조는 advanced maker architecture로 보는 것이 적절합니다. 학습과 custom stack behavior에는 유용하지만, Ethernet 연결을 가장 빠르게 구현하는 방법은 아닙니다.

FAQ

Q: MCU에서 LwIP를 실행하는데 왜 WIZnet W5500을 사용하나요?
A: W5500은 여전히 유선 Ethernet hardware path를 제공합니다. SPI 접근, Ethernet MAC/PHY, link handling, 내부 frame buffering을 담당합니다. LwIP는 software TCP/IP stack을 제공합니다. 이 분리는 native Ethernet MAC이 없는 MCU에서도 LwIP 동작을 사용하고 싶을 때 유용합니다.

Q: W5500은 MCU 플랫폼에 어떻게 연결되나요?
A: W5500은 SPI를 통해 연결됩니다. 일반적으로 SCLK, MOSI, MISO, chip select, reset, interrupt, 3.3 V 전원, Ethernet magnetics 또는 RJ45 module path가 필요합니다. W5500은 embedded 10/100 MAC/PHY와 내부 Tx/Rx memory를 가진 SPI 기반 Ethernet controller입니다.

Q: 이 MACRAW + LwIP 프로젝트에서 W5500은 어떤 역할을 하나요?
A: W5500은 frame-level Ethernet device로 동작합니다. 케이블에서 Ethernet frame을 수신해 SPI를 통해 MCU에 노출하고, LwIP가 생성한 frame을 전송합니다. MCU 펌웨어는 W5500과 LwIP 사이에서 frame을 이동시키는 LwIP network-interface driver를 제공합니다.

Q: 초보자도 이 프로젝트를 따라갈 수 있나요?
A: 학습 프로젝트로는 따라갈 수 있지만, 일반적인 W5500 socket programming보다 어렵습니다. 필요한 선행 지식은 SPI debugging, W5500 register operation, FreeRTOS task design, LwIP netif integration, packet buffer, static IP 또는 DHCP setup, 기본 Ethernet frame structure입니다.

Q: 일반 MCU Ethernet MAC에서 LwIP를 실행하는 방식과 비교하면 어떤 차이가 있나요?
A: native MCU Ethernet MAC이 있는 경우 LwIP는 보통 벤더의 Ethernet DMA driver를 통해 연결됩니다. W5500 MACRAW mode에서는 MCU가 SPI를 통해 frame을 이동시켜야 하므로 SPI bandwidth와 transaction overhead가 네트워크 경로의 일부가 됩니다. 장점은 native Ethernet MAC이 없는 저가 MCU 보드도 W5500 유선 인터페이스를 통해 LwIP를 실행할 수 있다는 점입니다.

출처

Original source link: 사용자가 제공한 CSDN Wenku answer page. 검증 중 해당 페이지를 직접 가져올 수 없었으며, 정확한 answer page의 라이선스는 확인할 수 없었습니다.
https://wenku.csdn.net/answer/3zzj19i8f0

Related accessible CSDN Wenku listing: “告别硬件协议栈:手把手教你用W5500的MAC RAW模式移植LWIP到FreeRTOS,” W5500 MAC RAW mode와 FreeRTOS 기반 LwIP 이식 방향을 설명하는 목록.
https://wenku.csdn.net/column/516kkl1sqo9

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

WIZnet software reference: ioLibrary Driver repository, MIT license.
https://github.com/Wiznet/ioLibrary_Driver

LwIP reference: official Savannah project summary for the lightweight TCP/IP stack.
https://savannah.nongnu.org/projects/lwip/

태그

#W5500 #WIZnet #LwIP #FreeRTOS #MACRAW #Ethernet #SPI #Maker #Firmware #Performance #NetworkStack #Registers #EmbeddedTCPIP #ioLibrary

Documents
Comments Write