Wiznet makers

What changed in commit e307339

This Embassy commit is a clear “we’re in” moment for W6300 in the Rust async embedded ecosystem: it adds a new W6300 chip driver module to embassy-net-wiznet and wires it into the chip abstraction layer. In practical terms, it means W6300 is now a first-class target in the Embassy Wiznet backend—no longer a “you could port it” story, but an actual starting point inside the canonical repo.

Three concrete changes make that real:

• Support list updated: embassy-net-wiznet/README.md now lists W6300 (Single SPI only) next to W5500/W5100S/W6100. That “Single SPI only” note is important: it’s honest about the current transport, while still confirming official direction.
• Chip module extended: embassy-net-wiznet/src/chip/mod.rs expands its scope statement to include W6100 and W6300 and exports W6300 so the rest of the crate can select it like the other chips.
• New W6300 implementation file: embassy-net-wiznet/src/chip/w6300.rs introduces the initial register addressing model and the async bus transactions (read/write) needed by the shared driver core. This is the real payload: it defines register blocks (Common, Socket0, TxBuf, RxBuf), an address type (RegisterBlock, u16), a buffer sizing constant (BUF_SIZE = 0x1000 = 4KB pages), and SPI transaction sequencing (instruction → address → dummy → data).

Why it’s great news even in Single SPI mode: W6300’s headline performance comes from high-speed QSPI, but Single SPI is the “lowest friction” on-ramp for the largest number of boards and MCU SPI peripherals. Once the register model and command framing are correct (this commit’s focus), scaling the physical layer to QSPI later is much more straightforward.

Technical analysis: what the new driver is actually doing (and what it unlocks)

W6300 is positioned as a high-performance hardwired TCP/IP controller with dual IPv4/IPv6 hardware stack, 8 sockets, and 64KB internal SRAM for socket buffers. It also supports QSPI (4 data lines) and a 150MHz system clock to push throughput into the “90Mbps+ class” in real designs.

This commit doesn’t try to “finish” W6300 support in one go. Instead, it lands the foundational parts that matter most in Embassy’s architecture:

• A correct addressing scheme: The code models W6300 addresses as (RegisterBlock, u16), which matches the reality that many operations are “which block + which offset,” not just a flat register map.
• Async SPI transaction framing: bus_read() builds a multi-operation transaction: write 1-byte “instruction”, write 2-byte big-endian address, write a dummy byte, then transfer data in place. bus_write() is similar, but ORs 0b0010_0000 into the instruction to enable write-access. These details are the difference between “it compiles” and “it talks to silicon.”
• MACRAW mode nuance captured early: There’s a very practical note: Bit 7 (MAC filter) is normally enabled on W5500, but the author reports W6300 fails to retrieve an IP via DHCP with that bit enabled, so it’s disabled for now (“live with extra noise”). That’s exactly the kind of real-world integration gotcha that’s valuable to have encoded in the driver from day one.

Net effect: Embassy now has an upstream place to iterate on W6300 behavior (DHCP, socket flow, buffer management), and the community can improve it without maintaining private forks. For WIZnet, this is a meaningful step: it makes W6300 discoverable to Rust users who already rely on Embassy’s async executor and embedded-hal-async patterns.

Code + architecture highlight (from the actual commit)

Below are the key excerpts that show how Embassy talks to W6300 over Single SPI today.

1) The driver is registered as a first-class chip

embassy-net-wiznet/src/chip/mod.rs (commit diff lines ~11–13) exports W6300:

mod w6300;
use embedded_hal_async::spi::SpiDevice;
pub use w6300::W6300;

2) The SPI transaction format (instruction → address → dummy → data)

embassy-net-wiznet/src/chip/w6300.rs shows the async bus_read() and bus_write() framing (commit diff lines ~69–99):

// Read: instruction + address + dummy + transfer
let instruction_phase = [address.0 as u8];
let address_phase = address.1.to_be_bytes();
let dummy_phase = [0u8];
let operations = &mut [
    Operation::Write(&instruction_phase),
    Operation::Write(&address_phase),
    Operation::Write(&dummy_phase),
    Operation::TransferInPlace(data),
];
spi.transaction(operations).await?;

// Write: same, but set the Write Access Bit
let instruction_phase = [(address.0 as u8) | 0b0010_0000];

3) “Single SPI only” is explicit in documentation

The README now lists W6300 with its current limitation:

• W6300 (Single SPI only)

Architecture takeaway: This commit adds the “bus + register map” layer—the exact seam where future enhancements live (QSPI mode, higher throughput tuning, more socket blocks than Socket0, etc.), while keeping compatibility with common SPI wiring today.

About the embassy-rs organization

embassy-rs is the GitHub organization behind Embassy, a modern embedded framework built around Rust + async/await. Their public mission is consistent across the main repo and website: help developers write safe, correct, and energy-efficient embedded code faster by using Rust’s safety guarantees together with async-based libraries.

What makes Embassy especially relevant for networking chips like WIZnet parts is that it’s not “one crate”—it’s an ecosystem of interoperating crates (you can use them together or independently). The Embassy Book explicitly describes this modular approach (e.g., an async executor plus reusable libraries), which is why adding a new chip backend in embassy-net-wiznet is such a meaningful upstream event.

In other words: when a WIZnet chip driver lands inside the official embassy-rs/embassy repository, it becomes discoverable and maintainable by the same community and tooling that already powers Embassy networking across targets. That’s the bigger story behind commit e307339: W6300 isn’t a side experiment anymore—it’s now part of the mainstream Embassy integration path (even if the current transport is Single SPI only).

FAQ

1) Why use W6300 with Rust Embassy in the first place?

W6300 gives you a hardwired TCP/IP offload path (TOE) with dual IPv4/IPv6 support, 8 hardware sockets, and 64KB internal buffer SRAM, which can reduce MCU CPU load compared to a full software TCP/IP stack. Embassy’s async model benefits because networking I/O can stay non-blocking while the chip handles protocol work in hardware.

2) How do you connect W6300 to an Embassy-based MCU today (Single SPI)?

In this commit, W6300 is operated in Single SPI mode, which typically means wiring SCLK/MOSI/MISO/CS (plus reset/interrupt as your board design requires). The driver’s transactions explicitly send an instruction byte, a 16-bit address, a dummy byte, then data—so your SPI peripheral must support multi-operation transactions (via embedded_hal_async::spi::SpiDevice).

3) What role does the new W6300 driver play inside embassy-net-wiznet?

It provides the chip-specific glue: register block selection, register addresses, buffer sizing defaults (BUF_SIZE = 0x1000), and the SPI read/write transaction format. With W6300 exported alongside W5500/W5100S/W6100, the shared Wiznet stack can target W6300 without rewriting the higher-level socket logic from scratch.

4) Can beginners follow this and actually get packets moving?

Yes—but expect “early driver” realities. The commit includes a real-world note that enabling the MAC filter bit (common on W5500) prevents DHCP from succeeding on W6300 right now, so it’s disabled. That kind of behavior is normal during bring-up, and having it upstream means beginners can track fixes publicly instead of debugging alone in a private fork.

5) How does W6300 + Embassy compare to W6100 or to a software stack like lwIP?

W6100 is already a strong choice for IPv6/IPv4 hardware stack workflows in embedded Rust, and Embassy supports it today. W6300 targets higher throughput designs with QSPI (4 data lines) and a 150MHz system clock potential, while still providing 8 sockets and hardware offload. Embassy’s current W6300 support is Single SPI only, but the architectural groundwork is now in place for future performance work.