Building an Industrial Access Control Gateway with WIZnet W6300-EVB-Pico2

A production-grade firmware architecture that brings together MQTT, Wiegand readers, RS485 devices, I2C LCD, RTC, and SD card storage — all running on a single RP2350-based board.

Project Overview

This project is an industrial-grade Access Control Gateway firmware built around WIZnet's W6300-EVB-Pico2 board. The full source is published by GitHub user JohnBaird in the rpi_pico2_6300 repository and is also featured on the WIZnet Maker platform.

This is not a toy demo. The firmware tackles a real-world problem: coordinating a Wiegand access panel, RS485 slave devices, an I2C LCD, an RTC, and SD card storage within a single coherent firmware architecture — over a hardwired Ethernet link that never drops.

Core Hardware

W6300-EVB-Pico2 at a Glance

The W6300 is WIZnet's latest hardwired TCP/IP controller, supporting an IPv4/IPv6 dual-stack and connecting to the RP2350 over QSPI. Compared to the traditional SPI approach, QSPI delivers significantly higher throughput while integrating cleanly with the Pico SDK. Because the network stack runs entirely in hardware, the RP2350's second core is freed up for application logic rather than being consumed by TCP/IP processing.
 

Peripheral Lineup

• SD Card — stores config.json, Wiegand format definitions, event logs, and the offline transaction queue
• I2C RTC (DS3231, 0x68) — provides accurate local timestamps even without NTP
• I2C 4×20 LCD (0x27 / 0x3F) — displays operational status at a glance
• I2C Wiegand Processor (0x30–0x33) — handles up to four independent access interfaces
• UART RS485 (75176-type transceiver) — supports up to eight RS485 slave devices
• DS2401 1-Wire — reads a hardware-derived MAC address and provides a unique device identity
• MCP9808 — I2C temperature sensor that publishes readings via MQTT
• PoE-sourced 12 V main rail — powers the entire system from a single cable

Network Architecture: The SPV1.0 Topic Convention

Rather than relying on a generic MQTT topic hierarchy, this project defines its own lightweight protocol: SPV1.0.

The topic format is:

SPV1.0/<domain>/<command>/<sourceID>/<destinationID>

A concrete example:

SPV1.0/ident/stc_access_request/101E002A/6001
       └─ domain ─┘└──── command ────┘└─ srcID ─┘└─ dstID ─┘

Most MQTT designs encode device groups or feature areas in the topic path. SPV1.0 takes a different approach — it embeds the serial IDs of both the source and destination directly in the topic. This allows the broker to route messages to exactly the right controller without any additional lookup logic on the subscriber side.

The JSON payload carries fields such as interface, card_number, and wiegand_format, keeping the topic lean while still providing rich context in the body.

Compared to heavier standards like Sparkplug B, SPV1.0 reduced code size and RAM usage by roughly 40% — a meaningful saving on a microcontroller with limited resources.

Power Architecture

The system is powered entirely over PoE, which feeds a single 12 V main rail. Each Wiegand module draws from its own dedicated 5 V buck converter (RECOM/TRACO, 1 A rated), isolating faults at the module level.

PoE Module → 12 V Main Rail
  ├── W6300-Pico2 on-board regulator
  ├── Wiegand Module 0 → Local 5 V buck converter
  ├── Wiegand Module 1 → Local 5 V buck converter
  ├── Wiegand Module 2 → Local 5 V buck converter
  └── Wiegand Module 3 → Local 5 V buck converter

This per-module power isolation means a single faulty Wiegand unit cannot bring down the rest of the gateway. It also makes field replacement straightforward — swap the module, restore power, done.

Lessons Learned

The W6300 hardware stack pays dividends in core allocation. Offloading TCP/IP to silicon freed the RP2350's second core entirely for I²C polling and IRQ handling — a clean separation that simplified both firmware structure and real-time responsiveness.

SPV1.0 keeps the footprint small. Defining a purpose-built topic convention rather than adopting Sparkplug cut code size and RAM consumption by about 40%, which matters when working within microcontroller constraints.

SD-based configuration is convenient but fragile at power-off. Storing config.json on an SD card makes field updates easy — no reflashing required — but a sudden power loss during a write cycle can corrupt the card. Migrating to LittleFS mitigates this risk by providing wear-leveling and crash-safe writes.

Future Improvements

• Door controller logic — richer timer and sensor fusion for more nuanced access policies
• Multilingual LCD menus and OTA firmware update — reducing the need for on-site engineering visits
• Automated RS485 device provisioning — streamlining the addition of new slave devices in the field

How This Project Compares to Similar Work on WIZnet Maker

The WIZnet Maker community has produced a handful of projects that tackle the same central problem: bridging hardwired Ethernet to industrial field buses using WIZnet's hardware TCP/IP offload. Two of them — both live on maker.wiznet.io — share enough DNA with this gateway to make a direct comparison worthwhile.

Project A — STM32F103 W5500 MQTT Gateway for CAN and RS485 Motor Control

View on WIZnet Maker

Project B — How W55RP20 Can Add Industrial Ethernet Control to an Automated Variac and Stepper System

View on WIZnet Maker

Summary

The W6300-EVB-Pico2 proves that a compact, cost-effective board can anchor a production-quality access control gateway. Hardwired Ethernet via the W6300 eliminates the reliability concerns of Wi-Fi; SD-based configuration keeps field deployment flexible; and the SPV1.0 MQTT convention delivers precise device-to-device routing without bloated middleware. Whether the target environment is a commercial building, a university campus, or an industrial facility, this firmware provides a solid starting point for building a dependable access and door control system.