Wiznet makers

Introduction

Zephyr RTOS has become one of the most important embedded operating systems in the industry. Its vendor-neutral governance under the Linux Foundation, its robust networking stack, and its broad board support have made it the default RTOS choice for a growing number of production embedded systems — from IoT sensors to industrial controllers. When a board gains Zephyr support, it gains access to a mature, production-tested networking layer, a unified device driver model, and a community of thousands of developers already familiar with the platform.

The story of how the W6300-EVB-Pico2 arrived in Zephyr mainline is itself a small illustration of how healthy open-source ecosystems work. The board is now supported in Zephyr — but it was not WIZnet who got it there first.

The Community Got There First

In January 2025, Manjae Cho, an engineer at Samsung in Korea, opened pull request #102727 in the Zephyr repository, adding board support for the W6300-EVB-Pico2. This was an independent community contribution — Manjae was not working on behalf of WIZnet. He identified the board, found it useful, and did the work to bring it into Zephyr mainline on his own initiative.

WIZnet opened their own PR for the same board in April 2025. By that point, Manjae's PR was already well into the review process. The Zephyr maintainers subsequently informed WIZnet that since Manjae's PR had been approved and merged, WIZnet's PR was unlikely to receive further review.

That outcome stings a little, but the honest reading is a positive one: a Samsung engineer found the W6300-EVB-Pico2 compelling enough to contribute Zephyr support for it entirely on his own initiative, months before WIZnet themselves got around to it. That is organic community adoption, and it is exactly what board makers hope for.

What Manjae's Implementation Does

Manjae's merged PR adds a complete, working board support package. The board is registered under the identifier w6300_evb_pico2/rp2350a/m33 and the full Zephyr networking stack is available immediately — DHCP, sockets, TLS, MQTT, CoAP, HTTP, and the rest — backed by the W6300's hardwired TCP/IP engine.

The W6300 is configured in the Device Tree using the wiznet,w6300 compatible string, connected via the zephyr,spi-bitbang bus driver on GPIO 15–19:

spi_w6300: spi-bitbang {
    compatible = "zephyr,spi-bitbang";
    clk-gpios  = <&gpio0 17 GPIO_ACTIVE_HIGH>;
    mosi-gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
    miso-gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
    cs-gpios   = <&gpio0 16 GPIO_ACTIVE_LOW>;
     ethernet: w6300@0 {
        compatible = "wiznet,w6300";
        spi-max-frequency = <500000>;
        int-gpios   = <&gpio0 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
        reset-gpios = <&gpio0 22 GPIO_ACTIVE_LOW>;
        zephyr,random-mac-address;
        status = "okay";
    };
};

This is a standard 4-wire SPI connection — MOSI, MISO, CLK, and CS — running at a conservative 500 kHz. It is correct, functional, and portable across Zephyr versions. For many applications it is entirely sufficient: the W6300's hardwired TCP/IP stack handles the heavy networking work in silicon, and a modest SPI clock is enough to keep the socket interface fed for typical sensor telemetry, MQTT publishing, or HTTP transactions.

Notice, however, what the implementation does not use: GPIO 20 and GPIO 21, which are wired to the W6300's IO2 and IO3 pins on the board. Those are the two additional data lines that enable QSPI mode — four simultaneous data bits per clock cycle instead of one. They are physically present on the hardware, connected and ready. In the merged implementation they are simply unused.

What WIZnet's PR Adds

WIZnet's own PR, still open and currently at "Changes required" status, takes a different approach. Rather than the software bitbang SPI driver, it uses the RP2350's PIO blocks to implement QSPI communication with the W6300.

This is a meaningful technical distinction. The RP2350A has three Programmable I/O (PIO) blocks — independent state machines that execute small custom instruction programs directly on GPIO pins, with deterministic timing and without involving the Cortex-M33 cores in the bit-level signalling. PIO was introduced in the RP2040 and is one of the defining capabilities of the RP2350 family. It is the mechanism Raspberry Pi themselves use for QSPI flash access.

Using PIO for QSPI to the W6300 means all four data lines (IO0–IO3, GPIO 18–21) are active simultaneously on every clock edge. Where standard SPI transfers one bit per clock cycle, QSPI transfers four. At equivalent clock frequencies, the effective throughput to and from the W6300 is four times higher. In practice this matters most for bulk data transfers — OTA firmware streaming, large HTTP responses, high-rate sensor data aggregation — where the SPI bus between the host MCU and the W6300 becomes the bottleneck rather than the W6300's internal TCP/IP processing.

The gap between the two approaches is also visible in the clock rate. Manjae's bitbang implementation runs at 500 kHz — a deliberate choice for a software driver where higher speeds risk timing violations. A PIO-based implementation can run reliably at much higher frequencies, staying well within the W6300's specified limits, because PIO timing is hardware-deterministic and does not depend on CPU scheduling or interrupt latency.

Why the PR is still in review

The "Changes required" status on WIZnet's PR reflects the Zephyr maintainers applying appropriate rigour to a more complex contribution. Adding a PIO-based QSPI driver involves more moving parts than a bitbang SPI node — PIO program code, a new compatible string and driver binding, DTS changes, and potentially contributions to the Zephyr PIO driver subsystem for the RP2350. Each of those components gets reviewed carefully. The fact that Manjae's simpler implementation was merged first has not helped the situation, as it reduces the urgency from the maintainers' perspective.

WIZnet is continuing to push the PR forward. If it merges, the W6300-EVB-Pico2 will gain a substantially higher-performance Ethernet path in Zephyr — one that makes full use of both the W6300's QSPI interface and the RP2350's PIO capabilities.

The Board Itself

The W6300-EVB-Pico2 pairs the Raspberry Pi RP2350A with the WIZnet W6300 hardwired TCP/IP controller in a Pico2-compatible form factor.

The RP2350A runs dual-core ARM Cortex-M33 at up to 150 MHz, with 520 KB of on-chip SRAM, 2 MB of QSPI flash, hardware floating-point, DSP extensions, TrustZone security, USB 1.1, and three PIO blocks. The W6300 implements the full Ethernet MAC, PHY, IP stack, TCP, UDP, and socket interface in dedicated silicon, handling both IPv4 and IPv6 natively in hardware.

The W6300 occupies GPIO 15–22 for its SPI/QSPI interface. GPIO 0–14 and 26–28 remain available to the application on the standard Pico-compatible header, meaning the board fits any existing Pico2 accessory or carrier board.

Using the Board in Zephyr Today

With the Zephyr SDK and west installed, the board is immediately usable:

west init ~/zephyrproject
cd ~/zephyrproject && west update
 cd zephyr
west build -b w6300_evb_pico2/rp2350a/m33 samples/net/sockets/echo_server
west flash   # UF2 via USB — hold BOOTSEL before connecting

The board supports UF2 drag-and-drop flashing over USB, OpenOCD via SWD using Raspberry Pi's forked version, and probe-rs targeting the RP235x chip family.

The board documentation is at docs.zephyrproject.org/latest/boards/wiznet/w6300_evb_pico2/ and hardware documentation at docs.wiznet.io.