Wiznet makers

The example implements a virtual Matter On/Off Light using:

• Raspberry Pi Pico with RP2040
• WIZnet W5500 over SPI
• Rust in a #![no_std] and #![no_main] environment
• Embassy asynchronous runtime
• embassy-net IPv6/UDP networking
• rs-matter device and security logic

Direct answer: The W5500 connects the Pico to wired Ethernet, but this example does not use the W5500’s conventional IPv4 hardware TCP/UDP sockets. Instead, the embassy-net-wiznet driver runs the W5500 in MACRAW mode, allowing the RP2040’s software network stack to process the IPv6 and UDP traffic required by Matter.

That distinction is the most important technical point in the project.

Not this:

Matter
   │
W5500 Hardware TCP/UDP Socket
   │
Ethernet

But this:

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

Matter is an IPv6-based application protocol. Its operational communication uses IPv6 unicast and multicast addressing, making a software IPv6 stack necessary when using an Ethernet controller whose native hardware socket architecture is based on IPv4.

2. What Problem Is It Solving?

Many embedded Matter examples assume one of the following environments:

• A Wi-Fi-capable MCU
• A Thread radio
• A vendor-specific Matter SDK
• An RTOS or full operating system
• A comparatively large MCU with substantial memory

A stock Raspberry Pi Pico has none of these network interfaces. It provides an RP2040 Cortex-M0+ MCU, SRAM, flash, GPIO, SPI, and other basic peripherals.

The project answers a practical question:

Can a small, non-wireless RP2040 run a Matter device over wired Ethernet using Rust?

The answer demonstrated by the repository is yes.

The example adds a W5500 to the Pico and divides the work between the two devices:

The repository explicitly states that the stock Pico supports the Ethernet example through light_eth and W5500.

This opens a useful path for fixed smart-home and building devices where Wi-Fi or Thread is unnecessary:

• Wall-mounted controllers
• Wired lighting controllers
• Fixed sensors
• Access-control equipment
• Building automation endpoints
• Devices installed in RF-congested environments

3. Matter, Embassy and W5500 in Plain Language

The software stack is easier to understand when each layer is treated as a separate job.

Matter: the smart-home language

Matter defines concepts such as:

• Device types
• Endpoints
• Clusters
• Attributes
• Commands
• Commissioning
• Device authentication
• Secure operational sessions

In this example, the device exposes an On/Off Light on Endpoint 1.

rs-matter: the Matter implementation

rs-matter provides the Rust implementation of the Matter protocol and data model. It processes commands such as turning the virtual light on or off.

Embassy: the runtime

Embassy provides asynchronous embedded execution without requiring a conventional operating system.

Instead of blocking while waiting for Ethernet traffic, timers or SPI operations, tasks can wait asynchronously while other work continues.

embassy-net: the IP network stack

embassy-net processes networking above the Ethernet-frame layer, including the IPv6 and UDP path needed by the Matter application.

W5500: the wired Ethernet interface

The W5500 moves Ethernet frames between the RP2040 and the physical network through SPI.

Intuitive Example

Think of the system as an international delivery service:

• Matter defines the language and contents of the documents.
• IPv6 and UDP determine the destination and delivery rules.
• Embassy coordinates the workers.
• W5500 is the vehicle carrying the sealed package onto the Ethernet network.

The W5500 normally includes its own hardware TCP/IP engine. In this project, however, the package is carried as a complete raw Ethernet frame because the RP2040 needs to run an IPv6-capable software stack for Matter.

4. System Architecture

 ┌────────────────────────────────────────────┐
 │ Matter Controller                         │
 │ Google / Alexa / Apple / SmartThings      │
 └──────────────────────┬─────────────────────┘
                        │
                        │ Matter over IPv6 / UDP
                        ▼
             Home Router or Ethernet Switch
                        │
                        │ RJ45 Ethernet
                        ▼
              ┌──────────────────────┐
              │    WIZnet W5500      │
              │                      │
              │  MACRAW Frame I/O    │
              │  Ethernet MAC / PHY  │
              └──────────┬───────────┘
                         │
                         │ SPI 50 MHz
                         │ DMA TX / RX
                         │ INT + RESET
                         ▼
              ┌──────────────────────┐
              │ Raspberry Pi Pico    │
              │      RP2040          │
              │                      │
              │ embassy-net          │
              │ IPv6 / UDP / mDNS    │
              │                      │
              │ rs-matter            │
              │ Security / Clusters  │
              │                      │
              │ On/Off Light Logic   │
              └──────────────────────┘

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.

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