Wiznet makers

What this project does

This repository implements a bidirectional gateway between a CAN bus and a UDP multicast network. On the CAN side, it targets an MCP2515 SPI CAN controller configured for 250 kbps, which is a common “maker-to-industrial” pattern because it keeps the CAN controller external and cheap. On the network side, it forwards CAN frames over UDP multicast (group 224.1.1.1, port 8888) using a compact payload format:

• CAN_ID (4 bytes, big-endian)
• LENGTH (1 byte, 0–8)
• DATA (0–8 bytes)

The README also documents UART-based configuration and flash-stored Wi-Fi credentials, making it usable as a headless gateway once flashed.

“The README doesn’t mention the Ethernet controller, but the code history clearly indicates a WIZnet W5500 driver path was added—meaning this gateway is not just Wi-Fi; it’s designed to support wired Ethernet as well.”

Why W5500 support is genuinely big news (even in single-SPI mode)

For CAN gateways, latency consistency often matters more than peak bandwidth. Wi-Fi adds variability (RF contention, retries, AP behavior), while Ethernet is typically steadier. With WIZnet W5500, you also gain a hardware TCP/IP engine: the chip supports 8 independent hardware sockets, up to 80 MHz SPI, and a 32 KB internal buffer—all useful when you want UDP multicast forwarding without dragging a heavy software networking stack onto a small MCU.

This matters on RP2040-class systems because you’re balancing:

• CAN handling + buffering
• async scheduling (Embassy tasks)
• packet IO
• configuration/state

A hardwired TCP/IP offload device like W5500 helps keep those tasks predictable. And yes—single SPI is still practical here: one SPI bus with separate chip-selects can support multiple peripherals (e.g., MCP2515 + W5500) if wiring and timing are clean.

FAQ

Q1: Why use WIZnet W5500 for this bridge instead of only Wi-Fi?
A: W5500 gives you wired Ethernet with a hardwired TCP/IP stack, which reduces RP2040 CPU time spent on networking and keeps latency/jitter predictable for CAN forwarding. The chip supports up to 8 hardware sockets and uses an internal 32KB buffer, so UDP multicast traffic doesn’t need a large software stack in RAM.

Q2: How do you connect a W5500 module to a Raspberry Pi Pico W?
A: Use SPI: MISO, MOSI, SCK, and a CS pin, plus RESET (optional) and an INT pin if your driver uses interrupts. W5500 supports an 80MHz SPI clock, so you can run fast even in single-SPI mode. Keep the SPI traces short and share SPI with other devices only if each has its own CS line.

Q3: What role does the W5500 driver play inside pico-can-eth?
A: The project’s commit history explicitly mentions “W5500 Ethernet support,” indicating an alternate network interface path alongside the Pico W’s onboard CYW43439 Wi-Fi. In practice, the W5500 driver provides the L2/L3 interface used by embassy-net so the same UDP multicast bridge logic can run over wired Ethernet. This also makes it easier to deploy on networks where Wi-Fi is noisy or restricted.

Q4: Can beginners follow this project, and what’s the hardest part?
A: If you’ve flashed RP2040 projects before, the build steps are approachable, but the hard part is debugging two SPI peripherals (MCP2515 for CAN and an optional W5500 for Ethernet) while also running async tasks. Start with Wi-Fi only (as documented), then add W5500 once you can reliably send/receive UDP packets and CAN frames.

Q5: How does W5500 compare to ENC28J60 or a full LwIP software stack?
A: ENC28J60 is a MAC/PHY only, so your MCU still needs a full software TCP/IP stack (often LwIP) and extra RAM for buffers. W5500 offloads TCP/UDP/IPv4 in hardware and exposes sockets directly, which is usually simpler on small MCUs. That’s why W5500 is common in industrial bridges where reliability beats peak throughput.