Wiznet makers

W55RP20 Ethernet Foundation for a VSCP Access Node

vscp-demo-wiznet-w55rp20-nfc is an early firmware project for the WIZnet W55RP20-EVB-Pico, aimed at a distributed NFC lock mechanism that will use VSCP Link and multicast protocol. In the current repository state, the implemented part is the Ethernet foundation: W5500 communication probing, WIZnet ioLibrary setup, static or DHCP network configuration, PHY diagnostics, and a FreeRTOS task structure. That makes it most useful today as a bring-up scaffold for a future VSCP access-control node rather than as a complete NFC lock application.

VSCP, or Very Simple Control Protocol, is a framework for distributed automation nodes. The project name and README describe a future NFC lock using VSCP Link and multicast. The repository also includes the author's vscp-firmware project as a submodule, which contains reusable VSCP firmware components. However, the active firmware target currently builds only firmware/src/main.c with Pico SDK, WIZnet ioLibrary, and FreeRTOS. There is no NFC reader driver, lock actuator logic, multicast transport, or VSCP Link server in the compiled target yet.

W5500 Bring-Up on W55RP20

The most concrete part of the project is the W5500 bring-up path. The CMake file builds WIZnet ioLibrary sources for wizchip_conf.c, socket.c, W5500/w5500.c, and DHCP/dhcp.c, then defines _WIZCHIP_=W5500. The firmware registers chip-select, byte-transfer, and burst-transfer callbacks for the WIZnet library, using GPIO pins for CS, SCK, MISO, MOSI, INT, and RST.

One interesting detail is that the firmware does not assume a single SPI mode and reset polarity. It probes combinations of SPI mode 0, SPI mode 3, active-low reset, and active-high reset, then checks the W5500 VERSIONR value. That is a practical diagnostic feature for early board bring-up, because it separates wiring or mode problems from higher-level network issues.

The W5500 is configured through WIZnet ioLibrary calls such as wizchip_init(), getVERSIONR(), ctlnetwork(), wizphy_getphylink(), and wizphy_setphyconf(). Static IP mode is the default in main.c, with DHCP available through the same Ethernet task. When DHCP is enabled, the firmware initializes socket 0 for DHCP and repeatedly calls DHCP_run().

// firmware/src/main.c
if (wizchip_init(tx_size, rx_size) != 0) {
    puts("W5500 init failed");
    return false;
}

uint8_t lib_version = getVERSIONR();
uint8_t raw_version = wiz_raw_read_version(cpol, cpha);
printf("W5500 post-init check: lib=0x%02X raw=0x%02X\r\n", lib_version, raw_version);

Because the active code uses W5500 and ioLibrary DHCP, this project does exercise the WIZnet hardware TCP/IP path in a limited way. The TOE status is best described as partial: the W5500 socket layer is present through ioLibrary and DHCP, but the application-level VSCP multicast or TCP/UDP lock protocol is not implemented yet.

Current Firmware Structure

The firmware creates two FreeRTOS tasks. The Ethernet task selects static or DHCP mode, initializes W5500, optionally runs DHCP, and keeps the network service loop alive. The heartbeat task prints a status line once per second. This is small, but it is enough to validate the essential board path before adding protocol and application code.

There are also a few repository-level clues that show the project is still moving from scaffold to application. The GitHub Actions workflow installs CMake, Ninja, and the ARM embedded toolchain, then builds UF2 and HEX artifacts. The README says the firmware expects Pico SDK and ioLibrary submodules, while the actual CMake setup also requires FreeRTOS-Kernel. The CMake default board is wiznet_w5100s_evb_pico, even though the README and repository name point to W55RP20-EVB-Pico, so users should verify the board definition before building.

Where This Can Go Next

The project is valuable as a starting point for a wired Ethernet access-control node. W55RP20 provides the RP2040 application core together with W5500 Ethernet in the same WIZnet platform, so the firmware can keep network bring-up and application logic close together. The next meaningful steps would be adding the NFC reader driver, defining the lock-control state machine, connecting the VSCP firmware submodule to the build target, and implementing the multicast or VSCP Link transport over W5500 sockets.

FAQ

What does this project use the W5500 for?

The current firmware uses W5500 for Ethernet bring-up, PHY/link diagnostics, static IP configuration, and optional DHCP through WIZnet ioLibrary. It does not yet implement the final VSCP or NFC lock network traffic.

Is this a complete NFC lock project?

Not yet. The repository description points toward a distributed NFC lock, but the active firmware target does not include NFC reader code, lock actuator code, or access-control decision logic.

Does the firmware use WIZnet TOE?

Partially. The build includes WIZnet socket.c and DHCP code, and DHCP uses W5500 UDP socket operations internally. The application-level VSCP socket transport is not present yet, so the TOE use is limited to bring-up and DHCP support.

What should developers check before building it?

They should initialize submodules recursively, install CMake, Ninja, and gcc-arm-none-eabi, then verify the PICO_BOARD setting. The current CMake default is wiznet_w5100s_evb_pico, while the repository targets W55RP20-EVB-Pico.