--- title: "W6300-EVB-PICO2にArduinoVNCを移植する話" url: "https://maker.wiznet.io/matthew/projects/w6300-evb-pico2arduinovnc/" markdown_url: "https://maker.wiznet.io/matthew/projects/w6300-evb-pico2arduinovnc/md" type: "UCC: User Created Content" author: "Kazumasa Ueda" author_url: "https://zenn.dev/kazueda/articles/6a296ed5b09603" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "Kazumasa Ueda" original_url: "https://zenn.dev/kazueda/articles/6a296ed5b09603" published: "2025-12-16" language: "ja" likes: 0 views: 408 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # W6300-EVB-PICO2にArduinoVNCを移植する話 > W6300-EVB-PICO2にArduinoVNCを移植する話 Original author: Kazumasa Ueda (source: https://zenn.dev/kazueda/articles/6a296ed5b09603) ## Article ## 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. 1. **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. 2. **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. 3. **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 ![](https://maker.wiznet.io/upload/ckeditor5/1052283358%5F1766359630%2Epng) Generate AI Image **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. ![](https://maker.wiznet.io/upload/ckeditor5/1052283358%5F1766360471%2Epng) Generate AI Image ### 2) Where VNC is commonly used ![](https://maker.wiznet.io/upload/ckeditor5/1052283358%5F1766360675%2Epng) Generate AI Image 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) ![](https://maker.wiznet.io/upload/ckeditor5/1052283358%5F1766362162%2Epng) 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 1. It connects (through the router) to a **VNC server on Raspberry Pi 4** over TCP (typically 5900/5901, etc.) 2. Server → device: **framebuffer updates** stream in 3. Device renders to LCD via Arduino_GFX (ILI9341) 4. (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) 1. Remove Wi-Fi related code from the ArduinoVNC sketch 2. Replace with `W6300lwIP`-based Ethernet bring-up 3. Apply a manual W6300 reset pulse (e.g., 100ms low/high) before `eth.begin()` 4. Wait for DHCP using `eth.connected()` 5. Force the LCD onto **SPI1** with explicit pin mapping 6. Disable touch/keyboard during the initial bring-up phase 7. Update UI/log messages for Ethernet and print `eth.localIP()` 8. 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` --- Source: https://maker.wiznet.io/matthew/projects/w6300-evb-pico2arduinovnc/