Wiznet makers

Title

Porting ArduinoVNC to W6300-EVB-PICO2: replacing Wi-Fi with W6300 wired Ethernet (DHCP), avoiding SPI conflicts, and pushing toward a tiny thin-client

Introduction

This project is a practical porting story from kazueda’s Zenn article (published 2025/12/14): taking an ArduinoVNC sketch originally built for Raspberry Pi Pico W (Wi-Fi) and moving it onto WIZnet’s W6300-based W6300-EVB-PICO2. The author doesn’t just claim success—they documents the exact engineering steps that make embedded ports reliable: swapping the network stack, stabilizing reset timing, pinning the display bus to avoid contention, temporarily disabling input peripherals, and finally reaching a working milestone: connecting from W6300-EVB-PICO2 to a VNC server running on a Raspberry Pi 4 (TigerVNC/TightVNC).
What makes this worth curating is the method: it’s a clean example of how to carve a “messy” bring-up into a minimal success path—and it ends with a concrete direction for future work: exploring the device as a truly compact thin client.

Overview

The outcome of the article can be read as three deliberate stages, each enabling the next.

Establish a stable wired network baseline
ArduinoVNC on Pico W naturally leans on Wi-Fi libraries and connection loops. The author removes the Wi-Fi include/connect logic and replaces it with W6300lwIP-based Ethernet initialization plus a DHCP wait loop. A notably “real-world” touch is the explicit manual reset pulse (LOW → 100 ms → HIGH → 100 ms) before bringing Ethernet up—small details like this often make the difference between flaky and repeatable bring-up.

Make the display deterministic (avoid shared-bus surprises)
On boards where the Ethernet controller already occupies a critical bus/pin set, “network works but screen is broken” (or the reverse) is common. Instead of relying on auto-configuration, the author pins the LCD to SPI1 and hard-codes the relevant pins, removing a major class of SPI contention problems.

Defer non-essential peripherals until the baseline is solid
Touch and an I2C keyboard are useful—but they also introduce more pin conflicts and debugging variables. The article disables them temporarily, focuses on getting W6300 connectivity + LCD rendering working first, then plans to re-enable input later with safer pin assignments.

In short, this is not a generic networking demo. It’s an embedded port that turns a small MCU-class board into a wired, interactive VNC viewer, which is exactly the kind of workload where stability, bus planning, and incremental integration matter.

Quick background

1) What ArduinoVNC is

ArduinoVNC is a VNC viewer implementation intended for microcontrollers or small boards. It connects to a remote VNC server (e.g., TigerVNC/TightVNC on a Raspberry Pi 4), then:

receives screen updates (typically as rectangles/tiles),

renders them onto a local LCD (often via a graphics layer such as Arduino_GFX), and

sends input events (touch/keyboard translated into mouse/key events) back to the server.

That means ArduinoVNC is a combined workload: networking + graphics rendering + input event delivery. If any part is unstable—network jitter, bus contention, slow draw paths—you feel it immediately.

2) Where VNC is commonly used

VNC (RFB-based remote framebuffer control) shows up repeatedly in a few well-known patterns:

Headless device operation: managing a Raspberry Pi / Linux box without a monitor, while still using a GUI remotely.

Remote support and troubleshooting: screen-sharing and control for IT/helpdesk workflows.

Virtualization and server console access: VM/host graphical consoles, often via browser-based noVNC.

Out-of-band / KVM-style remote management: scenarios where a graphical console is needed even during boot or recovery (implementation details vary by product, but “VNC console” is a recurring motif).

The use case in this article—Raspberry Pi 4 as a VNC server, a small embedded device as the viewer—maps especially well to headless operation and thin-client style access.

3) Who uses VNC, and how broadly (qualitative view)

It’s hard to give a single trustworthy “global user count” because usage spans many implementations and deployment styles. But the user groups are consistently broad:

Makers, students, researchers: remote GUI control of Raspberry Pi and lab machines.

System and infrastructure engineers: VM/server console access and operational workflows.

IT support organizations: remote assistance and troubleshooting.

Embedded/OT engineers: lightweight terminals where heavy UI runs elsewhere.

So VNC tends to behave like infrastructure: not always visible as a “hot product,” but widely present where remote graphical access is needed.

4) Why “Wi-Fi → wired Ethernet” matters so much for VNC

VNC is sensitive to latency and packet loss in a very human way—stutters and delays become instantly obvious. That’s why the author’s decision to remove Wi-Fi assumptions and build on wired Ethernet (DHCP) is more than preference: it’s a practical design choice aligned with the workload, especially if the long-term goal is a reliable, small thin client device.

Author & Community (who the author is, and where the impact comes from)

Author: who is kazueda?

Based on the Zenn profile line shown in your screenshots, kazueda introduces themselves as someone who loves 8-bit CPUs and MCUs—very much a maker/embedded engineer vibe. The writing style matches that: instead of presenting a polished “finished product,” it documents a bring-up → conflict resolution → staged feature expansion process.

This post is also part of the Raspberry Pi Advent Calendar 2025 (listed for 12/22), which naturally creates a distribution path like:

People following the calendar discover it in sequence

Related contributors cross-reference and share within the same theme cluster

It spreads more like a community reading chain than a one-off SEO article

Why this content has real leverage (qualitative)

Its value isn’t “I ran something on a W6300 board.” It’s that it captures reusable porting patterns with enough specificity to replicate:

Replaces the entire Wi-Fi stack with wired Ethernet + DHCP

Accepts W6300 resource constraints (SPI/pins) and moves the LCD to SPI1 explicitly

Disables touch/keyboard during bring-up to reduce variables

Publishes a diff patch to make reproduction realistic

That makes it useful not only to WIZnet users, but to anyone doing RP-class + Arduino sketch porting.

Architecture & Data Flow (mechanism-first)

Here’s the port described as a system flow—because with VNC, networking and display/IO resource layout must both work.

End-to-end flow (high level)

W6300-EVB-PICO2 (ArduinoVNC) acquires an IP via DHCP

It connects (through the router) to a VNC server on Raspberry Pi 4 over TCP (typically 5900/5901, etc.)

Server → device: framebuffer updates stream in

Device renders to LCD via Arduino_GFX (ILI9341)

(Future) touch/keyboard events would be sent back to the server
→ In the current stage, input is intentionally disabled

0) Bring-up priority: define the “minimum success path”

The author doesn’t try to enable everything at once. They aim to make W6300 networking + LCD rendering coexist first, then revisit input devices later. This is a classic move: once touch/keyboard are enabled, debugging can explode due to pin/bus conflicts.

1) Networking stack swap: Wi-Fi → W6300 wired Ethernet

Remove WiFi.h and the Wi-Fi connect loop (WiFi.mode/begin/status)

Introduce W6300lwIP, call eth.begin(), then wait on eth.connected() for DHCP

Stability tweak: manually pulse reset on the W6300 reset pin (LOW 100ms → HIGH 100ms) before calling eth.begin()

It’s not “just changing a library”—it’s replacing the connection model from a Wi-Fi state machine to an Ethernet link/DHCP model.

2) LCD stability: eliminate SPI0 contention structurally

On this board family, the network chip owns critical resources. The author avoids automatic display bus selection and forces SPI1 with explicit pin mapping:

Hard-define LCD SCLK/MOSI/MISO/CS/DC/RST pins

Force the bus using Arduino_RPiPicoSPI(..., spi1)

Drive the panel with Arduino_ILI9341

For VNC, this is basically “half the win,” because display rendering is the whole point.

3) Temporarily disable touch/keyboard: the bring-up isolation strategy

Comment out touch.h, keyboard.h, their init calls, and their handlers

Rationale: W6300 has dedicated pins (e.g., GPIO16–21, 22, 15, etc.) and other features risk collisions

Plan: later re-enable after re-mapping to safe pins

This isn’t “giving up features”—it’s a deliberate isolation phase.

4) Status UI/logging: improve debug throughput

Rename and update the message from TFTnoWifi() → TFTnoEthernet()

Print eth.localIP() after connection

In networked embedded systems, showing the IP can save hours.

5) Patch publication

The author publishes a diff patch and notes it targets their modified ArduinoVNC-pico.ino and may not perfectly patch personal settings—honest and useful for real-world reproduction.

WIZnet / Ethernet Section (where WIZnet is used)

In this content, WIZnet isn’t “background”—it’s the core enabler.

Hardware: W6300-EVB-Pico2, an RP2350-based evaluation board featuring WIZnet’s W6300 hardwired TCP/IP Ethernet controller

Software: bring-up uses W6300lwIP / Wiznet6300lwIP to initialize Ethernet and obtain DHCP connectivity (as shown in the article text/patch)

System impact: because W6300 claims specific buses/pins, the port explicitly restructures resources—LCD moved to SPI1, input disabled until safe pin reassignment

So the post demonstrates how to make a complete application (VNC) work around and with a WIZnet Ethernet board’s constraints, rather than treating networking as an afterthought.

Results / Lessons learned / Limitations

Results (what worked)

Wired Ethernet (DHCP) successfully brought up on W6300-EVB-PICO2

ArduinoVNC connects to a VNC server on Raspberry Pi 4 (TigerVNC/TightVNC referenced)

The setup uses a router to connect the device and the Pi

Lessons learned (transferable patterns)

Explicit resource assignment beats “auto config” when buses collide (SPI1 forcing is often the fastest route to stability)

Input devices are bring-up multipliers—get network + display stable first

Ethernet bring-up is often half reset timing—manual reset pulses can dramatically improve stability

Status messages and IP display are part of the product, not just debugging

Publishing a patch creates impact—others can follow, fork, and extend

Limitations / next steps (as stated by the author)

Touch pad and I2C keyboard remain disabled for now

Plan to add DNS-based addressing so the VNC server can be selected by name

Explore the form factor as a thin client (e.g., “foldable keyboard-sized thin client”)

Where this matters (who benefits)

Engineers building wired Ethernet apps on RP-class boards (Pico/Pico2 family)

W6300-EVB-Pico2 users needing network + LCD bring-up on the same target

Anyone porting Arduino sketches across boards and wanting repeatable conflict-resolution patterns (SPI/pins/feature staging)

Teams exploring thin-client/HMI alternatives where the terminal stays light and the UI lives on a remote host

Quick Reproduce / Getting Started (checklist)

Remove Wi-Fi related code from the ArduinoVNC sketch

Replace with W6300lwIP-based Ethernet bring-up

Apply a manual W6300 reset pulse (e.g., 100ms low/high) before eth.begin()

Wait for DHCP using eth.connected()

Force the LCD onto SPI1 with explicit pin mapping

Disable touch/keyboard during the initial bring-up phase

Update UI/log messages for Ethernet and print eth.localIP()

Configure VNC server IP/port/password and validate connection

References (collected)

[1] Zenn — kazueda, “W6300-EVB-PICO2にArduinoVNCを移植する話” (2025/12/14): https://zenn.dev/kazueda/articles/6a296ed5b09603 (verified via user-provided screenshots/text/patch)
[2] Raspberry Pi Advent Calendar 2025: https://adventar.org/calendars/11389
[3] WIZnet Product Page — W6300-EVB-Pico2: https://wiznet.io/products/evaluation-boards/w6300-evb-pico2
[4] WIZnet Product Page — W6300 Ethernet Controller: https://wiznet.io/products/ethernet-chips/w6300
[5] RFC 6143 — The Remote Framebuffer Protocol (RFB, used by VNC): https://www.rfc-editor.org/rfc/rfc6143