Wiznet makers

1. Overview

Matter has quickly become the common language for smart-home devices, allowing products from ecosystems such as Apple Home, Google Home, Amazon Alexa, and Samsung SmartThings to work together through a single open standard.

Instead of building separate firmware or applications for each ecosystem, developers can implement Matter once and expose their device to multiple platforms. This greatly simplifies interoperability and makes Matter one of the most important technologies for modern connected devices.

This project demonstrates a Matter-over-Ethernet device built on a stock Raspberry Pi Pico (RP2040) and a WIZnet W5500 Ethernet controller, without requiring Wi-Fi, Thread, Linux, an RTOS, or a vendor-specific Matter SDK.

It proves that Matter doesn't require a powerful SoC or a vendor-specific software stack—it can run on a simple RP2040 with Ethernet and bare-metal Rust.

Rather than being just another lighting example, this project serves as an excellent reference for developers who want to understand how a Matter device is built from the networking layer up. It shows how networking, commissioning, security, and the Matter interaction model work together on resource-constrained embedded hardware.

2. Why Is This Project Interesting?

Many Matter examples target powerful SoCs with integrated Wi-Fi or Thread radios. While convenient, those examples often hide much of the networking architecture behind vendor SDKs.

This project takes the opposite approach.

Every major software layer—from Ethernet communication to IPv6 networking and the Matter protocol—is visible in the source code, making it much easier for embedded developers to study how a Matter device actually works.

For anyone learning Rust, embedded networking, or Matter, this repository provides a practical end-to-end reference instead of a black-box SDK example.

3. Why W5500 Matters

One of the most interesting aspects of this project is that it uses the W5500 in MACRAW mode instead of its traditional hardware TCP/IP socket interface.

Normally, the W5500 is used as a hardwired IPv4 TCP/IP controller.

In this design, however, the RP2040 runs the software IPv6 and UDP stack required by Matter, while the W5500 provides fast and reliable Ethernet frame transport through SPI.

This demonstrates that the W5500 is not limited to conventional IPv4 applications. It can also serve as a high-performance Ethernet interface for modern software-defined network stacks such as Matter.

For WIZnet users, this makes the project an especially valuable reference because it showcases an advanced usage model beyond the controller's traditional TOE architecture.

4. System Architecture

The light_eth.rs source describes EmbassyEthMatterStack as using Ethernet for both the main Matter transport and commissioning. It creates an On/Off Light device rather than merely testing Ethernet connectivity.

Data Flow Example

When a user presses the light button in a Matter controller app:

1. The controller generates a Matter On/Off command.
2. The command travels as encrypted Matter traffic over IPv6 and UDP.
3. The Ethernet switch forwards the frame to the W5500.
4. The W5500 transfers the raw Ethernet frame to the RP2040 over SPI.
5. embassy-net processes the Ethernet, IPv6 and UDP layers.
6. rs-matter validates and decodes the Matter message.
7. The On/Off cluster updates the virtual light state.

The return status follows the same path in reverse.

5. W5500 Hardware Connection

The Raspberry Pi Pico wiring is defined directly in examples/rp/src/bin/light_eth.rs.

50 MHz SPI

The example sets the SPI frequency to:

spi_cfg.frequency = 50_000_000;

This provides a high-bandwidth path for transferring complete Ethernet frames between the W5500 and RP2040.

DMA-Based SPI

The SPI peripheral uses two RP2040 DMA channels:

DMA_CH0
DMA_CH1

DMA reduces the amount of CPU intervention required during SPI transfers. The processor can spend more time handling Matter, IPv6 and cryptography while the DMA engine moves data.

MAC Address

The example initializes the interface with:

[0x02, 0x00, 0x00, 0x00, 0x00, 0x00]

This is suitable as a development example. A real deployment with multiple devices should assign a unique MAC address to each unit.

6. How the Code Works

The complete path can be reduced to six main stages.

Stage 1: Initialize Memory

The example uses a small heap because the X.509 dependency used by rs-matter still requires dynamic allocation.

const HEAP_SIZE: usize = 8192;

The futures created while running the Matter stack use a separate bump-allocation region:

const BUMP_SIZE: usize = 16500;

The main Matter stack itself is statically allocated. Source comments estimate its memory footprint at approximately 35–50 KB and recommend static allocation on MCUs to prevent stack exhaustion.

This means the example is no_std, but it is not completely allocation-free.

Stage 2: Initialize SPI and W5500

The application configures:

• SPI0
• 50 MHz SPI clock
• DMA channels
• Chip select
• Interrupt input
• Hardware reset

It then creates the W5500 device and background runner through embassy_net_wiznet::new().

Stage 3: Start the Ethernet Runner

The runner executes as a permanent Embassy task:

spawner.spawn(ethernet_task(runner));

The task calls:

runner.run().await

This background task handles communication between the W5500 hardware and the Embassy network interface.

Stage 4: Create the Matter Stack

The example statically initializes EmbassyEthMatterStack with development commissioning and attestation data.

It also creates a cryptographic provider using the RP2040 ring-oscillator random-number source to seed a cryptographically secure pseudo-random number generator.

Stage 5: Define the Light Endpoint

Endpoint 0 is reserved for Matter system clusters, so the example places the On/Off Light on Endpoint 1.

Endpoint 0
└── Matter system clusters

Endpoint 1
├── Descriptor cluster
└── On/Off cluster

The test light changes its state automatically every five seconds, making it easy to confirm that the application is running even before sending commands from a controller.

Stage 6: Connect Ethernet to Matter

The central integration point is conceptually:

EmbassyEthernet::new(
    PreexistingEthDriver::new(device),
    crypto.rand().unwrap(),
    stack,
)

The device created by the W5500 driver becomes the Ethernet interface used by the Matter stack.

That single boundary connects:

W5500 raw Ethernet interface
             │
             ▼
       embassy-net
             │
             ▼
        rs-matter

7. Building, Flashing and Commissioning

Build

cd examples/rp
cargo +nightly build

Flash the Ethernet Example

probe-rs run --chip rp2040 \
  target/thumbv6m-none-eabi/debug/light_eth

The repository uses the nightly Rust toolchain for the Pico example. Its Cargo configuration includes embassy-net-wiznet with the W5500 Ethernet example dependencies.

Commissioning Flow

After flashing:

1. The firmware starts the W5500 Ethernet interface.
2. The device prints a Matter QR code through its debug output.
3. The user scans the QR code using a compatible Matter controller app.
4. The controller commissions the device.
5. A Light device appears in the application.
6. The light can be switched on and off from the app.
7. The test implementation also toggles its state every five seconds.

The project documentation lists Google Home, Alexa, Apple Home and SmartThings controller configurations. It also states that the firmware is not certified, so controller applications may display an uncertified-device warning.

Important Development Limitation

Persistent storage is currently disabled in the example configuration.

After restarting the Pico, the user may need to:

1. Remove the previous device from the Matter controller.
2. Scan the QR code again.
3. Repeat commissioning.

This behavior comes from the example’s use of DummyKvBlobStore, which does not preserve Matter fabric and commissioning state across resets.

8. Role of the W5500

WIZnet role: The W5500 is the SPI-connected wired Ethernet frame interface that allows the RP2040 software stack to participate in an IPv6 Matter network.

The W5500 normally provides:

• Hardwired IPv4
• TCP
• UDP
• Eight hardware sockets
• Ethernet MAC
• 10/100 Ethernet PHY

Those features make it a hardwired TCP/IP Ethernet controller.

However, this project deliberately uses a different path.

Conventional W5500 Application

Application
    │
W5500 TCP/UDP Socket API
    │
Built-in IPv4 TCP/IP Engine
    │
Ethernet

This Matter Application

Matter
    │
embassy-net IPv6 / UDP
    │
Raw Ethernet Frames
    │
W5500 MACRAW Mode
    │
Ethernet

The embassy-net-wiznet crate explicitly describes itself as an Embassy integration for WIZnet SPI Ethernet chips operating in MACRAW mode.

Why This Is Significant

This demonstrates that W5500 is useful beyond its traditional hardware-socket model.

A developer can use it as:

• A conventional IPv4 TOE controller
• A raw Ethernet interface for a software network stack
• An external MAC/PHY path for MCUs without integrated Ethernet
• A wired transport for protocols requiring networking features outside the W5500 hardware socket engine

For Matter, the MACRAW architecture allows the RP2040 to supply the required IPv6 functionality while retaining the practical hardware advantages of a compact SPI Ethernet controller.

9. Why This Project Matters—and Its Limits

Why It Matters for Makers

This is not a basic W5500 web-server or MQTT demonstration.

It combines:

• Bare-metal Rust
• Async embedded programming
• DMA-based SPI
• Raw Ethernet frames
• Software IPv6 and UDP
• X.509 processing
• Matter commissioning
• Secure Matter sessions
• Device endpoints and clusters

The project shows that a small RP2040 can become a real Matter endpoint without Wi-Fi, Thread, Linux or a vendor-specific Matter SDK.

Practical Use Cases

The architecture is particularly relevant to fixed installations:

• Smart distribution panels
• Wired lighting systems
• Building-control equipment
• Security controllers
• Industrial rooms with restricted wireless use
• Devices where Ethernet availability is more important than mobility

Current Limitations

The public example should still be treated as a development reference.

• The light is virtual and does not directly control a physical GPIO output.
• Persistence is disabled.
• Development device credentials are used.
• The firmware is not Matter-certified.
• Initial commissioning may still encounter issues because the related Rust Matter ecosystem remains under active development.
• The fixed demonstration MAC address must be replaced for multi-device deployment.
• A small heap is still required for X.509 processing. 

Useful Upgrade Path

A production-oriented follow-up could add:

1. Flash-backed Matter fabric persistence
2. A physical LED, relay or light-control output
3. Unique MAC-address provisioning
4. Production device-attestation credentials
5. Ethernet link-loss and reconnection handling
6. Watchdog recovery
7. Secure firmware update
8. Commissioning and interoperability tests across several ecosystems
9. Formal Matter certification preparation
10. Hardware enclosure and power-supply design

10. Source-Backed Summary and FAQ

Source-Backed Summary

rs-matter-embassy includes a Raspberry Pi Pico Ethernet example called light_eth.rs. It initializes a W5500 through SPI0 at 50 MHz, uses DMA for SPI transmission and reception, and runs the W5500 interface through a dedicated Embassy task.

The resulting Ethernet device is passed into EmbassyEthernet, which connects it to the EmbassyEthMatterStack. The RP2040 then runs the software IPv6/UDP stack, cryptographic provider, Matter system clusters and an On/Off Light cluster.

The most important architectural fact is that W5500 is running in MACRAW mode. Its built-in IPv4 TCP/UDP socket engine is not the Matter network stack. Instead, W5500 carries raw Ethernet frames while embassy-net supplies the IP networking required by Matter.

This makes the project a strong WIZnet Maker reference for three reasons:

• It demonstrates W5500 in a nontraditional IPv6 application.
• It brings wired Matter to a stock RP2040 board.
• It provides an inspectable Rust example covering hardware initialization, networking, Matter commissioning and device control.

Related WIZnet Maker Project

https://maker.wiznet.io/Grace_Koo/projects/p%2Dlinked/ : Like the RP2040 + Rust Embassy Matter project, it demonstrates embedded Matter implementation using open standards and modular network architecture.

FAQ

Q. Is the W5500 hardware TCP/IP engine running Matter?

No. The example uses W5500 in MACRAW mode. IPv6 and UDP are handled by the RP2040 through embassy-net.

Q. Why not use the W5500’s normal hardware sockets?

Matter operational communication is based on IPv6. W5500’s conventional hardware socket stack is IPv4-based, so the example processes IPv6 in software and uses W5500 for raw Ethernet-frame transport.

Q. Does the Raspberry Pi Pico need Wi-Fi or Bluetooth?

No. The stock Pico example uses wired Ethernet through W5500 for both its Matter network transport and commissioning path.

Q. Is an operating system required?

No conventional operating system is used. The firmware runs in a Rust no_std environment with the Embassy asynchronous executor.

Q. Is the example completely heap-free?

No. Most large structures are statically allocated, but the example creates an 8 KB heap because the X.509 dependency requires dynamic allocation.

Q. What Matter device does it implement?

It implements an On/Off Light on Endpoint 1. The test device also toggles its state automatically every five seconds.

Q. Can it connect to commercial Matter ecosystems?

The project documentation provides controller options for Google, Alexa, Apple Home and SmartThings. The firmware is a non-certified development example, so warnings or commissioning limitations may appear.

Q. Does commissioning survive a reboot?

Not in the current example. It uses a dummy storage implementation, so the device normally needs to be removed and commissioned again after restarting.

Q. Can the example control a real lamp?

Not without modification. The supplied On/Off device logic is a test implementation. A maker can replace it with GPIO, relay, PWM or another physical output handler.

Q. What is the main educational value?

It shows how a small MCU can run Matter over wired IPv6 by combining a software network stack with W5500 MACRAW Ethernet, rather than relying on Wi-Fi, Thread or W5500’s standard IPv4 socket engine.

Hashtags

#WIZnet #W5500 #Matter #MatterOverEthernet #Rust #EmbeddedRust #Embassy #RP2040 #RaspberryPiPico #BareMetal #NoStd #IPv6 #UDP #MACRAW #SmartHome #IoT #Ethernet #AsyncRust #HomeAutomation #OpenSource